10x程序员工作法笔记

程序员与产品经理的关系是 IT 行业一个经典的话题。许多程序员都会倾向于不问为什么就接受来自产品经理的需求，然后暗自憋气。

比较早成型的面向不确定创造新事物的方法论是精益创业，它提出了“开发（build）- 测量（measure）- 认知（learn）”这样一个反馈循环和最小可行产品的概念。

当产品经理让我们做一个新的产品特性时，我们可以从精益创业这个实践上得到启发，向产品经理们问一些问题，帮助我们确定产品经理提出的需求确实是经过严格思考的。

如果今天的内容你只记住一件事，那请记住： 默认所有需求都不做，直到弄清楚为什么要做这件事 。

程序员总喜欢用技术去解决一切问题，但很多令人寝食难安的问题其实根本不是问题。之所以找不出更简单的解决方案，很多时候原因在于程序员被自己的思考局限住了。

不同角色工作真正的差异在于上下文的差异。在一个局部上下文难以解决的问题，换到另外一个上下文甚至是可以不解决的。所以说无论单点有多努力也只是局部优化，很难达到最优的效果。

想把工作做好，就需要不断扩大自己工作的上下文，多了解一下别人的工作逻辑是什么样的，认识软件开发的全生命周期。

扩大自己的上下文，除了能对自己当前的工作效率提高有帮助，对自己的职业生涯也是有好处的。随着你看到的世界越来越宽广，得到的机会也就越来越多。

如果今天的内容你只记住一件事，那请记住： 扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上。

即便已经确定了自己的工作目标，我们依然要在具体动手之前，把实施步骤推演一番，完成一次头脑中的创造，也就是第一次创造或智力上的创造。这种思想在军事上称之为沙盘推演，在很多领域都有广泛地应用。

在软件开发过程中，我们就假设软件已经就绪，看就绪之后，要做哪些事情，比如，如何上线、如何推广等等，这样的推演过程会帮我们发现前期准备的不足之处，进一步丰富我们的工作计划。为了不让我们总在“最后一公里”摔跟头，前期的推演是不可或缺的，也是想让团队进入有条不紊状态的前提。

如果今天的内容你只记住一件事，那请记住： 在动手做一件事之前，先推演一番。

随着智能时代的来临，人类社会开始逐渐认识到数据的重要性。但我们这群 IT 人在通过数据为其他人服务的同时，却很少把数字化的思维带到自己的工作范围内。这也是工作中很多“空对空”对话的根源所在。

结合着“以终为始”的思考，如果我们可以在一开始，就设计好测量工作有效性的指标，那么就可以更有目的性地去工作了。

而如果我们习惯了用数字去思考，就可以在很多方面让数字帮助我们。我举了几个小例子，比如：基于数据进行技术决策、预先设定系统指标，以及发现系统中的问题等等。希望你也可以把数字思维带到你的日常工作中。

如果今天的内容你只记住一件事，那请记住： 问一下自己，我的工作是不是可以用数字衡量。

在这个模块中，我们学习到了一些行业最佳实践。

• DoD，确定好完成的定义，减少团队内部的理解不一致。
• 用户故事，细化出有价值的需求。
• 持续集成，通过尽早集成，减少改动量，降低集成的难度。
• 精益创业，减少过度开发不确定性产品带来的浪费。
• 迭代 0，在项目开始之前，做好一些基础准备。

还学习到一些重要的思维转变。任何事物都要经过两次创造：

• 一次是在头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation），然后才是付诸实践，也就是实际的构建或第二次创造（Physical/Second Creation）。
• 在更大的上下文内发现自己的“终”。
• 通过推演，找到通往“终”的路径。用可度量的“数字”定义自己的“终”。

在每一篇文章的结尾，我们还将全篇内容浓缩为“一句话”的实战指南，希望你可以迅速上手，把“以终为始”的原则运用在实际工作之中，我们一起来回顾一下这些实战指南。

