10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7943 人已学习
课程目录
已完结 56 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 程序员解决的问题,大多不是程序问题
免费
思考框架 (1讲)
01 | 10x程序员是如何思考的?
以终为始 (11讲)
02 | 以终为始:如何让你的努力不白费?
03 | DoD的价值:你完成了工作,为什么他们还不满意?
04 | 接到需求任务,你要先做哪件事?
05 | 持续集成:集成本身就是写代码的一个环节
06 | 精益创业:产品经理不靠谱,你该怎么办?
07 | 解决了很多技术问题,为什么你依然在“坑”里?
08 | 为什么说做事之前要先进行推演?
09 | 你的工作可以用数字衡量吗?
10 | 迭代0: 启动开发之前,你应该准备什么?
答疑解惑 | 如何管理你的上级?
划重点 | 关于“以终为始”,你要记住的9句话
任务分解 (11讲)
11 | 向埃隆·马斯克学习任务分解
12 | 测试也是程序员的事吗?
13 | 先写测试,就是测试驱动开发吗?
14 | 大师级程序员的工作秘笈
15 | 一起练习:手把手带你分解任务
16 | 为什么你的测试不够好?
17 | 程序员也可以“砍”需求吗?
18 | 需求管理:太多人给你安排任务,怎么办?
19 | 如何用最小的代价做产品?
答疑解惑 | 如何分解一个你不了解的技术任务?
划重点 | 关于“任务分解”,你要重点掌握哪些事?
沟通反馈 (12讲)
20 | 为什么世界和你的理解不一样
21 | 你的代码为谁而写?
22 | 轻量级沟通:你总是在开会吗?
23 | 可视化:一种更为直观的沟通方式
24 | 快速反馈:为什么你们公司总是做不好持续集成?
25 | 开发中的问题一再出现,应该怎么办?
26 | 作为程序员,你也应该聆听用户声音
用户故事 | 站在前人的肩膀上,领取属于你的高效工作秘籍
27 | 尽早暴露问题: 为什么被指责的总是你?
28 | 结构化:写文档也是一种学习方式
答疑解惑 | 持续集成,一条贯穿诸多实践的主线
划重点 | 一次关于“沟通反馈”主题内容的复盘
自动化 (12讲)
加餐 | 你真的了解重构吗?
29 | “懒惰”应该是所有程序员的骄傲
30 | 一个好的项目自动化应该是什么样子的?
31 | 程序员怎么学习运维知识?
32 | 持续交付:有持续集成就够了吗?
33 | 如何做好验收测试?
34 | 你的代码是怎么变混乱的?
35 | 总是在说MVC分层架构,但你真的理解分层吗?
36 | 为什么总有人觉得5万块钱可以做一个淘宝?
37 | 先做好DDD再谈微服务吧,那只是一种部署形式
答疑解惑 | 持续集成、持续交付,然后呢?
划重点 | “自动化”主题的重点内容回顾汇总
综合运用 (7讲)
38 | 新入职一家公司,怎么快速进入工作状态?
39 | 面对遗留系统,你应该这样做
40 | 我们应该如何保持竞争力?
答疑解惑 | 如何在实际工作中推行新观念?
划重点 | “综合运用”主题内容的全盘回顾
总复习 | 重新审视“最佳实践”
总复习 | 重新来“看书”
结束语 (1讲)
结束语 | 少做事,才能更有效地工作
10x程序员工作法
登录|注册

05 | 持续集成:集成本身就是写代码的一个环节

郑晔 2019-01-04
上一讲我们探讨了需求的“完成”,你现在知道如何去界定一个需求是否算做完了,这要看它是不是能够满足验收标准,如果没有验收标准,就要先制定验收标准。这一点,对于每一个程序员来说都至关重要。
在今天这一讲中,我们假设需求的验收标准已经制定清楚,接下来作为一个优秀的程序员,你就要撸起袖子准备开始写代码了。
不过在这里,我要问你一个问题:“是不是写完代码,工作就算完成了呢?”你或许会疑惑,难道不是这样吗?那我再问你:“代码是技术团队的交付物吗?”
你是不是发现什么不对劲了。没有人需要这堆文本,人们真正需要的是一个可运行的软件。写代码是程序员的职责,但我们更有义务交付一个可运行的软件。
交付一个可运行的软件,通常不是靠程序员个体奋战就能完成的,它是开发团队协作的结果。我们大多数人都工作在一个团队中,那我们写的代码是不是能够自然而然地就和其他人的代码配合到一起呢?显然没那么简单。
如果想将每个程序员编写的代码很好地组合在一起,我们就必须做一件事:集成。
但是集成这件事情,该谁做,该怎么做呢?我不知道你有没有思考过这个问题。在开始这个话题之前,我先给你讲个故事。

