第 8 章：项目启动之前
系列：程序员修炼之道 · 第 8/9 章
一句话总结
编码之前弄清需求、利益相关者与约束；用原型说服、用维护视角审视规格，避免在错误问题上写出完美代码。
核心观点浓缩
- 需求是流动资产：挖掘真实需要，而非仅收集愿望列表
- 维护与遗忘：多数成本在维护；今日决策明日买单
- 规格与政策：区分可测需求与官僚条款
- 用原型说服：可视化胜过争论
- 无人确切知道：承认不确定性，迭代澄清
- 学会说「不」与「是，但是…」：管理范围
关键概念 / 金句
- 「Requirements are learned in a feedback loop」
- 维护期成本常远超初版开发
本章在全书中的位置
把务实哲学拉到项目前段，与第 9 章交付形成首尾。跳过本章易「高效地做错事」。
个人思考与启发
面扫项目：「必须支持某云」是政策还是可测需求？导出格式、日志上传失败体验应写成可验收条目。
原型：用假 mesh 演示订单流程，比 PPT 更早暴露工作流缺口。
与《软件设计的哲学》对照
- 需求模糊是复杂度来源之一（依赖与模糊）
- 原型学习 ↔ 战术式一次性代码；曳光弹 ↔ 可演进骨架
- 「决定什么重要」（Ousterhout 第 21 章）在立项阶段就要开始
重点与注意
重点：需求靠反馈环澄清，不是一次性文档冻结。
重点：维护与运维视角应尽早进入设计。
重点：原型用于沟通与学习，与曳光弹目的区分。
注意：规格中的政策性条款要识别，避免无法验收。
注意：说「不」时要带替代方案（务实沟通）。
导航：上一篇：第 7 章 · 下一篇：第 9 章 务实的项目