• 遇到事情，倒着想。——《02 | 以终为始：如何让你的努力不白费？》
• 在做任何事之前，先定义完成的标准。——《03 | DoD 的价值：你完成了工作，为什么他们还不满意？》
• 在做任何需求或任务之前，先定好验收标准。——《04 | 接到需求任务，你要先做那件事？》
• 尽早提交代码去集成。——《05 | 持续集成：集成本身就是写代码的一个环节》
• 默认所有需求都不做，直到弄清楚为什么要做这件事。——《 06 | 精益创业：产品经理不靠谱，你该怎么办？》
• 扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上。——《07 | 解决了很多问题，为什么你依然在“坑”里？》
• 在动手做一件事之前，先推演一番。——《08 | 为什么说做事之前要先进行推演？》
• 问一下自己，我的工作是不是可以用数字衡量。——《09 | 你的工作可以用数字衡量吗？》
• 设计你的迭代 0 清单，给自己的项目做体检。——《10 | 启动开发之前，你应该准备什么？》

在这个部分的最后，针对大家在学习过程中的热门问题，我也进行了回答，希望你懂得：

• 作为程序员，你可以管理你的上级；
• 拿老板说事的产品经理，你可以到老板面前澄清；
• 喜欢无脑抄袭的产品经理，让他回去先想清楚到底抄的是什么；
• 分清楚需求和技术，产品经理和开发团队各自做好各自的事。——《答疑解惑 | 如何管理你的上司？》

我们从外星人探索和马斯克的火星探索入手，介绍了任务分解在人类社会诸多方面的应用，引出了分而治之这个人类面对复杂问题的基本解决方案。接着，我给你讲了这一思想在软件开发领域中的一个常见应用，分而治之的算法。

虽然我们很熟悉这一思想，但在日常工作中，我们却没有很好地应用它，这也使得大多数人的工作有很大改进空间。运用这一思想的难点在于，给出一个可执行的分解。

一方面，对复杂工作而言，给出一个分解是巨大的挑战；另一方面，面对日常工作，人们更容易忽略的是，分解的任务要可执行。每个人对可执行的理解不同，只要你清楚地知道接下来的工作该怎么做，任务分解就可以告一段落。

大多数人对于可执行的粒度认识是不足的，低估了任务分解的程度，做到好的分解你需要达到“微操作”的程度。有了分解得很小的任务，我们就可以很容易完成一个开发循环，也就让计划调整成为了可能。软件行业在倡导拥抱变化，而任务分解是拥抱变化的前提。

如果今天的内容你只记住一件事，那么请记住： 动手做一个工作之前，请先对它进行任务分解。

测试是软件开发重要的组成部分，测试应该是软件开发团队中所有人的事，而不仅仅是测试人员的事。因为软件变更成本会随着时间和开发阶段逐步增加，能在早期解决的问题，就不要将它延后至下一个阶段。

在测试问题上，程序员有着天生的优势，会写代码，于是，程序员拥有了一个突出的强项，自动化测试。写测试应该是程序员工作完成的重要组成部分。

随着人们对于测试理解的加深，各种各样的测试都出现了，也开始有了测试的分类：单元测试、集成测试、系统测试等等。越在底层测试，成本越低，执行越快；越在高层测试，成本越高，执行越慢。

人的时间和精力是有限的，所以，人们开始思考不同的测试如何组合。在这个方面的最佳实践称之为测试金字塔，它强调的重点是，越底层的测试应该写得越多。只有按照测试金字塔的方式写测试，持续集成才能更好地发挥作用。

如果今天的内容你只能记住一件事，那请记住： 多写单元测试。

一些优秀的程序员不仅仅在写测试，还在探索写测试的实践。有人尝试着先写测试，于是，有了一种实践叫测试先行开发。还有人更进一步，一边写测试，一边调整代码，这叫做测试驱动开发，也就是 TDD。

从步骤上看，关键差别就在，TDD 在测试通过之后，要回到代码上，消除代码的坏味道。

测试驱动开发已经是行业中的优秀实践，学习测试驱动开发的第一步是，记住测试驱动开发的节奏：红——绿——重构。把测试放在前面，还带来了视角的转变，要编写可测的代码，为此，我们甚至需要调整设计，所以，有人也把 TDD 称为测试驱动设计。

如果今天的内容你只能记住一件事，那请记住： 我们应该编写可测的代码。

Kent Beck 的做法清晰而有节奏，每个任务完成之后，代码都是可以提交的。 看上去很简单，但这是大多数程序员做不到的。

只有把任务分解到很小，才有可能做到小步提交。你能把任务分解到很小，其实是证明你已经想清楚了。 而大多数程序员之所以开发效率低，很多时候是没想清楚就动手了。

很多人看了一些 TDD 的练习觉得很简单，但自己动起手来却不知道如何下手。中间就是缺了任务分解的环节。

