提升工作效率的最佳实践
总结起来就四个：
- 以终为始；
- 任务分解；
- 沟通反馈；
- 自动化。
1、以终为始就是在工作的一开始就确定好自己的目标。我们需要看到的是真正的目
标，而不是把别人交代给我们的工作当作目标。你可以看出这个原则是在帮助我们回答思考框架中，Where are we going?（我们要到哪儿去？）这个问题。
2、任务分解是将大目标拆分成一个一个可行的执行任务，工作分解得越细致，我们便越能更好地掌控工作，它是帮助我们回答思维框架中，How can we get there?（我们如何到达那里？）的问题。
3、沟通反馈是为了疏通与其他人交互的渠道。一方面，我们保证信息能够传达出去，减少因为理解偏差造成的工作疏漏；另一方面，也要保证我们能够准确接收外部信息，以免因为自我感觉良好，阻碍了进步。
4、自动化就是将繁琐的工作通过自动化的方式交给机器执行，这是我们程序员本职工作的一部分，我们擅长的是为其他人打造自动化的服务
我们不是一个人孤独地在工作，而是与其他人在协作，想要做到高效工作，我们就要“抬起头”来，跳出写代码这件事本身。所以，我在开篇词里说，程序员解决的问题，大多不是程序问题。
大多数人工作低效是由于工作中偶然复杂度太多造成的，只要能够更多地将注意力放到本质复杂度上，减少偶然复杂度造成的消耗，我们“真实”的工作效率自然会得到大幅度提升。
一个思考框架
思考三个问题：
- 我现在是个什么水平？（现状）
- 我想达到一个什么水平？（目标）
- 我将怎样到达那个目标？（实现路径）
四个思考原则
在实际的工作中，这个思考框架会帮助我更好地了解自己的工作。比如，当一个产品经理给我交代一个要开发的功能特性时，我通常会问他这样一些问题：
- 为什么要做这个特性，它会给用户带来怎样的价值？
- 什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？
- 达成这个目的是否有其它手段？是不是一定要开发一个系统？
- 这个特性上线之后，怎么衡量它的有效性？
一、以终为始
践行“以终为始”就是在做事之前，先考虑结果，根据结果来确定要做的事情。
小李认为他的活已经做完了，项目经理老张却认为他没做完。归根结底，就在于二人对“完成”的定义理解的不同。
完成的定义 - DoD
DoD 是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况，一旦 DoD 确定好了，谁该做什么事就一目了然了。
DoD 是团队成员间彼此汇报的一种机制。当我们有了 DoD，做事只有两种状态，即“做完”和“没做完”。
DoD 是一个的思维模式，是一种尽可能消除不确定性，达成共识的方式。DoD 让我们能够在一开始就把“终”清晰地定义出来。
请记住：在做任何事之前，先定义完成的标准。
如何描述需求 - 用户故事
用户故事（User Story）是新的需求描述方式，它是站在用户的角度来描述了一个用户希望得到的功能，关注用户在系统中完成一个动作需要经过怎样的路径。既然它是“故事”，它就需要是一个完整的场景。
验收标准给出了这个需求最基本的测试用例，它保证了开发人员完成需求最基本的质量。
请记住：在做任何需求或任务之前，先定好验收标准
持续集成：集成本身就是写代码的一个环节
一个好的做法是尽早把代码和已有代码集成到一起，而不应该等着所有代码都开发完了，再去做提交。
git 版本工具，Jenkins 持续构建。
精益创业：经过严格思考的需求才能做
当产品经理让我们做一个新的产品特性时，我们可以从精益创业这个实践上得到启发，向产品经理们问一些问题，帮助我们确定产品经理提出的需求确实是经过严格思考的。
请记住：默认所有需求都不做，直到弄清楚为什么要做这件事。
跳出程序员的角色看问题，工作才会变得更加高效
你在项目里打杂，你只能关注到一个具体的任务，而项目主力心目中是整个系统。虽然写的代码都一样，但你看到的是树木，人家看到的是森林，他更能从全局思考。
前提就是要跳出程序员角色思维，并不是所有问题都要用技术解决，扩大自己工作的上下文。
做事之前要先进行推演
整理了自己的思路，列出了一个自己的问题解决计划。
- 先从结果的角度入手，看看最终上线要考虑哪些因素。
- 推演出一个可以一步一步执行的上线方案，用前面考虑到的因素作为衡量指标。
- 根据推演出来的上线方案，总结要做的任务。
启动开发之前的准备
与上级的相处
问题 1：领导要求的，无力反驳怎么办？
上级也是人，一样有着长处和短处，不能唯命是从，应该从正确的事情入手，以上级能够接受的方式向其提出建议。
敢于管理上级，对上级不合理的要求说“不”。把自己看到的问题暴露给上级，让他选择。
如果是我，我会告诉上级，这个压缩时间会影响到什么。比如，要想做这个调整，你需要放弃的内容是什么；或者，我可以给出一个快速上线的临时方案，但接下来的几天，我需要调整，让代码回到一个正常的状态中。所以，你就不要给我安排新工作了。
如果经过你的种种努力，发现你的上级真的是完全没法影响，只能以令人无语的方式行事，那你需要仔细考虑一下与他合作的前景了。
问题 2：产品经理总拿老板说事，怎么办？
不合理的部分应该是他和老板去沟通的，而不是让开发团队来实现。
问题 3：别人能做的，我们也要做
“抄”不是问题，问题是无脑地抄。
如果你的产品经理只想无脑抄袭，本质上，他就是在偷懒，没干好他该干的活
关于“以终为始”，你要记住的9句话
- 遇到事情，倒着想。
- 在做任何事之前，先定义完成的标准。
- 在做任何需求或任务之前，先定好验收标准。
- 尽早提交代码去集成。
- 默认所有需求都不做，直到弄清楚为什么要做这件事。
- 扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上。
- 在动手做一件事之前，先推演一番。
- 问一下自己，我的工作是不是可以用数字衡量。
- 设计你的迭代 0 清单，给自己的项目做体检。
二、任务分解
德雷克公式最大的作用在于：它将一个原本毫无头绪的问题分解了，分成若干个可以尝试回答的问题。
多写单元测试
对于每个程序员来说，只有在开发阶段把代码和测试都写好，才有资格说，自己交付的是高质量的代码。
随着人们对于测试理解的加深，各种各样的测试都出现了，也开始有了测试的分类：单元测试、集成测试、系统测试等等。越在底层测试，成本越低，执行越快；越在高层测试，成本越高，执行越慢。
测试驱动开发TDD：我们应该编写可测的代码
学习 TDD 的第一步，是要记住 TDD 的节奏：“红 - 绿 - 重构”。
红，表示写了一个新的测试，测试还没有通过的状态；绿，表示写了功能代码，测试通过的状态；而重构，就是再完成基本功能之后，调整代码的过程。
因为重构和测试的互相配合，它会驱动着你把代码写得越来越好。这是对“驱动”一词最粗浅的理解。
我的代码怎么写才是能测试的，也就是说，我们要编写具有可测试性的代码。
先测试后写代码的方式，会让你看待代码的角度完全改变，甚至要调整你的设计，才能够更好地去测试。
大师级程序员的工作秘笈
极限编程：持续集成。每个任务完成之后，代码都是可以提交的。
一个经过分解后的任务，需要关注的内容是有限的，我们就可以针对着这个任务，把方方面面的细节想得更加清晰。
将任务拆小，越小越好
学习拆分任务
按照完整实现一个需求的顺序去安排分解出来的任务。
任务分解没有一个绝对的标准答案，分解的结果根据个人技术能力的不同，差异也会很大。
检验每个任务项是否拆分到位，就是看你是否知道它应该怎么做了，不过，即便你技术能力已经很强了，我依然建议你把任务分解到很细，观其大略人人行，细致入微见本事。
强调：每做完一个任务，代码都是可以提交的
任务的优先级 - 艾森豪威尔矩阵
它将事情按照重要和紧急两个维度进行划分，也就形成了四个部分：重要且紧急，重要不紧急，不重要且紧急，不重要不紧急。
- 让系统不能正常运行的线上故障，就属于重要且紧急事情，不赶紧解决，就影响公司的正常运营。
- 团队对系统升级改造就属于重要不紧急：改造好，性能也好，可维护性也得到提升；不改造，一时半会也能用。
- 一些临时任务都属于紧急不重要，
- 刷朋友圈则属于既不紧急也不重要。
如果不把精力放在重要的事情上，到最后可能都变成紧急的事情。
问题 1：面对不了解的技术，我该如何分解任务？
先把它变成你熟悉的技术，做一次技术调研
问题 2：多个功能同时开发，怎么办？
用户故事划分得当，你可以很快完成一个完整的业务需求
三、沟通反馈
我们努力地学习各种知识，为的就是更好地理解这个世界的运作方式，而沟通反馈，就是我们与真实世界互动的最好方式。
香农信息论中的一个通信模型，如下图所示：
因为每个人经历见识的差异，造成了各自编解码器的差异
不要讲东西直奔细节，先介绍全局和背景。
沟通反馈就是改善编码、解码以及算法的方式
编写可维护的代码
更有追求的程序员会知道，仅仅实现功能是不够的，还需要写出可维护的代码。
我们写代码的目的是与人沟通，因为我们要在一个团队里与人协同工作。
人要负责将业务问题和机器执行连接起来，缺少了业务背景是不可能写出好代码的。
领域驱动设计：在代码里尽可能使用业务语言
记住：用业务的语言写代码。
轻量级沟通
开会是一种重量级的沟通，它有很强的仪式感，开会是为了解决问题
凡是效果特别好的会议，基本上都是用来做信息同步的。比如，领导宣布一个事情，这种会议几乎不会浪费时间。宣布消息，大家收到消息，结束。
改善会议
- 改善会议的第一个行动项是，减少参与讨论的人数。
- 如果你要讨论，找人面对面沟通。
站立会议
- 我昨天做了什么？（同步进展，如果偏离计划，请主动把它提出）
- 我今天打算做什么？（工作安排，同步涉及协助的其他人）
- 我在过程中遇到了什么问题，需要请求帮助。
记住：多面对面沟通，少开会。
技术雷达
什么是技术雷达？技术雷达是由 ThoughtWorks 技术战略委员会（TAB）经由多番正式讨论给出的最新技术趋势报告，它以独特的雷达形式对各类最新技术的成熟度进行评估并给出建议，为从程序员到CTO的利益相关者提供参考。
每次技术雷达发布之后，我会特别关注一下“采用” 和 “暂缓”两项。
- “采用”表示强烈推荐，我会去对比一下自己在实际应用中是否用到了
-
“暂缓” 则表示新项目别再用这项技术了
雷达图是一种很好的将知识分类组织的形式，它可以让你一目了然地看到并了解所有知识点，并根据自己的需要，决定是否深入了解。
看板
看板，是一种项目管理工具，它将我们正在进行的工作变得可视化。
持续集成
持续集成的两个重要目标：怎样快速地得到反馈，以及什么样的反馈是有效的。
执行同样的操作，本地环境会快于 CI 服务器环境。
想要做好持续集成，还要有一些纪律要遵循：
- 只有 CI 服务器处于绿色的状态才能提交代码；
- CI 服务器一旦检查出错，要立即修复。
想要做好 CI，需要有一个稳定的开发分支，最好采用主开发分支的方式，最好能够频繁提交；
复盘
把过程还原，进行研讨与分析的方式，就是复盘。
客体化：当你复盘时，你会站在另外一个视角，去思考引起这个问题的原因。
回顾会议
- 主题分成三类：“做得好的、做得欠佳的、问题或建议”。
- 针对这个开发周期内团队的表现，按照分类在便签上写下一些事实，每张便签只写一条，因为后面我要对便签归类
记住：定期复盘，找准问题根因，不断改善。
聆听用户声音
作为一个程序员如果欠缺用户视角，在与产品经理的交流中，你是不可能有机会的，因为他很容易用一句话就把你打败：“这就是用户需求。”
谁离用户近，谁就有发言权，无论你的角色是什么。
记住：多走近用户。
尽早暴露问题
遇到问题，最好的解决方案是尽早把问题暴露出来，而不是等别人问。
克服心理障碍，这种担心是多余的。只有你能把问题解决了大家才会高看你，而把问题遮盖住，并不能改善你在别人心目中的形象。
把自己的工作透明化，让别人尽可能多地了解自己的工作进展，了解自己的想法。
记住：事情往前做，有问题尽早暴露。不要怕
结构化：写文档也是一种学习方式
很多人回避写文档的真正原因是，他掌握的内容不能很好地结构化。
想要成为一个好程序员，有一个良好的知识结构是极其重要的。
当你建立起自己的知识结构，任何新东西都只是在原有知识上的增量迭加。
将零散的知识结构化，有很多种方式，但输出是非常关键的一环。
知识输出：输出的过程，本质上就是把知识连接起来的过程。
金字塔原理
我们要确定想要表达的是什么，也就是找到中心论点，然后，再确定支撑这个论点的分论点，再来就是找到支撑每个分论点的论据
高效学习运维知识
学习一个新东西，最好的办法是学习增量，如果能够找到它与已有知识体系的联系。
我们可以把运维知识和我们熟悉的Java知识联系，进行增量学习
请记住：有体系地学习运维知识。
持续交付
在构建持续交付的基础设施时，会有下面几个不同的环境
- 持续集成环境，持续集成是持续交付的前提
- 测试环境（Test），这个环境往往是单机的，主要负责功能验证
- 预生产环境（Staging），这个环境通常与生产环境配置是相同的
- 生产环境（Production），这就是真实的线上环境了。
我们的生成产物就由一个发布包变成了一个 Docker 镜像。
Docker 在开发中扮演的角色，是一个构建在我们应用与具体机器之间的中间层。对应用而言，它就是机器，但对机器而言，它只是一个可以部署的镜像，统一了各种应用千奇百怪的部署差异，让部署本身变得更简单了。
请记住：将部署纳入开发的考量。
SOLID 原则
高内聚、低耦合
- 单一职责原则（Single responsibility principle，SRP）
- 开放封闭原则（Open–closed principle，OCP）
- Liskov 替换原则（Liskov substitution principle，LSP）
- 接口隔离原则（Interface segregation principle，ISP）
- 依赖倒置原则（Dependency inversion principle，DIP）
请记住：把函数写短
先做好DDD再谈微服务吧，那只是一种部署形式
微服务真正的难点并非在于技术实现，而是业务划分，而这刚好是 DDD 战略设计中限界上下文（Bounded Context）的强项。
DDD 到底讲了什么呢？它把你的思考起点，从技术的角度拉到了业务上。
限界上下文：它限定了通用语言自由使用的边界，一旦出界，含义便无法保证。
重构
重构是一种微操作。
重新实现这套系统叫重写（rewrite），而不是重构（refactoring）
重构的手法就会把它做一个分解：
- 添加一个新的通用类，用以放置这个方法；
- 在业务类中，添加一个字段，其类型是新添加的通用类；
- 搬移实例方法，将这个方法移动到新的类里面。
进入新的工作环境，快速进入工作状态
得到了三个小目标：
1、业务：基本业务框架、怎么做，做什么
2、技术：技术栈、系统的业务架构、架构图、分层架构、代码
3、团队运作：产品来源、向谁汇报、日常沟通、站会、周会、代码评审、分享机制
面对遗留系统，你应该这样做
先尝试重构你的代码，尽可能在已有代码上做小步调整，不要走到大规模改造的路上，因为重构的成本是最低的。
如何保持竞争力
我们的焦虑来自于对未来的不确定性，而这种不确定性是一个特定时代加上特定行业的产物。
1、成为 T 型人
有了“一专”，“多能”才是有意义的，否则，就是低水平重复，而这正是很多人职业生涯不见起色的真正原因。
这里的“专”不是熟练，而是深入
2、在学习区成长
读书的一个好处在于，你的视野会打开，不会把目标放在“用别人已经打造好的工具做一个特定的需求”，虽然这可能是你的必经之路，但那只是沿途的风景，而不是目标。
找一个好问题去解决，解决了一个好的问题能够让你的水平快速得到提升。什么是好问题？就是比你当前能力略高一点的问题。
如果你已经能完成一个普通的系统设计，那就应该去设计业务量更大的系统。
- 最内层是舒适区（Comfort Zone），置身其中会让人感觉良好，但也会因为没有挑战，成长甚微，你可以把它理解成做你最熟悉的事情。
- 最外层是恐慌区（Panic Zone），这是压力极大的地方，完全超出了你的能力范围，你在其中只会感到无比的焦虑。
- 中间的是学习区（Learning Zone），事情有难度，又刚好是你努力一下可以完成的，这才是成长最快的区域。
根据这个模型，只有一直身处学习区才能让人得到足够的成长，所以，我们应该既选择比自己能力高一点的问题去解决，不要总做自己习惯的事，没有挑战，也不要好大喜功，一下子把自己的热情全部打散。
问题 1：想要推行 DDD，阻力很大怎么办？
找到愿意和你一起改变的人，做一件具体的事。
总结
产品
做产品，很多时候是面向不确定性解决问题。目前这方面最好的实践是“精益创业”。对于精益创业的最简单的理解就是“试”。试也有试的方法，精益创业提出了一个“开发（build）- 测量（measure）- 认知（learning）”这样的反馈循环，通过这个循环得到经过验证的认知（Validated Learning）。
既然是对不确定产品特性的尝试，最好的办法就是低成本地试。在精益创业中，最小可行产品（MVP）就是低成本的试法。最小可行产品，就是“刚刚好”满足用户需求的产品。理解这个说法的关键在于用最小的代价，尝试可行的路径。
在产品的打磨过程中，可以采用用户测试的方式，直接观察用户对产品的使用。作为程序员，我们要尽可能吃自家的狗粮，即便你做的产品不是给自己使用的产品，也可以努力走近用户。
精益创业
相关阅读：《06 | 精益创业：产品经理不靠谱，你该怎么办？》最小可行产品（MVP）
相关阅读：《19 | 如何用最小的代价做产品？》用户测试、验证产品特性、吃自家狗粮
相关阅读：《26 | 作为程序员，你也应该聆听用户声音 》
需求
当我们确定做一个产品功能时，怎么描述需求也是很重要的。产品列表式的需求描述方式最容易出现问题的地方在于，看不清需求的全貌。
用户故事是一个好的需求描述方式：作为一个什么角色，要做什么样的事，以便达成一种怎样的效果。
在用户故事中，验收标准是非常重要的一环。即便不是采用用户故事描述需求，也依然建议先将验收标准定义清楚。
开发团队对需求的理解普遍偏大，基本上都是一个主题。在开发之前，先将需求拆分成小粒度的。衡量一个用户故事拆分是否恰当，一个标准是 INVEST 原则。有了拆分出来的用户故事，就可以进行估算了，估算的过程也是对需求加深理解的过程，过大的用户故事应该再次拆分。
当我们有了拆分之后的需求，就可以对需求进行进行优先级讨论了。先做重要性高的事，而不是一股脑地去做所有的需求。只有分清了需求的优先级，才能方便地对需求进行管理。
用户故事
相关阅读：《04 | 接到需求任务，你要先做哪件事？ 》需求的分解与估算
相关阅读：《17 | 程序员也可以“砍”需求吗？》需求管理、优先级
相关阅读：《18 | 需求管理：太多人给你安排任务，怎么办？》
持续集成
在开发中，写出代码并不是终点，我们要把代码集成起来。集成要经常做，改动量越小，集成就可以做得越频繁，频繁到每次提交都去集成，这就是持续集成。
持续集成发展到今天已经是一套完整的开发实践。想要做好持续集成，你需要记住持续集成的关键是“快速反馈”。
- 怎样快速得到反馈。
- 怎样反馈是有效的。
持续集成，可以继续延展，将生产部署也纳入其中，这就是持续交付。如果持续交付，再向前一步，就可以同产品验证结合起来。
持续交付的关键点，是在不同的环境验证发布包和自动化部署。不同的环境组成了持续交付的构建流水线，而自动化部署主要是 DevOps 发挥能力的地方。持续交付的发展，让交付物从一个简单的发布包变成了一个拥有完整环境的 Docker 镜像。
持续集成和持续交付可以将诸多的实践贯穿起来：单元测试、软件设计、任务分解、主分支开发、DevOps 等等。所以，如果一个公司希望做过程改进，持续集成是一个好的出发点。
持续集成发展史
相关阅读：《05 | 持续集成：集成本身就应该是写代码的一个环节》快速反馈
相关阅读：《24 | 快速反馈：为什么你们公司总是做不好持续集成？》持续集成，贯穿诸多实践
相关阅读：《答疑解惑 | 持续集成，一条贯穿诸多实践的主线 》持续交付
相关阅读：《32 | 持续交付：有持续集成就够了吗？》与产品结合：持续验证
相关阅读：《答疑解惑 | 持续集成、持续交付，然后呢？ 》
测试
测试是一个典型的程序员误区，很多程序员误以为测试只是测试人员的事。理解了软件变更成本，知道了内建质量之后，我们就应该清楚，测试应该体现在全部的开发环节中。这一思想在开发中的体现就是自动化测试。
想要写好自动化测试，需要先理解测试金字塔，不同的测试运行成本不同。为了让软件拥有更多的、覆盖面更广的测试，需要多写单元测试。
编写测试的方式有很多，一种实践是测试驱动开发（TDD）。先写测试，然后写代码，最后重构，这就是 TDD 的节奏：红——绿——重构。测试驱动开发的本质是测试驱动设计，所以，编写可测试的代码是前提。
要想做好 TDD，一个重要的前提是任务分解，分解到非常小的微操作。学会任务分解，是成为优秀程序员的前提条件。
想写好测试，需要懂得好测试是什么样子的，避免测试的坏味道。好测试有一个衡量标准：A-TRIP。
我们不只要写好单元测试，还要站在应用的角度写测试，这就是验收测试。验收测试现在比较成体系的做法是行为驱动开发（BDD），它让你可以用业务的语言描述测试。
单元测试、自动化测试、蛋卷和冰淇淋模型
相关阅读：《12 | 测试也是程序员的事吗？》测试驱动开发
相关阅读：《13 | 先写测试，就是测试驱动开发吗？》
相关阅读：《14 | 大师级程序员的工作秘笈 》测试练习
相关阅读：《15 | 一起练习：手把手带你拆任务 》简单的测试、测试的坏味道、A-TRIP
相关阅读：《16 | 为什么你的测试不够好？ 》验收测试、写好验收测试用例
相关阅读：《32 | 持续交付：有持续集成就够了吗？》外部系统测试，用接口隔离
相关阅读：《答疑解惑 | 如何在实际工作中推行新观念？ 》
编码与设计
编码和设计，是软件开发中最重要的一环。在我看来，编码和设计是一体，想清楚才能写出好代码。很多程序员追求写好代码，却没有一个很好的标准去衡量代码的好坏。结合着软件设计的一些理念，我给你一个编写好代码的进步阶梯，希望你能达到用业务语言编写代码的程度。
用业务语言编写代码，需要对软件设计有着良好的理解。提到设计，人们的初步印象是“高内聚低耦合”，但这是一个太过高度抽象的描述。SOLID 原则是一个更具实践性的指导原则，有了原则做指导，就可以更好地理解设计模式了。
有了基础原则，我们会知道将不同的代码划分开，这样就产生了分层。好的分层可以构建出抽象，而其他人就可以在这个抽象上继续发展。对于程序员来说，构建自己的核心抽象是最关键的一步。
目前构建核心抽象最好的方式是领域驱动设计（DDD），它将我们思考的起点拉到了业务层面，通过战略设计将系统按照不同的上下文划分开来，再通过战术设计，指导我们有效地设计一个个的领域模型。
但无论怎样做设计，前提是使用适当的技术解决适当的问题，不要把技术用复杂，把团队带入泥潭。
业务语言写代码
相关阅读：《21 | 你的代码为谁而写？》架构设计
相关阅读：《34 | 你的代码是怎么变混乱的？ 》分层、抽象
相关阅读：《35 | 总是在说 MVC 分层架构，但你真的理解分层吗？》业务与技术
相关阅读：《36 | 为什么总有人觉得 5 万块钱可以做一个淘宝？ 》微服务
相关阅读：《37 | 先做好 DDD 再谈微服务吧，那只是一种部署形式 》
项目准备
从头开始一个项目时，一个好的实践就是把一切都准备好。迭代 0 就是这样一个把迭代准备好的实践，从需求到技术，做好充分的准备工作再开启项目，你会显得从容不迫。在技术方面，迭代 0 最重要的准备工作就是构建脚本，它是后续很多工作的基础，比如，持续集成。
迭代 0，做基础的准备
相关阅读：《10 | 迭代 0: 启动开发之前，你应该准备什么？》构建脚本，让项目一开始就自动化
相关阅读：《30 | 一个好的项目自动化应该是什么样子的？ 》
其余的最佳实践
除了几个花大篇幅介绍的最佳实践，我们还提到了很多不同的最佳实践。
DoD
完成的定义（DoD），是一个确保合作各方理解一致的实践。它是一个清单，由一个个检查项组成，每个检查项都是实际可检查的。有了 DoD，做事就只有两种状态：完成和未完成。
- 完成的定义，DOD
相关阅读：《03 | DoD 价值：你完成了工作，为什么他们还不满意？》
站会
站会，一种轻量级的会议形式，用来同步每天发生的事情。一般来说，只说三件事：昨天做了什么，今天打算做什么，遇到了什么问题。
- 站会
相关阅读：《22 | 轻量级沟通：你总是在开会吗？ 》
看板
看板，一种项目管理工具， 将正在进行的工作可视化。通过看板，可以发现团队正在进行工作的很多问题。看板有实体和电子之分，可以根据自己的项目特点进行选择。
- 看板
相关阅读：《23 | 可视化：一种更为直观的沟通方式 》
回顾会议
回顾会议，是一种复盘实践，让团队成员对一个周期内发生的事情进行回顾。回顾会议一般分为讲事实、找重点和制定行动项三个部分。但在开始回顾之前，会先进行安全检查，确保每个人都能放心大胆地说真话。
回顾会议
相关阅读：《25 | 开发中的问题一再出现，应该怎么办？ 》回顾会议中的安全检查
相关阅读：《答疑解惑 | 持续集成，一条贯穿诸多实践的主线 》
重构
重构，是程序员的基本功，把调整代码的动作分解成若干可以单独进行的“重构”小动作，一步步完成。重构的前提是识别代码的坏味道。保证代码行为不变，需要有测试配合，而重构的方向是，重构成模式（Refactoring to Patterns）。重构的过程和编写代码的过程最好结伴而行，最佳实践就是测试驱动开发。
重构
相关阅读：《加餐 | 你真的了解重构吗？》在测试驱动开发中重构
相关阅读：《13 | 先写测试，就是测试驱动开发吗？》
分支开发
分支开发模型，是每个团队都要面临的问题。行业中有两种常见的分支模型，一种是基于主干的开发模型，一种是分支开发模型。分支开发符合直觉，却不是最佳实践。主分支开发模型是与其他实践配合最好的模式，但也需要开发者有着良好的开发习惯。如果并行开发多个功能，可以考虑 Feature Toggle 和 Branch by Abstraction。
分支开发
相关阅读：《14 | 大师级程序员的工作秘笈 》Feature Toggle 和 Branch by Abstraction
相关阅读：《答疑解惑 | 如何分解一个你不了解的技术任务？ 》
Fail Fast
Fail Fast 是一个重要的编程原则：遇到问题，尽早报错。不要以构建健壮系统为由，兼容很多奇怪的问题，使得 Bug 得以藏身。
- Fail Fast
相关阅读：《27 | 尽早暴露问题： 为什么被指责的总是你？ 》