10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7975 人已学习
课程目录
已完结 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程序员工作法
登录|注册

24 | 快速反馈:为什么你们公司总是做不好持续集成?

郑晔 2019-02-27
在“以终为始”那个模块,我们留下了一个巨大的尾巴。在“持续集成:集成本身就是写代码的一个环节”这篇文章中,我们是站在“以终为始”的角度阐述了集成,尤其是持续集成的重要性。
但怎么做好持续集成,才是很多人真正关心的内容。今天,我们就来谈谈如何做好持续集成。
既然我们打算讨论持续集成,不妨停下来先思考一个问题:你对持续集成的第一印象是什么。
持续集成?Jenkins?没错,很多人对持续集成第一印象都是持续集成服务器,也就是 CI 服务器,当年是 CruiseControl,今天换成了 Jenkins。
也正是因为如此,很多人就把 CI 服务器理解成了持续集成。我就曾经接触过这样的团队,他们恨不得把所有的事情都放在 CI 服务器上做:在 CI 服务器上做了编译,跑了代码检查,运行了单元测试,做了测试覆盖率的统计等等。
或许你会疑问,这有什么不对的吗?
在做软件这件事上,我们不会用对与错去衡量,我只能说,这种做法是可行的,但它不是最佳实践。我希望你去思考,有没有比这更好的做法呢?
想要回答这个问题,我们还是要回到持续集成的本质上去。持续集成的诞生,就是人们尝试缩短集成周期的结果。为什么要缩短周期呢?因为我们希望尽早得到反馈,知道自己的工作结果是否有效。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(16)

  • 孤星可
    快速反馈这个观点是很赞同的 本地验证这个个人不太看好 以普通 JAVA 项目为例 本地跑一次 耗时以分钟计 这个间隔有点长了

    作者回复: 如果你的本地检查可以在几分钟内完成,那就是可以在本地做的,因为你把它放到 CI 服务器上执行,效果只会更差,而且几分钟时间,稍作调整也并无不可。

    如果时间很长,比如,超过十分钟,根据快速反馈的原则,就要考虑是不是考虑按照测试金字塔划分一下,在本地只跑单元测试。

    但实际情况是,很多团队没有真正的单元测试,造成本地只能运行集成测试,甚至是验收测试,所以,会占据很长时间。

    2019-02-27
    4
  • eyeandroid
    老师,我的意思是其它人的提交被CI检查出错后只会影响他这笔提交,并不会block其它人的提交,所以并不会存在等待其它人修复这个说法,请教下我的理解对吗?因为我工作中遇到的情况是这样

    作者回复: 谁破坏谁修复,CI 红的时候,除了修复的人,任何人不允许提交。这时如果有人已经完成代码准备提交,破坏 CI 的人就是阻塞了它人的工作,所以,要尽快修复。

    2019-02-27
    1
    2
  • eyeandroid
    CI 服务器一旦检查出错,要立即修复。原因很简单,你不修,别人就不能提交,很多人的工作就会因此停顿下来,团队的工作流就会被打断,耽误的是整个团队的工作。

    老师,请教下上面这句话我不太理解。我在工作中遇到的CI是针对某笔提交的,某笔提交被CI服务器检查出错只会影响他这笔的提交,其它人可以继续做检查提交。

    作者回复: 一次一个提交,出错了容易修复,等这次 CI 通过了,下个人再来提交。强调本地检查,就是说,CI 的运行不会影响你在本地工作。把事情做小,做简单,这是我们在任务分解模块的主要观点,前面学的原则,后面也要用啊!

    2019-02-27
    2
  • 西西弗与卡夫卡
    有启发。常遇到的问题是,项目多了以后CI资源吃紧要排队。虽然可以自己用本地多做事,但这有点像“公地悲剧”,只是自己节约还不够,会被别人挤占资源,所以大家抢着上,结果大家都慢。如果有智能CI可以依据以往占用资源的多少来分配CI优先级,或许可以缓解。当然,不差钱的话,增加机器可能更简单

    作者回复: 能花钱解决的事都是小事,一个程序员比一台机器贵多了。

    2019-02-27
    2
  • 如果单元测试做的不到位,或者不满足A-TRIP,是不是执行CI的效果就会弱很多?
    另外在持续集成的过程中,测试人员或者QA有可能参与其中吗?如果能参与的话,对他们的意义以及他们的贡献会是什么?

    作者回复: 说得没错,测试是基础,自动化是基础,CI是一根主线,将诸多实践贯穿起来。

    CI强调自动化,测试人员不需要参与到其中。但测试人员可以拿到生成物去测试,找到的问题以测试的形式补充进来。

    2019-03-01
    1
  • 清菊
    我们遇到的问题是UI测试结果不稳定,这样的话是直接去掉这部分的测试吗?

    作者回复: 难道不是把测试修好,让它稳定下来吗?关于测试应该是什么样,我们在前面讲过。

    2019-02-27
    1
  • Robert小七
    我一直有一个疑问!很多专栏都提到了持续集成,都表达了持续集成中包含自动化测试,我很想知道如果包含了接口和ui的测试,那么持续集成其实也是包括部署环节的。再就是持续集成服务器是监控主干还是分支和主干同时监控?
    2019-12-09
  • 丁丁历险记
    我每天在公司强调的,热手性
    2019-11-14
  • 丁丁历险记
    本质是尽早得到反馈,早发现问题。
    2019-11-14
  • 陈斯佳
    今天这节课老师真的是解决了我一个在工作上一直在思考的大问题,就是之前一直有个执念,想推程序员使用CI服务器来进行构建,但是发现很吃力,现在才知道,其实更好的方法是让他们先在本地进行构建,等代码检查无误再推到ci服务器上,这样子更加科学。
    2019-05-30
  • butterfly
    公司没有CI的,表示瑟瑟发抖
    2019-05-23
  • helloworld
    可视化CI监视器可以了解下
    2019-04-25
  • 虢国技匠
    打卡
    2019-04-06
  • 旭东
    持续集成和持续发布是绑定的,这样只要你发布就必须解决集成问题。
    持续集成之前的代码合并倒是需要更多的约定和规范,好多时候有人强制提交。

    是git分支策略选择,以及代码合并方法也对持续集成有重大影响
    2019-04-03
  • like_jun
    要让团队认识到复盘的重要性。
    让每个人都深入思考项目运作过程中遇到了哪些问题。才能做好复盘。

    作者回复: 可执行的方案是定期回顾,做多了就懂了。

    2019-03-11
  • Xunqf
    我们团队比较小,开发流程比较野路子,都是刚毕业的大学生,没多少开发经验,我们目前的开发流程是: 代码用GitHub托管,然后我们也用到了Jenkins,但是作为一个移动开发来说,对Jenkins的了解还仅限于自动打包工具,由于一开始使用的是手动打包,每次打一个包都要费好长时间,后来了解到自动打包,就很公司申请了一台电脑,用Jenkins搭建了一个自动打包服务器,然后定时去GitHub拉取代码打包,打包成功后上传蒲公英,然后发邮件通知下载,还不存在老师说的出错了就影响其他人提交的问题,感觉我们的持续集成是在GitHub上,缺失了测试环节。听老师讲完感觉我们做的太简单了,但是老师说的这些服务公司根本就没有,现有的这么简单的东西还是我们自己抽时间搞的,但是我们的主要任务毕竟是开发公司的业务产品,而Jenkins持续集成服务也非我专长,不太可能花太多精力去做这个。这个时候我该怎么办?

    作者回复: 其实,CI 不应该占用那么长时间,在构建脚本里写好打包过程,在 CI 服务器上调用一下就好了。至于 CI 监视器,网上有很多,找一个现成的拿来用就好了。

    2019-03-03
收起评论
16
返回
顶部