根据开发文档,执行开发任务
开发前先按开发文档提及的内容,结合项目文档充分理解开发背景和上下文。
选定开发任务
用户指明了做哪份开发文档就做哪份。没指明时,自己到开发文档目录(默认 docs/development/,
项目有自己的文档规范时按它规定的目录)里挑一个当前最适合开工的里程碑,按以下判据:
- 优先接着已开工的主题往下做——有里程碑已勾了一部分,或前序里程碑已收尾的主题
- 同一主题内按编号取第一个没做完的里程碑;前序里程碑还没收尾的不能跳过去做后面的
- 多个主题都可开工时,取依赖最少、能独立测试独立合并的那个
- 选定后先告诉用户做的是哪个里程碑再开工
- 目录是空的,或候选之间取舍不清(优先级相当、互相有依赖),列出候选让用户拍板,不要自己硬挑
如何读开发文档
- 总览文档:主题目录下的
README.md——问题描述、解决方案概述、关键设计决策; 拆成多个里程碑时这里还有里程碑清单与进度 - 里程碑文档:按编号排序的文件,一份对应一个能独立测试、能独立合并的里程碑, 开头点明目标与完成判据。编号即依赖顺序,按顺序做
- 只有
README.md的目录:说明这个主题只有一个里程碑,总览与里程碑内容都在这一份里, 按它开发即可,不要另建编号文档 - 已完成的里程碑文档:开工前先读它依赖的那几份的「落地状态」节——那里写着实际做成了什么、 留下了哪些过渡层。过渡层都标了 TODO,不要当成遗漏顺手删掉,各自写明了由哪个里程碑删
如何了解项目上下文
- 项目有自己的文档规范就先读它,文档目录与本项目额外的规则以它为准
- 否则从文档索引(默认
docs/README.md)入手,按项目地图定位要动的模块, 再读对应的产品文档确认现有行为
进度标记
- 落一项勾一项:完成开发文档里的一个 checkbox 条目就立即勾上,严禁攒到最后批量勾
- 跳过已完成:条目已勾完的里程碑文档直接跳过
里程碑收尾
| 未完成条目 | 能否收尾 |
|---|---|
| 全部勾完 | 可以 |
| 有未完成,但已有明确去向(挂到后面某个里程碑、或等外部条件) | 可以,就地写明去向 |
| 有未完成,且无明确去向 | 不可以,先移进另一份文档单独排期 |
收尾分三步,前一步没做完不许做下一步。
1. 固化
把本里程碑做完的东西里有长期价值的部分整理进产品文档与项目地图。
- 判据是读代码本身得不到、但接手时必须知道;纯内部实现细节、换实现而外部行为不变的改动不写
- 项目有自己的文档规范的按它的规定做
- 没有的自己整理,落笔前必须先完整读一遍要改的那几份文档
- 刻意留下的过渡层不进产品文档,除非它造成了用户看得见的行为差异——那就如实写现状并标明是过渡态, 但不写计划、不带里程碑编号
2. 写落地状态
判据是本里程碑有没有东西要交给后面,与主题里有几个里程碑无关:
| 类型 | 判据 | 这一步 |
|---|---|---|
| 自足里程碑 | 没有东西要交给后面的里程碑 | 跳过 |
| 留账里程碑 | 留下了后面要拆的过渡层、要接的接口,或要后面了结的口径 | 写「落地状态」 |
在本里程碑文档开头、正文之前加一节「落地状态」,写:
- 最终形态与原计划的差异
- 刻意留下的过渡层 / 临时兼容层,逐条写明由哪个里程碑删掉;代码里同步标
TODO - 交给后续里程碑的账:眼下没有调用方的接口、尚未统一的口径、待补测的项
- 验证方式,以及没验证的部分
正文里作废的计划不必清理。顺手更新 README.md 总览里的里程碑进度。
3. 删除
| 类型 | 本里程碑做完时怎么做 |
|---|---|
| 自足里程碑 | 确认已固化,删掉这份文档,README.md 总览里对应的条目一并删掉 |
| 留账里程碑 | 不删,等它交出去的账全部了结才能删——账还没人接就删掉,接手的人只能从代码反推 |
整个主题的文档都删完时,把主题目录一起删,不留痕。