24-快速反馈：为什么你们公司总是做不好持续集成？
这篇讲的内容是，为了快速集成，就需要解决 CI 比较慢的问题。针对这个问题，作者提出将检查放到本地去运行。作者认为，本地进行单测等检查耗时相对 CI 服务器会更短一点
想做好持续集成的一个关键点是，用好本地构建脚本（build script），保证各种各样的检查都可以在本地环境执行。
至于什么样的内容适合放在构建脚本里，这个话题我们先放一放，把它留到后续“自动化”模块再做讨论。
每完成一个任务，在本地运行构建脚本，如果有问题，就修复；没问题，则可以同步代码。如果 CI 服务器上没有正在运行的服务，就可以提交代码了。
当团队真正地实施起持续集成，你会发现随着时间增加，本地检查的时间会越来越长。原因有很多，比如，代码越来越多，测试也越来越多。总之，检查的时间长了，就会对集成的速度造成影响。
这个时候，本着快速反馈的理念，我们就必须想办法。比如，有的团队做了分布式测试运行，有的团队将测试分类，就是我们在测试金字塔中讲到的分类，在本地执行单元测试和集成测试，而把更复杂的系统测试放到 CI 服务器上运行。
如果本地和 CI 服务器上执行的是一样的脚本，我在本地通过了，还用关心 CI 服务器的反馈吗？
当然要。因为还会出现很多其他问题，比如说最简单的一种情况是，你漏提交了一个文件。
好，既然我们要关注 CI 服务器的反馈，下一个问题就是，它怎么反馈给我们呢？
我们还是从一种常见的错误入手。有些团队做持续集成用的反馈方式是什么呢？答案是邮件。
以邮件进行反馈，问题出在哪里呢？很明显，邮件不是一种即时反馈的工具。
展示屏显示出来 or 直接通讯软件进行提醒。
25-自我复盘，开发中的问题一再出现，应该怎么办？
回顾会议是一个常见的复盘实践，定期回顾是一个团队自我改善的前提。回顾会议怎么开呢？我给你分享我通常的做法。
作为组织者，我会先在白板上给出一个主题分类。我常用的是分成三类：“做得好的、做得欠佳的、问题或建议”。
还有不同的主题分类方式，比如海星图，分成了五大类：“继续保持、开始做、停止做、多做一些、少做一些”五类。
我会给与会者五分钟时间，针对这个开发周期内团队的表现，按照分类在便签上写下一些事实。比如，你认为做得好的是按时交付了，做得不好的是 Bug 太多。
这里面有两个重点。一个是写事实，不要写感受。因为事实就是明摆在那里的东西，而感受无法衡量，你感觉好的东西，也许别人感觉很糟糕。
另外，每张便签只写一条，因为后面我要对便签归类。因为大家是分头写的，有可能很多内容是重复的，所以，要进行归类。
五分钟之后，我会号召大家把自己写的便签贴到白板上。等大家把便签都贴好了，我会一张一张地念过去。
这样做是为了让大家了解一下其他人都写了些什么，知道不同人的关注点是什么。一旦有哪一项不清楚，我会请这张便签的作者出来解释一下，保证大家对这个问题的理解是一致的。在念便签的同时，我就顺便完成了便签归类的工作。
等到所有的便签都归好类，这就会成为后续讨论的主题，与会者也对于大家的关注点和看到的问题有了整体的了解。
做得好的部分，是大家值得自我鼓励的部分，需要继续保持。而我们开回顾会议的主要目的是改善和提升，所以，我们的重点在于解决做得不好的部分和有问题出现的地方。
在开始更有针对性的讨论之前，我会先让大家投个票，从这些分类中选出自己认为最重要的几项。我通常是给每人三票，投给自己认为重要的主题。每个人需要在诸多内容中做出取舍，你如果认为哪一项极其重要，可以把所有的票都投给这个主题。
根据大家的投票结果，我就会对所有的主题排出一个顺序来，而这就是我们要讨论的顺序。我们不会无限制的开会，所以，通常来说，只有最重要的几个主题才会得到讨论。
无论是个人选择希望讨论的主题，还是团队选择最终讨论的主题，所有人都要有“优先级”的概念在心里。然后，我们就会根据主题的顺序，一个一个地进行讨论。
讨论一个具体的主题时，我们会先关注现状。我会先让写下反馈意见的人稍微详细地介绍他看到的现象。比如，测试人员会说，最近的 Bug 比较多，相比于上一个开发周期，Bug 增加了 50%。
然后，我会让大家分析造成这个现象的原因。比如，有人会说，最近的任务量很重，没有时间写测试。
再下来，我们会尝试着找到一个解决方案，给出行动项。比如，任务重，我们可以让项目经理更有效地控制一下需求的输入，再把非必要的需求减少一下；测试被忽略了，我们考虑把测试覆盖率加入构建脚本，当测试覆盖率不足时，就不允许提交代码。
请注意，所有给出的行动项应该都是可检查的，而不是一些无法验证的内容。比如，如果行动项是让每个程序员都“更仔细一些”，这是做不到的。因为“仔细”这件事很主观，你说程序员不仔细，程序员说我仔细了，这就是扯皮的开始。
而我们上面给出的行动项就是可检查的，项目经理控制输入的需求，我们可以用工作量衡量，还记得我们在讨论用户故事中提到的工作量评估的方式吗？
控制工作量怎么衡量？就是看每个阶段开发的总点数是不是比上一个阶段少了。而测试覆盖率更直接，直接写到构建脚本中，跑不过，不允许提交代码。
好，列好了一个个的行动项，接下来就是找责任人了，责任人要对行动项负责。
比如，项目经理负责需求控制，技术负责人负责将覆盖率加入构建脚本。有了责任人，我们就可以保障这个任务不是一个无头公案。下一次做回顾的时候，我们就可以拿着一个个的检查项询问负责人任务的完成情况了。
5whys 探寻最根本出问题的原因
- 为什么会出现 504 呢？因为服务器处理时间比较长，超时了。
- 为什么会超时呢？因为服务器查询后面的 Redis 卡住了。
- 为什么访问 Redis 会卡住呢？因为另外一个更新 Redis 的服务删除了大批量的数据，然后，重新插入，服务器阻塞了。
- 为什么它要大批量的删除数据重新插入呢？因为更新算法设计得不合理。
- 为什么一个设计得不合理的算法就能上线呢？因为这个设计没有按照流程进行评审。
分享一个我现在每天在对自身进行复盘的方法。我每天会通过 5 个方面来分析过去的一天自己的学习成长。第 1 个方面是身体，也就是我的身体健康，其中包括运动，饮食，睡眠，还有冥想。因为好的身体，才是一切的动力来源。第 2 个的方面是关于认知和学习，其中包括比如像通过极客时间专栏的学习，对认知的提升，还有英语的学习和技术的学习。第 3 个方面是工作生活，工作主要是对前一天工作的总结，并且提炼出成就事件和需要改进的方面，生活主要吗，因为还单身，所以也没啥生活……这一块留给以后的家庭生活使用。第 4 个方面关系心理，也就是如何和自我相处，如何和他人相处，如何维持好的人际关系。最后一个是理财，也就是自己在理财知识方面的学习和一些理财实践。每天早上几乎都会在这 5 个方面进行一些复盘，我自己会把它形象化，想象出是 5 个部门的经理，自己就像是一个 CEO 一样，每天听取 5 个部门经理的汇报，其实感觉也挺有意思的。
关于复盘，孙陶然曾经说过，如果他有所成就，一半要归功于复盘。他提出了几个步骤供大家参考。首先，先对比实际结果和期初所定目标之间有什么差距。其次，情景再现，回顾项目的几个阶段。然后，对每个阶段进行得失分析，找出问题原因。最后，总结规律，化作自己的技能沉淀，再次遇到时可以规避。我再补充一点，复盘资料应该记录到知识库，无论新来的或是接手的人，都能从中获益，从而提升组织的能力。另外，好的复盘需要有坦诚的文化氛围，不然有可能变成互相指责甩锅，就失去了意义
极客时间-跟着高手学复盘
跟着高手学复盘_复盘_总结_管理_团队_项目_成长_晋升-极客时间
用户故事-站在前人的肩膀上，领取属于你的高效工作秘籍
对于高效工作有哪些心得？
能用尽可能小的时间颗粒度来安排自己的工作。
高效工作，如果按字面理解，就是在指定时间里能完成更多的工作（当然还得是合格的工作）。《五分钟商学院》的作者刘润老师曾提到过时间颗粒度的概念，你会发现，很多成功人士划分时间的颗粒度都比较小。王健林的时间颗粒度是十五分钟，比尔盖茨的时间颗粒度是五分钟。
你可以思考一下，你是按什么颗粒度来安排自己工作的呢？1 天，半天，1 小时还是 15 分钟？
工作习惯的培养
程序员的工作习惯不仅仅是每天上班打开邮箱，提交代码前编译通过等等事务性习惯，还包括：你的思维方式是否合适，由此产生的执行方式是否到位，检验方式是否科学，理论修正是否能产生更好的思维方式。
就像专栏中讲精益创业时，提到的“想法 → 产品 → 数据”对应的“开发 → 测量 → 认知”这样的反馈模型。
30-一个好的项目自动化应该是什么样子的？
https://freegeektime.com/100022301/86561/
一个好的项目自动化应该是什么样子的？
今天，我们以一个典型的 Java REST 服务为例，介绍一下最基本的构建脚本应该做到什么样子。这里我采用的 Java 技术中最为常见的 Spring Boot 作为基础框架，而构建工具，我选择了 Gradle。
估计很多 Java 程序员心中的第一个问题就是，为什么用 Gradle，而不是 Maven？Maven 明明是 Java 社区最经典的构建工具。答案是因为 Maven 不够灵活。
你可以回想一下，你有多少次用 Maven 实现过特定需求？估计大部分人的答案都是没有。随着持续集成、持续交付的兴起，构建脚本的订制能力会变得越来越重要，Maven 则表现得力有不逮。
今天，我们以一个典型的 Java REST 服务为例，介绍一下最基本的构建脚本应该做到什么样子。这里我采用的 Java 技术中最为常见的 Spring Boot 作为基础框架，而构建工具，我选择了 Gradle。
估计很多 Java 程序员心中的第一个问题就是，为什么用 Gradle，而不是 Maven？Maven 明明是 Java 社区最经典的构建工具。答案是因为 Maven 不够灵活。
你可以回想一下，你有多少次用 Maven 实现过特定需求？估计大部分人的答案都是没有。随着持续集成、持续交付的兴起，构建脚本的订制能力会变得越来越重要，Maven 则表现得力有不逮。
怎么打开这个项目呢？我们先用 Gradle 命令生成一个 IDEA 工程。
TODO
对于一个好的项目自动化应该是什么样子这个问题，西西弗与卡夫卡 同学提到：
设想过这样的情景（还没实现，打算实践一把）：我们新招一名比较熟练的程序员，从 TA 入职拿到机器，到开发示意代码，再提交 SCM，然后 CI/CD，再发布到线上交付给用户，整个过程可以在入职当天的午饭之前完成。
这不光要求构建和集成自动化，甚至要求从入职开始的各个环节都能提前准备好，包括机器、开发环境、线上环境等，甚至连示范的需求都要能及时传递给 TA。理想情况下，程序员只需要开发好程序，保证质量，提交到 SCM 即可，其他事情都应该交给机器。
31-程序员怎么学习运维知识？
答疑解惑-持续集成，一条贯穿诸多实践的主线
想做好 CI，首先要有可检查的东西，什么是可检查的东西，最简单的就是编译、代码风格检查，这些检查可以无条件加入构建脚本。但更重要的检查，应该来自于测试，而要想做好 CI，我们要有测试防护网。
问题 2：老板参加复盘，不敢说真话怎么办？
怎么设置一个安全的环境呢？对于标准的回顾会议来说，第一步应该是做安全性检查。
先由大家投票，最简单的方式是就是，给当前的环境打分。你觉得可以畅所欲言就打 1 分，你觉得还好，就打 0 分，如果你觉得不方便表达，比如，你看领导在，很多问题不适合反馈，就打 -1。
每个与会者都投出属于自己的一票。然后，主持人根据投票结果决定回顾会议是否进行，比如，有人投 -1 就不能继续。
会议能继续固然好，一旦会议不能继续，可以有多种解决方案。比如，把在场职位最高的人请出去，这个人可能就是老板。老板也许心里很不爽，但在这个过程中，大家都是按照规则在办事，并不存在对谁另眼相待的情况。
当老板离席之后，我们再进行一轮投票，判断环境是否变得安全了。如此反复，也许要进行几轮投票，直到大家觉得安全了。
当然，也有可能进行多轮，有人始终觉得不安全，那可能最好的选择是，取消今天的回顾会议，换个时间地点从头再来。而项目负责人则需要私下里解决一下团队内心安全的问题。
32-持续交付：有持续集成就够了吗？
33-如何做好验收测试？
答疑解惑-持续集成、持续交付，然后呢？
划重点-“自动化”主题的重点内容回顾汇总
请谨慎地将工作自动化。
——《29 | “懒惰”应该是所有程序员的骄傲》
将你的工作过程自动化。
——《30 | 一个好的项目自动化应该是什么样子的？》
有体系地学习运维知识。
——《31 | 程序员怎么学习运维知识？》
将部署纳入开发的考量。
——《32 | 持续交付：有持续集成就够了吗？》
将验收测试自动化。
——《33 | 如何做好验收测试？》
39-面对遗留系统，你应该这样做
说到遗留代码和测试，我推荐一本经典的书：Michael Feathers 的《修改代码的艺术》（Working Effectively with Legacy Code），从它的英文名中，你就不难发现，它就是一本关于遗留代码的书。如果你打算处理遗留代码，也建议你读读这本书。
在 2007 年，我就给这本书写了一篇书评，我将它评价为“这是一本关于如何编写测试的书”，它会教你如何给真实的代码写测试。
我在《36 | 为什么总有人觉得 5 万块钱可以做一个淘宝？》中提到，淘宝将系统改造成 Java 系统的升级过程，就是将业务分成若干的小模块，每次只升级一个模块，老模块只维护，不增加新功能，新功能只在新模块开发，新老模块共用数据库。新功能上线，则关闭老模块对应功能，所有功能替换完毕，则老模块下线。
这个道理是普遍适用的，差别只是体现在模块的大小上。如果你的“小模块”是一个系统，那就部署新老两套系统，在前面的流量入口做控制，逐步把流量从老系统转到新系统上去；如果“小模块”只在代码层面，那就要有一段分发的代码，根据参数将流程转到不同的代码上去，然后，根据开发的进展，逐步减少对老代码的调用，一直到完全不依赖于老代码。
想到了之前 PK-Platform 重构到 Leaderboard 时候，也是类似的，根据参数将流程转到不同的代码上去。
改造遗留系统，我给你几个建议：
构建测试防护网，保证新老模块功能一致；
分成小块，逐步替换；
构建好领域模型；
寻找行业中关于系统构建的最新理解。