随着我在任务分解上练习的增多，我越发理解任务分解的关键在于： 小。

小到什么程度呢？有时甚至可以小到你可能认为这件事不值得成为一件独立的事。比如升级一个依赖的版本，做一次变量改名。

这样做的好处是什么呢？它保证了我可以随时停下来。

我们知道，养成一个习惯，最难的是坚持。 如果你有了一个微习惯，坚持就不难了。

一个经过分解后的任务，需要关注的内容是有限的，我们就可以针对着这个任务，把方方面面的细节想得更加清晰。 很多人写代码之所以漏洞百出，一个重要的原因就是因为任务粒度太大。

经过这种练习之后，任务分解也就成了我的本能，不再局限于写程序上。我遇到任何需要解决的问题，脑子里的第一反应一定是，它可以怎么一步一步地完成，确定好分解之后，解决问题就是一步一步做了。

如果不能很好地分解，那说明我还没想清楚，还需要更多信息，或者需要找到更好的解决方案。

TDD 在很多人眼中是不实用的，一来他们并不理解测试“驱动”开发的含义，但更重要的是，他们很少会做任务分解。而任务分解是做好 TDD 的关键点。只有把任务分解到可以测试的地步，才能够有针对性地写测试。

同样听到任务分解这个说法，不同的人理解依然是不一样的。我把任务分解的结果定义成微操作，它远比大多数人理解得小。我们能将任务分解到多小，就决定了我们原子操作的粒度是多大。软件开发中的许多问题正是由于粒度太大造成的，比如，分支策略。

如果今天的内容你只能记住一件事，那请记住： 将任务拆小，越小越好。

既然无法用写程序的方式保证测试的正确性，我们只有一个办法： 把测试写简单，简单到一目了然，不需要证明它的正确性。 所以，如果你见到哪个测试写得很复杂，它一定不是一个好的测试。

我把这段代码分成了四段，分别是 前置准备、执行、断言和清理 ，这也是一般测试要具备的四段。

很多人总想在一个测试里做很多的事情，比如，出现了几个不同方法的调用。请问，你的代码到底是在测试谁呢？

这个测试一旦出错，就需要把所有相关的几个方法都查看一遍，这无疑是增加了工作的复杂度。

也许你会问，那我有好几个方法要测试，该怎么办呢？很简单，多写几个测试就好了。

另一个典型“坏味道”的高发区是在断言上，请记住， 测试一定要有断言。 没有断言的测试，是没有意义的，就像你说自己是世界冠军，总得比个赛吧！

还有一种常见的“坏味道”：复杂。最典型的场景是，当你看到测试代码里出现各种判断和循环语句，基本上这个测试就有问题了。

你或许会疑问，我有一大堆不同的数据要测，不用循环不用判断，我怎么办呢？ 你真正应该做的是，多写几个测试，每个测试覆盖一种场景。

怎么样的测试算是好的测试呢？有人做了一个总结 A-TRIP，这是五个单词的缩写，分别是

• Automatic，自动化；
• Thorough，全面的，应该尽可能用测试覆盖各种场景；
• Repeatable，可重复的；
• Independent，独立的；
• Professional，专业的。

测试是一个说起来很简单，但很不容易写好的东西。在实际工作中，很多人都会遇到关于测试的各种各样问题。之所以出现问题，主要是因为这些测试写得太复杂了。测试一旦复杂了，我们就很难保证测试的正确性，何谈用测试保证代码的正确性。

我给你讲了测试的基本结构：前置准备、执行、断言和清理，还介绍了一些常见的测试“坏味道”：做了太多事的测试，没有断言的测试，还有一种看一眼就知道有问题的“坏味道”，测试里有判断语句。

怎么衡量测试是否做好了呢？有一个标准：A-TRIP，这是五个单词的缩写，分别是 Automatic（自动化）、Thorough（全面）、Repeatable（可重复的）、Independent（独立的）和 Professional（专业的）。

如果今天的内容你只能记住一件事，那请记住： 要想写好测试，就要写简单的测试。

评价用户故事有一个“ INVEST 原则”，这是六个单词的缩写，分别是：

• Independent，独立的。
• Negotiable，可协商的。
• Valuable，有价值的。
• Estimatable，可估算的。
• Small，小。
• Testable，可测试的。

“INVEST 原则”的说法是为了方便记忆，我们这里着重讨论两个点。

