10x 程序员工作法

[cuixiaorui]

以终为始

重点

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

重要的思维转变

任何事物都要经过两次创造：一次是在头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation）

然后才是付诸实践，也就是实际的构建或第二次创造（Physical/Second Creation）。

在更大的上下文内发现自己的“终”。

通过推演，找到通往“终”的路径。用可度量的“数字”定义自己的“终”。

实战指南

• 遇到事情，倒着想
• 在做任何事之前，先定义完成的标准。
• 在做任何需求或任务之前，先定好验收标准。
• 默认所有需求都不做，直到弄清楚为什么要做这件事（精益创业思想）。
• 扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上。
• 尽早提交代码去集成(持续集成)
• 在动手做一件事之前，先推演一番。
• 问一下自己，我的工作是不是可以用数字衡量。
• 设计你的迭代 0 清单，给自己的项目做体检。

额外收获

• 作为程序员，你可以管理你的上级；
  1. 管理上级的预期。
  2. 帮助上级丰富知识。
  3. 说出你的想法。
• 拿老板说事的产品经理，你可以到老板面前澄清；
• 喜欢无脑抄袭的产品经理，让他回去先想清楚到底抄的是什么；
• 分清楚需求和技术，产品经理和开发团队各自做好各自的事。

迭代 0 清单

精益创业

面向不确定创造新事物的方法论

开发（build）- 测量（measure）- 认知（learn）

当你有了一个新的想法（idea）时，就把想法开发成产品（code）投入市场，然后，收集数据（data）获取反馈，看看前面的想法是不是靠谱。

这样一个反馈循环和最小可行产品的概念

[cuixiaorui]

任务拆分

实战指南

• 动手做一个工作之前，请先对它进行任务分解。
• 多写单元测试
• 我们应该编写可测的代码
• 将任务拆小 越小越好
• 按照完整实现一个需求的顺序去安排分解出来的任务。
• 要想写好测试，就要写简单的测试
• 想要管理好需求，先把需求拆小。
• 尽量做最重要的事(优先级)
• 做好产品开发，最可行的方式是采用 MVP。

拆分

• 按照一个需求、一个需求的过程走，这样，任务是可以随时停下来的。
• 检验每个任务项是否拆分到位，就是看你是否知道它应该怎么做了
• 每做完一个任务，代码都是可以提交的（所有分解出来的任务，都是独立的）

写好测试

• 只有将复杂的测试拆分成简单的测试，测试才有可能做好
  1. Automatic(自动化)
  2. Thorough(全面的) 应该尽可能用测试覆盖各种场景
  3. Repeatable(可重复的) 反复运行 结果一致
  4. Independent(独立的) 不相互依赖
  5. Professional(专业的) 测试也需要按照项目代码去维护
• 把测试写简单，简单到一目了然，不需要证明它的正确性
  1. 前置准备(given)
  2. 执行(when)
  3. 断言(then)
  4. 清理(clean)
• 为什么写不好测试：你始终是站在写代码的视角，而不是写测试的视角

用户故事

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

最佳实践

测试金字塔

• 行业中测试组合的最佳实践。
• 多写单元测试是关键。

  测试驱动开发

• 测试驱动开发的节奏是：红——绿——重构，重构是测试驱动开发区别于测试先行的关键。
• 有人把测试驱动开发理解成测试驱动设计，它给行业带来的思维改变是，编写可测的代码。

  艾森豪威尔矩阵（Eisenhower Matrix）

• 将事情按照重要和紧急进行划分。
• 重要且紧急的事情要立即做。
• 重要但不紧急的事情应该是我们重点投入精力的地方。
• 紧急但不重要的事情，可以委托别人做。
• 不重要不紧急的事情，尽量少做。最小可行产品
• “刚刚好”满足客户需求的产品。
• 在实践中，要用最小的代价找到一条可行的路径。

做法和评判标准

