1. 以终为始
遇到事情，倒着想
在做任何需求或任务之前，先定好验收标准。
尽早提交代码去集成
默认所有需求都不做，直到弄清楚为什么要做这件事。
扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上
在动手做一件事之前，先推演一番
管理上级
管理上级预期
告诉他如果需要压缩时间，则会牺牲什么，有什么样的影响
帮助上级丰富知识
说出你的想法
思维转变
两次创造
头脑中的创造（Mental/First Creation）
付诸实践（Physical/Second Creation）
在更大的上下文内发现自己的“终”
通过推演，找到通往“终”的路径
用可度量的“数字”定义自己的“终”
2. 任务分解
方法
1. 分而治之，动手之前先进行任务分解
2. 多写单元测试，将粒度变细
3. 将任务拆小，越小越好
每做完一个任务，代码都是可以提交的
4. 按照完整实现一个需求的顺序去安排分解出来的任务
5. 把控需求，先把需求拆分
6. 划分任务等级，只做最重要的事
7. 做好产品开发，采用MVP
MVP 就是最小可行产品，Deadline 是形式，MVP 是内核。
最佳实践
测试金字塔
行业中测试组合的最佳实践
多写单元测试是关键
测试驱动开发
测试驱动开发的节奏是：红——绿——重构，重构是测试驱动开发区别于测试先行的关键。
有人把测试驱动开发理解成测试驱动设计，它给行业带来的思维改变是，编写可测的代码。
艾森豪威尔矩阵（Eisenhower Matrix）
将事情按照重要和紧急进行划分。
重要但不紧急的事情应该是我们重点投入精力的地方
紧急但不重要的事情，可以委托别人做。
不重要不紧急的事情，尽量少做。
最小可行产品
“刚刚好”满足客户需求的产品。
在实践中，要用最小的代价找到一条可行的路径。
重要思想
分而治之，是人类解决问题的基本手段
软件变更成本，它会随着时间和开发阶段逐步增加；
测试框架把自动化测试作为一种最佳实践引入到开发过程中，使得测试动作可以通过标准化的手段固定下来；
极限编程之所以叫“极限”，它背后的理念就是把好的实践推向极限；
大师级程序员的工作秘笈是任务分解，分解到可以进行的微操作；
按照完整实现一个需求的顺序安排开发任务。
3. 沟通反馈
通过沟通反馈，不断升级自己的编解码能力。
编写可以运行的代码
<div><span style="font-size: inherit;">编写符合代码规范的代码</span><br></div>
<div><span style="font-size: inherit;">编写人可以理解的代码</span><br></div>
用业务语言编写代码
多尝试用可视化的方式进行沟通
看板
一种来自精益生产的可视化实践。
按阶段将任务放置其中。
可以帮助我们发现问题。
技术雷达
做好持续集成，快速反馈
定期复盘，找准问题根因，不断改善
5why?
先对比实际结果和期初所定目标之间有什么差距
情景再现，回顾项目的几个阶段
每个阶段进行得失分析，找出问题原因
总结规律，化作自己的技能沉淀，再次遇到时可以规避
复盘资料应该记录到知识库
多走进用户
能做自己用户，做自己的用户
能接近用户，接近用户
没有用户，创造用户
事情往前做，有问题尽早暴露
一种编写代码的原则：Fail Fast
多输出文字，让知识有结构
4. 自动化
与机器交互的
DevOps
开发（Development）和运维（Operations）组合
一种软件交付的理念和方法，目的是增强软件的可靠性
方法
1. 谨慎地将工作自动化
了解一个技术，不是简单的了解其的实现，更是掌握它的设计
2. 将你的工作过程自动化
3. 有体系地学习运维知识
4. 持续交付，将部署纳入开发的考量
5. 将验收测试自动化
6. 把函数写短，道和术的结合
7. 构建好你的领域模型
三层设计，设计上的分解
拆分问题为小问题
目的：为了提供抽象
8. 用简单技术解决问题，直到问题变复杂
理解业务，不低估业务复杂度
理解技术，不增加技术复杂度
9. 学习领域驱动设计。
重构代码
SOLID 原则
单一职责原则（Single responsibility principle，SRP）
开放封闭原则（Open–closed principle，OCP）
Liskov 替换原则（Liskov substitution principle，LSP）
接口隔离原则（Interface segregation principle，ISP）
依赖倒置原则（Dependency inversion principle，DIP）
设计模式
7. Something Interesting
本质复杂度（Essential Complexity）和偶然复杂度（Accident Complexity）
DoD（Definition of Done，完成的定义）
德雷克公式
技术雷达
过程还原，进行研讨与分析的方式，就是复盘。
Eat your own dog food（从1988年开始，这个说法开始在 IT 行业流行的，微软的保罗·马瑞兹（Paul Maritz）写了一封“Eating our dog food”的邮件，提到要“提高自家产品在内部使用的比例。”从此，这个说法在微软迅速传播开来。）<br>
写程序有一个重要的原则叫 Fail Fast，这是什么意思呢？就是如果遇到问题，尽早报错。
靠 debug 来定位问题是最为费时费力的一种做法。
能力成熟度模型（Capability Maturity Model for Software）
当你的技术知识积累到一定程度时，还采用原来的学习方式，就很难获得真正意义上的提高，这是很多人抱怨 IT 行业不好混的原因。<br>
重构，本质上就是一个“微操作”的实践。另立门户，重新实现这套系统。对不起，你打算做的事叫重写（rewrite），而不是重构（refactoring）。<br>
优秀程序员应该有三大美德：懒惰、急躁和傲慢（Laziness, Impatience and hubris）
学习增量
DDD 分为战略设计（Strategic Design）和战术设计（Tactical Design）