第一个关注点是可协商。作为实现者，我们要问问题。只是被动接受的程序员，价值就少了一半，只要你开始发问，你就会发现很多写需求的人没有想清楚的地方。

在我的职业生涯中，我无数次将需求挡了回去，不是我不合作，而是我不想做一些糊涂的需求。我之所以能问出问题，一方面是出于常识，另一方面就是这里说的用户故事是否有价值。 用户故事，之所以是故事，就是要讲，要沟通。

还有一个更重要的关注点，也是这个模块的核心：小。无论是独立性也好，还是可估算的也罢，其前提都是小。只有当用户故事够小了，我们后续的腾挪空间才会大。

估算的结果是相对的，不是绝对精确的，我们不必像做科研一样，只要给出一个相对估算就好。

软件开发中，需求管理是非常重要的一环。在需求管理上常见的错误是，需求管理的粒度太大，很多团队几乎是在用一个大主题在管理需求，这就让需求调整的空间变得很小。

结合用户故事，我给你讲了一个好的需求管理基本单位是什么样子的，它要符合“INVEST 原则”。其中的一个关键点是“小”，只有小的需求才方便管理和调整。

什么样的需求才算小呢？我给你介绍了一种需求估算的方式，每个团队都可以根据自己的特点决定在自己的团队里，多大的需求算大。大需求怎么办？只要再进行分解就好了。

如果今天的内容你只能记住一件事，那请记住： 想要管理好需求，先把需求拆小。

就凭一句“老板说的”，我们就可以判断出，产品经理缺乏对需求管理应有的理解。

按照时间管理的理念，重要且紧急的事情要立即做。重要但不紧急的事情应该是我们重点投入精力的地方。紧急但不重要的事情，可以委托别人做。不重要不紧急的事情，尽量少做。

这个矩阵带给我们思维上最大的改变是，让人意识到事情和事情不是等价的。 如果不把精力放在重要的事情上，到最后可能都变成紧急的事情。

当员工想不明白的事，换成老板的视角就全明白了。

需求分解之后，最重要的是，排列需求的优先级。优先级的排列方式有很多，我们可以借鉴时间管理的方法，把事情按照重要和紧急的维度进行划分，得到了四个象限。我们要尽可能把精力放在重要的事情上，而不是把紧急的事情当成优先级排序的方式。

需求分解成一个个小块，其实也分解了原本合一的上下文。如果想要有效地管理需求，尤其是确定事情的重要程度，一种方式是找回丢失的上下文。如果我们自己无法判断上下文，一种好的办法是，引入外部更大的上下文。

如果今天的内容你只能记住一件事，那请记住： 尽量做最重要的事。

首先，我们必须清楚一件事， 我们要做的是验证一个想法的可行性，甚至不是为了开发一个软件，开发软件只是一种验证手段。

不知道你注意到了没有，迄今为止， 这个团队验证了一大堆的想法，而代码却是一行都没有写，所有花费的工作量都是有针对性的验证。

但从产品可行的角度，我们需要转换一下思路， 不是一个模块做得有多完整，而一条用户路径是否通畅。

和大家分享这个例子，主要是想破除大家对于一个“完整”系统概念的认识。 当时间有限时，我们需要学会找到一条可行的路径，在完整用户体验和完整系统之间，找到一个平衡。

产品同样需要分解，目前在探索产品的不确定性上的最佳实践是精益创业，而精益创业就包含了将庞大的产品分而治之的方式：最小可行产品（Minimum Viable Product，MVP）。最小可行产品就是“刚刚好”满足客户需求的产品。

想要在实践中运用好最小可行产品的理念，就是要用最小的代价找到一条可行的路径。 最小的代价就是能不做的事就不做，能简化的事情就简化。

程序员通常愿意用自己的代码解决问题，而写代码通常是代价非常高的解决方案，它应该成为最后的产品解决方案。

可行的路径，是一条完整的用户体验路径，至少在用户眼中是这样的。我们常常会想给客户一个完整的系统，但在时间有限的情况下，我们必须学会分解。

如果今天的内容你只能记住一件事，那请记住： 做好产品开发，最可行的方式是采用 MVP。

在这个部分的最后，针对大家在学习过程中的热门问题，我也进行了回答，希望你懂得：

