以终为始
重点
DoD，确定好完成的定义，减少团队内部的理解不一致。
用户故事，细化出有价值的需求。
持续集成，通过尽早集成，减少改动量，降低集成的难度。
精益创业，减少过度开发不确定性产品带来的浪费。
迭代 0，在项目开始之前，做好一些基础准备。
思维转变
任何事物都要经过两次创造：
头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation）
付诸实践，也就是实际的构建或第二次创造（Physical/Second Creation）
在更大的上下文内发现自己的“终”
通过推演，找到通往“终”的路径
用可度量的“数字”定义自己的“终”
实战指南
遇到事情，倒着想
在做任何事之前，先定义完成的标准
在做任何需求或任务之前，先定好验收标准
尽早提交代码去集成
默认所有需求都不做，直到弄清楚为什么要做这件事
扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上
在动手做一件事之前，先推演一番
问一下自己，我的工作是不是可以用数字衡量
设计你的迭代 0 清单，给自己的项目做体检
任务分解
重点
测试金字塔
行业中测试组合的最佳实践
多写单元测试是关键
测试驱动开发
测试驱动开发的节奏
红——绿——重构
重构是测试驱动开发区别于测试先行的关键
测试驱动设计
编写可测的代码
艾森豪威尔矩阵（Eisenhower Matrix）
将事情按照重要和紧急进行划分
重要且紧急的事情要立即做
重要但不紧急的事情应该是我们重点投入精力的地方
紧急但不重要的事情，可以委托别人做
不重要不紧急的事情，尽量少做
最小可行产品
“刚刚好”满足客户需求的产品
在实践中，要用最小的代价找到一条可行的路径
实战指南
动手做一个工作之前，请先对它进行任务分解
多写单元测试
我们应该编写可测的代码
将任务拆小，越小越好
按照完整实现一个需求的顺序去安排分解出来的任务
要想写好测试，就要写简单的测试
想要管理好需求，先把需求拆小
尽量做最重要的事
做好产品开发，最可行的方式是采用 MVP
评判标准
尽量不写 static 方法
主分支开发模型是一种更好的开发分支模型
好的用户故事应该符合 INVEST 原则
估算是一个加深对需求理解的过程，好的估算是以任务分解为基础的
好的测试应该符合 A-TRIP
改善
分而治之，是人类解决问题的基本手段
软件变更成本，它会随着时间和开发阶段逐步增加
测试框架把自动化测试作为一种最佳实践引入到开发过程中
使得测试动作可以通过标准化的手段固定下来极限编程之所以叫“极限”，它背后的理念就是把好的实践推向极限
大师级程序员的工作秘笈是任务分解，分解到可以进行的微操作
按照完整实现一个需求的顺序安排开发任务
额外
对不了解技术的任务，先要去了解技术，然后再做任务分解
通过一次技术 Spike ，学习新技术
丢弃掉在 Spike 过程中开发的原型代码
分清目标与现状，用目标作为方向，指导现状的改变
多个功能并行开发可以考虑使用 Feature Toggle
在遗留系统上做改造可以考虑使用 Branch by Abstraction
任务分解
重点
看板
一种来自精益生产的可视化实践
按阶段将任务放置其中
可以帮助我们发现问题
持续集成
做好持续集成的关键是，快速反馈
本地检查通过之后再提交
找到有效的反馈方式，比如：CI 监视器
持续集成的纪律
只有 CI 服务器处于绿色的状态才能提交代码
CI 服务器一旦检查出错，要立即修复
回顾会议
软件团队复盘的一种实践
枚举关注点，选出重点，深入讨论，列出行动项，找到负责人
5 个为什么
又一个来自丰田的实践
沿着一条主线追问多个问题
实战指南
通过沟通反馈，不断升级自己的编解码能力
用业务的语言写代码
多面对面沟通，少开会
多尝试用可视化的方式进行沟通
做好持续集成的关键在于，快速反馈
定期复盘，找准问题根因，不断改善
多走近用户
事情往前做，有问题尽早暴露
多输出，让知识更有结构
思路
用信息论理解沟通反馈
写代码的进阶路径编写可以运行的代码
编写符合代码规范的代码
编写人可以理解的代码
用业务语言写代码
会议是一种重量级的沟通方式
减少参会人数
找人面对面沟通
聆听用户声音
能做自己用户，做自己的用户
能接近用户，接近用户
没有用户，创造用户
Fail Fast
一种编写代码的原则
出现问题尽早报错
金字塔原理
- 从中心论点，到分论点，再到论据
额外
持续集成是一条主线，可以将诸多实践贯穿起来
从持续集成到稳定的开发分支，到频繁提交，足够小的任务，到任务分解
从持续集成到可检查
到测试防护网
到测试覆盖率
到单元测试
到可测试代码
到软件设计
安全性检查，是回顾会议的前提条件
在信息获取上，国内外程序员差别不大，开拓视野，改善工作习惯，是国内程序员亟需提高的
自动化
重点
持续交付
将生产部署纳入了开发的考量
持续交付的基础设施通常包含持续集成环境、测试环境、预生产环境和生产环境
构建流水线保证到了下游的交付物一定是通过上游验证的
随着 Docker 的诞生，交付由发布包变成了 Docker 镜像
DevOps
将开发和运维结合到一起
环境配置工具上的进步，让基础设施即代码成了行业共识
验收测试
站在业务的角度编写
BDD 是一种编写验收测试的方式
Given…When…Then… 的描述给了一个描述业务的统一方式
写好验收测试，需要构建测试模型
SOLID 原则
设计模式背后的道理
单一职责原则（Single responsibility principle，SRP）
开放封闭原则（Open–closed principle，OCP）
Liskov 替换原则（Liskov substitution principle，LSP）
接口隔离原则（Interface segregation principle，ISP）
依赖倒置原则（Dependency inversion principle，DIP）
用好单一职责原则，前提条件是看待问题颗粒度要小
DDD
它将思考的起点拉到了业务上
DDD 分为战略设计和战术设计
微服务
做好微服务的前提是划分好限界上下文
微服务的第一步，不要划分微服务
实战指南
请谨慎地将工作自动化
将你的工作过程自动化
有体系地学习运维知识
将部署纳入开发的考量
将验收测试自动化
把函数写短
构建好你的领域模型
用简单技术解决问题，直到问题变复杂
学习领域驱动设计
改善
程序员的三大美德
懒惰（Laziness）
急躁（Impatience）
懒惰（hubris）
小心 NIH 综合症（Not Invented Here Syndrome）
写好构建脚本，做好项目自动化
参照 Java 知识体系，学习运维知识
软件设计最基础的原则是“高内聚、低耦合”
分层架构是一种设计上的分解
不同业务量的系统本质上不是一个系统
采用简单技术解决问题，直到问题变复杂
额外
持续集成的延伸
持续集成完成系统集成
持续交付完成可部署上线
“持续验证”完成产品想法验证
AB 测试，用一个软件的多个版本验证想法
Selenium 用以完成浏览器的自动化
熟练使用快捷键
总结自：《10x程序员工作法》