工程化取舍
你将学会什么
Section titled “你将学会什么”- 识别「完全没有工程意识」和「过度工程化」两种错误
- 用一条标准判断工程化程度是否合适
- 列出适合简化与值得补结构的两类场景
学生阶段常见的两个错误是「完全没有工程意识」和「过度工程化」。真正实用的工程化判断标准只有一条：这个结构是否降低了当前团队的维护成本。
以下情况适合继续简化：
- 一个人完成的小项目
- 一周内就会停止维护的课程实验
- 没有后续协作或展示需求的临时工具
以下情况值得补工程结构：
- 多人协作或课程评审
- 后续还要继续扩展功能
- 希望把它放进作品集或开源展示
换句话说，工程化用来帮你减少重复投入，把时间留给真正重要的事情。每加一个工具、一层抽象之前，先问一句：它现在就在降低维护成本吗？如果答案是「以后可能有用」，那大概率属于过度设计。
维护成本怎么具体衡量？
Section titled “维护成本怎么具体衡量？”「维护成本」听起来抽象，实际上可以从三个方向具体感受：理解成本、修改成本、交接成本。理解成本是别人读懂这份代码要花多久；修改成本是加一个功能或改一处逻辑要动多少地方；交接成本是另一位同学接手时，需要多少说明才能继续。任何工程结构只要在其中一个方向上带来明显节省，就值得保留；三个方向都没有变化时，它通常只是在增加工作量。
什么情况属于过度设计？
Section titled “什么情况属于过度设计？”过度设计有一个典型特征：为「以后可能用到」的场景提前预留结构。这类预留建立在假设之上，而假设中的场景多数不会出现。更稳妥的次序是先按当前需求做出最简版本，等真实需求出现再补结构，届时你对需求的理解更完整，补上的结构也更贴合实际。Wikipedia 的 You aren’t gonna need it 条目把这一原则概括为：需求出现之前，不要为它编写代码。
取舍决定为什么要记下来？
Section titled “取舍决定为什么要记下来？”把取舍过程记录下来也有价值。做完取舍表后，在每个保留或砍掉的条目旁补一句当时的理由，包括被放弃的方案。这样过一段时间再看，你能快速回忆起当时的判断，课程评审时也能解释为什么某些结构没有出现。记录本身几乎不增加维护成本，却能避免同一问题被反复讨论。
先自己回答，再看答案：
- 判断工程化程度是否合适的唯一标准是什么？
- 「一周内停止维护的课程实验」更适合简化还是补结构？
- 为什么「以后可能有用」不是加功能的充分理由？
参考答案
- 是否降低了当前团队的维护成本。
- 更适合简化，因为投入的结构无法在短期内回收。
- 为「可能有用」投入的结构，多数最终用不上，反而增加维护负担。
- 两个极端：完全没有工程意识 vs 过度工程化
- 判断标准：是否降低当前团队的维护成本
- 简化与补结构都服务于「减少重复投入」
- 过度工程化（Overengineering）——介绍过度设计的常见表现与代价
- You aren’t gonna need it（YAGNI）——说明为什么不要在需求出现前实现功能