• 对不了解技术的任务，先要去了解技术，然后再做任务分解；
• 通过一次技术 Spike ，学习新技术；
• 丢弃掉在 Spike 过程中开发的原型代码；
• 分清目标与现状，用目标作为方向，指导现状的改变；
• 多个功能并行开发可以考虑使用 Feature Toggle；
• 在遗留系统上做改造可以考虑使用 Branch by Abstraction 。

人生不如意之事，十有八九，之所以很多人有如此多的不如意，很大原因在于我们对真实世界有着很多不切实际的幻想，美好的愿望并不能驱动这个世界，在软件开发中也是如此。虽然人和人生活在一个世界中，但对世界的理解却是千差万别的。

我们借用了信息论的一个通信模型解释为什么每个人看到的世界会有如此大的差异，其核心就在于，人和人拥有不同的编解码器。想要在这个真实世界中生活得更幸福一些，需要我们不断地改善自己的编解码器。

改善编解码，需要从几个角度着手，分别是：编码器，让信息能输出更准确；解码器，减少信号过滤，改善解码能力；还有编解码算法，也就是各种来自行业的“最佳实践”，协调沟通的双方。

如果今天的内容你只能记住一件事，那请记住： 通过沟通反馈，不断升级自己的编解码能力。

名字起得是否够好，一个简单的评判标准是，拿着代码给人讲，你需要额外解释多少东西。

但是，我们写代码的目的是与人沟通，因为我们要在一个团队里与人协同工作。

人要负责将业务问题和机器执行连接起来，缺少了业务背景是不可能写出好代码的。

代码是程序员与机器沟通的桥梁，写好代码是每个程序员的追求，一个专业程序员，追求的不仅是实现功能，还要追求代码可维护。如果你想详细学习如何写好代码，我推荐你去读 Robert Martin 的《代码整洁之道》（Clean Code），这本书几乎覆盖了把代码写好的方方面面。

命名，是写程序中最基础，也是一个程序员从业余走向专业的门槛。我以命名为基础，给你解释了写好代码的提升路径。最初的层次是编写可以运行的代码，然后是编写符合代码规范的代码。

对于命名，最粗浅的理解是不要起无意义的名字，遵循编码规范。但名字起得是否够好，主要看是否还需要额外的解释。很多程序员起名字习惯于采用面向实现的名字，比如，采用数据结构的名字。

再进一步提升，编写代码是要写出人可以理解的代码。因为代码更重要的作用是人和人沟通的桥梁，起一个降低其他人理解门槛的名字才是好名字。

实际上，我们很多没写好的程序有一些原因就是名字起错，把一些概念混淆在一起了。想起好名字，就要学会用业务语言写代码，需要尽可能多地学习业务知识，把业务领域的名字用在代码中。

如果今天的内容你只能记住一件事，那请记住： 用业务的语言写代码。

开会是为了解决问题，但真实情况却是开了会又没有解决多少问题，这真是一个奇特的矛盾。

回想一下，你参加过的会议里面，有没有效果特别好的呢？在我职业生涯中， 凡是效果特别好的会议，基本上都是用来做信息同步的。

那效果不好的会议是什么样呢？几乎都是那些讨论会，你一言我一语，每个会几乎无一例外，都有几个擅长打岔的，这个会基本上都会跑偏，时间就会这样一分一秒地流逝了。

用开会这种重量级的方式讨论问题，就好比杀鸡用了牛刀，这是不恰当的。那该怎么解决这个问题呢？很简单，杀鸡用鸡刀。

实际上，真正在会议上能够积极参与讨论的人并不会觉得会议是浪费时间，因为高度参与其中，人是进入到心流状态的，时间流逝很快。觉得浪费时间的，往往是没有参与其中的人。

换句话说，会议之所以给人留下如此不堪的印象，一个重要的原因是，真正参与讨论的人并不多。所以，我们换个角度思考一下，只要把这些真正参与讨论的人拉到一起讨论不就好了？

所以，改善会议的第一个行动项是，减少参与讨论的人数。

所以，我们的第二个行动项是，如果你要讨论，找人面对面沟通。

我前面说过了，开会并非都是不好的，一些信息同步的会还是有必要的。

举个例子，有一种实践叫站会（Standup）。很多公司都在实践它，站会甚至成为每天的开工仪式。一般的做法是，早上大家来上班了，先开一个站会，让大家同步一下昨天的工作，然后开始今天的工作。

