先设计后编码 是做什么的？
概述
工作流按顺序依次推进五个阶段：头脑风暴 → 规格说明 → 计划 → 执行 → 记录。 在设计和批准完成之前，不进行任何实现。最简单的任务中，未经检验的假设往往代价最高。
违反本规则的文字即违反其精神。“边写边设计”并非真正的设计。
五个阶段
- 头脑风暴。 探索意图、约束和成功标准。一次只问一个问题。提出2-3种方案，附带权衡分析和推荐意见。收敛到一个设计并获得明确批准。此阶段不写代码。
- 规格说明。 将批准的设计写入带日期的文档。规格说明是构建内容的合同。
- 计划。 在接触代码之前，将规格说明分解为有序、可审查的实现计划。
- 执行。 按照计划实现，设置审查里程碑。
- 记录。 将构建的内容及原因浓缩为决策记录（参见
recording-decisions）。
分解大型工作。 如果请求涉及多个独立子系统，请先分解再细化细节。每个子项目运行自己的周期，按依赖顺序构建。
何时不使用
真正琐碎、可逆的修改（拼写错误、日志行、配置值）可以直接跳到执行阶段。判断标准：在此处猜错，代价是否超过设计步骤？ 如果是，则先设计。
常见借口
| 借口 | 真相 |
|---|---|
| “这个太简单，不需要设计” | 简单任务隐藏着假设。几句话的设计很便宜，重写则不便宜。 |
| “我会边写边设计” | 设计尚未确定时编写的代码，就是需要重写的代码。设计是独立的行动。 |
| “用户告诉我要构建什么，那就是设计” | 请求说的是做什么，而不是怎么做。怎么做才是设计。 |
| “先探索代码库就能找到方法” | 探索可以为设计提供信息，但不能取代对方案的批准。 |
| “我们很急” | 着急正是跳过设计会产生返工工作的时候。 |
危险信号——停止
- 在获得批准的设计之前就打开编辑器
- “让我快速原型一下”（没有规格说明的原型就是未经审查的范围扩展）
- 在没有计划的情况下开始多文件修改
- 将用户的一行请求当作完整的规格说明
这些都意味着：停止，设计，获得批准，然后再构建。
完整理由：工程宪章的第一条，见 engineering-constitution/references/engineering-constitution.md。