• 尽量不写 static 方法；
• 主分支开发模型是一种更好的开发分支模型；
• 好的用户故事应该符合 INVEST 原则；
• 估算是一个加深对需求理解的过程，好的估算是以任务分解为基础的；
• 好的测试应该符合 A-TRIP。

思想

• 分而治之，是人类解决问题的基本手段；
• 软件变更成本，它会随着时间和开发阶段逐步增加；
• 测试框架把自动化测试作为一种最佳实践引入到开发过程中，使得测试动作可以通过标准化的手段固定下来；
• 极限编程之所以叫“极限”，它背后的理念就是把好的实践推向极限；
• 大师级程序员的工作秘笈是任务分解，分解到可以进行的微操作；
• 按照完整实现一个需求的顺序安排开发任务。

额外收获

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

[cuixiaorui]

沟通反馈

实战指南

• 通过沟通反馈，不断升级自己的编解码能力。
• 用业务的语言写代码
• 多面对面沟通，少开会
• 做好持续集成的关键在于，快速反馈
• 定期复盘，找准问题根因，不断改善。
• 多走近用户。
• 事情往前做，有问题尽早暴露。
• 多输出，让知识更有结构。

最佳实践

看板

• 一种来自精益生产的可视化实践。
• 按阶段将任务放置其中。
• 可以帮助我们发现问题。

  持续集成

• 做好持续集成的关键是，快速反馈。
• 本地检查通过之后再提交。
• 找到有效的反馈方式，比如：CI 监视器。持续集成的纪律。
• 只有 CI 服务器处于绿色的状态才能提交代码。
• CI 服务器一旦检查出错，要立即修复。

  回顾会议

• 软件团队复盘的一种实践。
• 枚举关注点，选出重点，深入讨论，列出行动项，找到负责人。

  5 个为什么

• 又一个来自丰田的实践。
• 沿着一条主线追问多个问题。

思想

用信息论理解沟通反馈

写代码的进阶路径

• 编写可以运行的代码。
• 编写符合代码规范的代码。
• 编写人可以理解的代码。
• 用业务语言写代码。

  会议是一种重量级的沟通方式

• 减少参会人数。
• 找人面对面沟通。

  聆听用户声音

• 能做自己用户，做自己的用户。
• 能接近用户，接近用户。
• 没有用户，创造用户。

  Fail Fast

• 一种编写代码的原则。
• 出现问题尽早报错。

  金字塔原理

• 从中心论点，到分论点，再到论据。

知识输出（金字塔原理）

输出的过程，本质上就是把知识连接起来的过程 中心论点 分论点1 分论点2 分论点3
论据1 论据2 论据3 论据4 论据5 论据6

自上而下

先说中心论点，然后说分论点 1，用论据证明分论点 1，再说分论点 2，用论据证明分论点 2，以此类推。

自下而上

先用证据得出分论点 1，然后再得出分论点 2，最后再归纳总结出中心论点。

Fail Fast

如果遇到问题，尽早报错。

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

使用 5 个为什么找到问题根因

五问法

站会

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

[cuixiaorui]

自动化

最佳实践

持续交付

• 将生产部署纳入了开发的考量。
• 持续交付的基础设施通常包含持续集成环境、测试环境、预生产环境和生产环境。
• 构建流水线保证到了下游的交付物一定是通过上游验证的。
• 随着 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 and hubris）。
• 小心 NIH 综合症（Not Invented Here Syndrome）。
• 写好构建脚本，做好项目自动化。
• 参照 Java 知识体系，学习运维知识。
• 软件设计最基础的原则是“高内聚、低耦合”。
• 分层架构是一种设计上的分解。
• 不同业务量的系统本质上不是一个系统。
• 采用简单技术解决问题，直到问题变复杂。

实战指南

• 请谨慎地将工作自动化
• 将你的工作过程自动化
• 有体系地学习运维知识
• 将部署纳入开发的考量
• 将验收测试自动化
• 把函数写短
• 构建好你的领域模型
• 用简单技术解决问题，直到问题变复杂
• 学习领域驱动设计