在总长固定的情况下，每个人发言的时间一定是有限的。在有限的时间内，你能说什么呢？我建议你只说三件事：

• 我昨天做了什么？
• 我今天打算做什么？
• 我在过程中遇到了什么问题，需要请求帮助。

开会是很多程序员的困扰，太多的会议甚至会影响到你工作的进展。开会的本意是为了解决问题，但实际上，大多数会议并不能很好地解决问题。因为会议是一种重量级的沟通方式，很多人参加会议时，并不能很好地参与其中。

如果你想用会议的形式与别人讨论问题，最好放弃这种打算，面对面的沟通是最好的方式。因为面对面沟通很轻，人数相对少，每个人参与度就会高很多。基于这种改进，我们可以把大部分会议都改成信息同步的会，效率就会得到提高。

我还给你介绍了一种特殊的会议：站会。之所以采用站会的方式，就是要控制时间。在站会上每个人说什么，我给了你一个建议的格式：

• 我昨天做了什么？
• 我今天打算做什么？
• 我在过程中遇到了什么问题，需要请求帮助。

如果你经常组织别人开会，请你想一下，是不是自己没有利用好开会这件事；如果你经常被别人组织开会，不妨把这篇文章转发给他，让他别总是开会“讨论”问题。

如果今天的内容你只能记住一件事，那请记住： 多面对面沟通，少开会。

ThoughtWorks 技术雷达是由 ThoughtWorks 技术咨询委员会（Technology Advisory Board）编写的一份技术趋势报告，每 6 个月发布一次。ThoughtWorks 的项目多样性足够丰富，所以它能够发现诸多技术趋势。因此，相比于行业中其它的预测报告，技术雷达更加具体，更具可操作性。

雷达图是一种很好的将知识分类组织的形式，它可以让你一目了然地看到并了解所有知识点，并根据自己的需要，决定是否深入了解。

在我看来，雷达图不仅仅适用于组织，也可以适用于团队。

你是否想过，为什么雷达图的形式可以帮助你更好地理解知识呢？ 因为人的大脑更擅长处理图像。

就人脑的进化而言， 处理图像的速度远远快于处理文字， 所以，有“一图胜千言”的说法。

我给你介绍了一种结构化学习新知识的方式：技术雷达。

技术雷达就是一种将技术信息组织起来的方式。它通过将技术按照“象限”和“圆环”两个维度进行分类，让人可以直观地看到并理解不同的技术所处的发展阶段。

雷达图是一种很好的形式，不仅可以用在组织技术，还可以用来组织其它信息，比如，读书雷达。每个公司都可以利用雷达图的形式组织自己所有的技术，每个团队也可以利用雷达图的形式组织自己团队用到的技术，这样，方便团队成员结构化地理解用到技术，也方便新人的学习。

雷达图实际上是一种可视化的方法，人脑对于图像处理速度更快，因此，可视化是改善沟通的一种方式。大多数软件过程习惯采用文字的方式进行表达，对于“可视化”利用的还不够。当然，还是有一些利用“可视化”的方法，比如，流程图、UML 等。

最后，我给你介绍了一个利用可视化进行信息沟通的实践：看板。看板把工作分成了几个不同的阶段，在看板上对应不同的列，然后，每个任务作为一张卡贴在上面。每完成一张卡，就把这张卡挪到下一个阶段。

看板可以帮你发现许多问题，比如，当前进展是否合适，是否有人同时在做很多的事，发现当前工作的瓶颈等等。

如果今天的内容你只能记住一件事，那请记住： 多尝试用可视化的方式进行沟通。

显然，我们还可以做得更快。在自己的开发机上执行这些检查，就会比在 CI 服务器快。也就是说， 执行同样的操作，本地环境会快于 CI 服务器环境。

这里我们要“插播”持续集成中重要的一个提交纪律： 只有 CI 服务器处于绿色的状态才能提交代码。 有检查在运行不能提交，有错误不能提交。原因很简单，如果这个时候多个人提交了代码，检查失败了，那问题到底算谁的呢？

好，你已经理解了我说的重点： 不能把检查只放到 CI 服务器上执行。 那该怎么做呢？答案已经呼之欲出了，那就是在本地开发环境上执行。

想做好持续集成的一个关键点是， 用好本地构建脚本（build script），保证各种各样的检查都可以在本地环境执行。

简单来说，我们的目的就是快速地得到反馈。