集成之“灾”

2009 年,我在一个大公司做咨询。对接合作的部门里有很多个小组,正在共同研发一个项目。他们工作流程是,先开发一个月,等到开发阶段告一段落,大项目经理再把各个小组最精锐成员调到一起开始集成。对他们来说,集成是一件大事,难度很大,所以要聚集精英来做。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(31)

  • Scott
    曾经参与过一个项目,中美印三地开发,开发测试产品加起来可能过百吧。当时,我们中国团队做过一个这样的工具,每次在git-review上提交/更新review时,自动构建一个当前branch是最新版,打上review的patch,然后构建,跑UT,UT覆盖率在95%再向下走。

    做到这一步,其实不算什么,但是已经超过国内80%的同行水平了。然后我们还会构建一个虚拟机镜像安装这个build,安装好了在专门的虚拟测试网络上启起来,利用自动测试工具跑一些基本的case,比如登陆啊,基本的操作啊,这一系列跑完,才可以正式的让人review。

    这个项目因为一些方向性和市场的问题,一年多就失败了,项目组解散。但是集成水平,的确是我经历过的最高的。

    作者回复: 确实做得不错!项目失败和实践之间是不能划等号的,不能因为项目失败就否认实践的优秀。

    2019-01-04
    1
    16
  • 虢国技匠
    打卡:
    目前我们团队借助git-flow,以git的分支 feature、release、hotfix和里程碑tag进行持续集成和构建;
    release 出发测试环境构建、tag出发生产环境部署

    作者回复: 我最喜欢的分支模型是,没有feature分支的git flow。

    2019-01-04
    6
  • pyhhou
    公司一部分人在美国这边做开发,另一部分在台湾做开发,每到集成,想到的头疼的问题第一个就是时差问题,一般的流程就是他们那边发现了问题邮件发给我们,我们看一下感觉好像不是这边的问题,给些解释和建议又邮件抛回去,感觉这种情况可能需要就是一方的负责人得牺牲一下自己的私人时间,积极开会沟通?持续集成必须合作的所有teams都同意,或是都有这样的意识才行,不然光靠一方的努力感觉弄不起来,不知老师如何看?

    作者回复: 不仅仅是持续集成,任何涉及到协作的实践都需要协作相关方的共同配合才可能有效落地。

    如果大家都觉得工作起来很辛苦,其中肯定有不对的地方,需要坐下来,一起商量解决方案。我在专栏中给大家提供的就是你坐下来可以提出的建议,比如,持续集成,验收标准等等。

    2019-01-04
    5
  • 一步
    虽然我们在同一个时代写代码做开发,但在技术实践层面,不同的团队却仿佛生活在不同的年代。
    2019-01-12
    3
  • liu
    简单一句,小步快走。尽早的暴露问题并解决问题,能够减少系统潜在奉献。持续集成能够帮忙做到
    2019-01-04
    3
  • 捞鱼的搬砖奇
    关于代码提交的问题,举例子是公司要求每日提交,如果一个功能没做好也要提交?还是说只要没有编译问题,即使未完成也得提交?

    作者回复: 好问题,你对提交的理解说明任务分解做得不够,不能小步提交,这是在任务分解模块要讲的内容,敬请期待。

    2019-01-04
    3
  • 猿工匠
    开发完成的定义:集成为可运行的软件
    开发模式:持续集成,尽早构建
    git 版本工具,Jenkins 持续构建
    2019-03-19
    2
  • 喜悦
    今日概念:
    1. 集成:将各个独立部分组合在一起使其成为一个新个体的过程;
    2. 每日集成:每天进行一次集成,它和持续集成只有时间间隔上的差别;
    3. 持续集成:每日集成推演到极致的结果,将开发和集成合二为一;

    今日总结:
    集成本身就是写代码的一个环节,持续集成已经有了很成熟的体系与实现,早点使用持续集成吧;
    2019-01-06
    2
  • zhengfc
    老师,您好;最近在做流程方面的重新梳理和实践,发现有个问题:比如产品那边起初是5个功能上线,后来由于某些原因或者市场原因临时砍掉一个一个功能,而这功能按持续集成每日构建的思路代码肯定是合掉了,这就产生代码回退和重新集成的问题,这个痛点有什么好的方案吗

    作者回复: 在“任务分解”模块的答疑中,我介绍了 Feature Toggle,你可以了解一下。

    这里面的关键点在于,你的代码模块需要划分清楚,这样无论是使用 Feature Toggle,还是调整代码,都有足够的空间去操作。

    2019-02-23
    1
  • 梦醒时分
    没有feature分支的git flow。是指开发和测试分支都使用一个么

    作者回复: 你可以先了解一下git flow,去掉feature分支就变成了主干开发,这是我鼓励的,换句话说,我的观点就是尽可能不使用分支,更别说开发分支,测试分支了。

    2019-01-08
    2
    1
  • 丁丁历险记
    笔记
    早点集成。
    好处,早点集成,早点发现问题。
    思考 未get 到其中深意,但最后集成的苦没少吃。
    但有时想想,好像根源是需求把控,产品很多东西啰哩巴嗦的定不下来,往往需要靠上线这事逼他们妥协。
    so 走向持续集成,是需要前序准备的。

    2019-10-31
  • 好久好久好久好久好久
    老师,之前在一家公司开发是开发完成一部分功能,然后测试测试一部分功能,开发继续开发,并修复之前的bug,这样的做法是对的吗,因为还要处理之前的bug,可能会耽误开发的进度,还有这算持续集成的范围吗
    2019-09-09
  • 码农Kevin亮
    请问老师,持续集成的前提是不是要有单元测试?我咨询过身边二三十个同行,要求写单元测试的公司不到20%,那是不是就无法持续集成?另外持续交付是指所有的测试工作都自动化吗,不是太理解这过程

    作者回复: 持续集成一定要自动化,不自动化开发速度就起不来。测试对于公司而言,就像法律,是底线,不是高标准。

    2019-08-19
  • 陈斯佳
    交付一个可运行的软件也是终局思维。Effective 和 Efficiency的区别就是前者更重视结果,而后者更在意过程。
    2019-07-11
  • Practice_蚂蚁骨头
    svn和git,写一个接口,自己测试了就提交上去,难道不是日常操作?
    2019-05-30
  • 春之绿野
    有一次为了改进我们的代码,新拉了个分支出来,在开发的过程中,新的功能要在新老两个分支上做两遍,最后合并的时候还要梳理一遍有没有只做在老的分支上的功能,还有个稍微大点的功能是国外的同事开发在老的分支上的,合并过来,太痛苦了

    作者回复: 我一直认为,大分支就是给自己找麻烦。后面还有关于分支的讨论。

    2019-05-05
  • 郑大大的粉丝
    咳咳咳,郑大大你就这么鼓励小朋友们挑战BA吧,就说我们的工作沟通成本越来越多😂

    作者回复: 以行业的平均水准而言,这种行为确实要鼓励。

    2019-04-18
  • we
    集成 是不是 对 编译型语言更实用,对解释型语言 不要重要?

    作者回复: 集成,就是把代码都放到一起跑起来,与什么语言没关系。你说的差异只是提现在编译这个环节。

    2019-03-26
  • 李冬杰
    到现在为止,真心觉得产品该学这个专栏,头脑清楚不糊涂的产品少,能在产品头脑不清晰的时候发现问题的开发也不多

    作者回复: 欢迎把专栏推荐给你的同事!

    2019-03-16
  • Harry
    尽早提交代码!
    2019-03-07
收起评论
31
返回
顶部