说完了“快速”，我们再来看看做好持续集成的第二个重点： 反馈，也就是怎么得到有效的反馈。

现在，我们终于要讲到这个部分的重点了： 怎么呈现是有效的？

答案很简单： 怎么引人注目，怎么呈现。

这里再插播一条持续集成的纪律： CI 服务器一旦检查出错，要立即修复。 原因很简单，你不修，别人就不能提交，很多人的工作就会因此停顿下来，团队的工作流就会被打断，耽误的是整个团队的工作。

持续集成是软件开发中的重要实践，做好持续集成的关键在于，快速反馈。这里面有两个目标，怎样快速地得到反馈，以及什么样的反馈是有效的。

做好快速反馈，要把本地能做好的事情，在本地做好；也要通过小步提交的方式，加快代码开发的节奏。什么是有效的反馈？一是即时的反馈，二是引人注目的反馈。有很多种持续集成相关的工具可以帮助我们达成有效的反馈。

想要做好持续集成，还要有一些纪律要遵循：

• 只有 CI 服务器处于绿色的状态才能提交代码；
• CI 服务器一旦检查出错，要立即修复。

如果今天的内容你只能记住一件事，那请记住： 做好持续集成的关键在于，快速反馈。

这种把过程还原，进行研讨与分析的方式，就是复盘。

为什么复盘这么好用呢？在我看来有一个重要的原因，在于 客体化。

用别人的视角看问题，这就是客体化。

这里面有两个重点。 一个是写事实，不要写感受。 因为事实就是明摆在那里的东西，而感受无法衡量，你感觉好的东西，也许别人感觉很糟糕。

另外， 每张便签只写一条，因为后面我要对便签归类。 因为大家是分头写的，有可能很多内容是重复的，所以，要进行归类。

请注意， 所有给出的行动项应该都是可检查的，而不是一些无法验证的内容。

你的团队如果能一下洞见到根因固然好，如果不能，那么最好多问一些为什么。具体怎么问，有一个常见的做法是：5 个为什么（5 Whys）。

“5 个为什么”中的“5”只是一个参考数字，不是目标。

在软件研发中，许多问题是反复出现的，很多开发团队会因此陷入无限“救火”中，解决这种问题一个好的办法就是复盘。

复盘，就是过程还原，进行研讨与分析，找到自我改进方法的一个方式。这种方式使我们拥有了客体化的视角，能够更客观地看待曾经发生过的一切。这种方法在很多领域中都得到了广泛的应用，比如股市和企业管理。

在软件开发中，也有一些复盘的实践。我给你详细介绍了“回顾会议”这种形式。

无论哪种做法，分析问题，找到根因是一个重要的环节。“5 个为什么”就是一个常用的找到根因的方式。

如果今天的内容你只能记住一件事，那请记住： 定期复盘，找准问题根因，不断改善。

而作为一个程序员，欠缺用户视角，在与产品经理的交流中，你是不可能有机会的，因为他很容易用一句话就把你打败：“这就是用户需求。”

今天我们讨论的角度，就是要你把工作范围扩大， 由听产品经理的话，扩大成倾听用户的声音。

这种改进很细微，如果你不是用户，只从逻辑推演的角度是很难看到这种差异的。

今天我们讨论了一个重要的话题：倾听用户声音。这是开发团队普遍欠缺的一种能力，更准确地说，是忽略的一种能力。所以，“吃自家的狗粮”这种听上去本来是理所当然的事情，才被反复强调，成为 IT 行业的经典。

在今天这一讲，我给你介绍了“了解用户需求”的不同做法，但其归根结底就是一句话，想办法接近用户。

无论是自己做用户，还是找机会接触已有用户，亦或是没有用户创造用户。只有多多听取来自真实用户的声音，我们才不致于盲目自信或是偏颇地相信产品经理。 谁离用户近，谁就有发言权，无论你的角色是什么。

如果今天的内容你只能记住一件事，那请记住： 多走近用户。

作为一个程序员，克服技术难题是我们工作的一个重要组成部分，所以，一旦有困难我们会下意识地把自己投入进去。但这真的是最好的做法吗？并不是， 不是所有的问题，都是值得解决的技术难题。

遇到问题，最好的解决方案是尽早把问题暴露出来。 其实，这个道理你并不陌生，因为你在写程序的时候，可能已经用到了。

我们今天讨论了一个重要的工作原则，把事情往前做，尽早暴露问题。我们前面讲的很多内容说的都是这个原则，比如，要先确定结果，要在事前做推演等等。越早发现问题，解决的成本就越低，不仅仅是解决问题本身的成本，更多的是对团队整体计划的影响。

一方面，事前我们要通过“以终为始”和“任务分解”早点发现问题；另一方面，在做事过程中，一旦在有限时间内搞不定，尽早让其他人知道。

这个原则在写程序中的体现就是 Fail Fast，很多程序员因为没有坚持这个原则，不断妥协，造成了程序越来越复杂，团队就陷入了无尽的泥潭。

原则很简单，真正的挑战在于克服自己的心理障碍。很多人都会下意识地隐瞒问题，但请相信你的队友，大家都是聪明人，问题是藏不住的。

如果今天的内容你只记住一件事，那请记住： 事情往前做，有问题尽早暴露。

其实， 很多人回避写文档的真正原因是，他掌握的内容不能很好地结构化。

将零散的知识结构化，有很多种方式，但输出是非常关键的一环。

输出的过程，本质上就是把知识连接起来的过程。 自己以为自己懂的东西，当你真的需要把它按照一个完整的逻辑呈现出来时，那些缺失的细节就会冒出来，而补齐这些细节，一张知识地图就逐渐成型了。

从中心论点、分论点至论据，这样一层层向下展开，从结构上看，就像金字塔一样，所以，这个方法称之为 金字塔原理。

程序员对文档有着一种矛盾的情感，一方面，需要依赖于文档获得知识，另一方面，很少有人愿意写文档。

文档在程序员心目中“形象不佳”，主要是传统的流程写了太多无用的文档。但对更多人来说，不愿意写文档，本质上是因为知识不能很好地结构化。

有结构的知识会让新知识的学习变得更加容易，今天很多人抱怨新知识层出不穷，就是因为知识过于零散，当知识有结构之后，学习新知识就只是在学习增量，效率自然就会大幅度提升。

输出是一种很好的方式，帮助你把知识连接起来，写作和做公开演讲都是很好的输出方式。

阻碍很多人进行知识输出的一个重要原因是缺乏输出的模型，金字塔原理就给出一个从中心论点到分论点，再到论据的模型，帮助我们将知识梳理出来。

而想要做好知识输出，还需要不断地进行练习，写作和做公开演讲都是可以通过练习提高的。

如果今天的内容你只能记住一件事，那请记住： 多输出，让知识更有结构。

你有没有想过一个问题，不同算法的复杂度本质差别到底是什么呢？我们就以插入排序和快速排序为例，为什么快速排序要比插入排序快呢？

我不打算做算法分析，直接公布答案：因为做比较的次数少。为什么同样的排序，比较次数会有差异呢？因为插入排序每次循环只关注当前的目标，循环之间没有关系，而快速排序在做不同划分时，上一次的结果对下一次有助力，因此它省下了不少的比较次数。

明白了这个道理，再来看所谓的算法优化， 其实就是尽可能利用已知的信息，少做不必要的事。

插入排序并不会因为干的活多，就比快速排序得到更高的评价，因为它们比的是谁排得快。工作效率高，不是因为代码写得多，而是有效工作做得多。

如果 CPU 都被无效指令占据了，哪有时间执行有效指令呢？即使你很忙碌，但工作进展依然是收效甚微，因为无效工作占据了你太多的大脑，让你不能聚焦在正经事上，当然就是效率不高了。

我在这个专栏真正探讨的主题是，有效工作。

有效工作，需要我们把力量聚焦到正确的地方，做本质复杂度（Essential Complexity）的事情，少做无意义的事情。

怎么才能有效工作呢？我在专栏中已经给你讲了很多，小结一下就是：

• 拓展自己的上下文，看到真正的目标，更好地对准靶子，比如，多了解用户，才不至于做错了方向；站在公司的层面上，才知道哪个任务优先级更高；站在行业的角度，而不局限于只在公司内成为高手，等等。
• 去掉不必要的内容，减少浪费，比如，花时间分析需求，不做非必要的功能；花时间做好领域设计，别围着特定技术打转；花时间做好自动化，把精力集中在编码上，等等。

要想有效工作，有两点非常重要。一方面，意识上要注意自己工作中无效的部分。这就像一个开关，拨过去就好了。所以，读这个专栏，有人常有恍然大悟的感觉，也有人觉得很简单。