你的 Bug 可能正是别人的功能

软件工程的魔幻定律(17)

定律之间的矛盾：这才是真正的挑战

这些定律最有意思的地方不是每一条单独看，而是它们放在一起时的张力：

DRY 与 YAGNI 的矛盾：为了消除重复引入抽象，但那个抽象可能是你不需要的。
Gall’s Law 与 Second-System Effect 的矛盾：从简单开始演化，但当你要重写成熟系统时，又容易过度设计。

Knuth’s Optimization Principle 与现代性能要求的矛盾：HackerNews 讨论中有人指出，在 1974 年，优化意味着写汇编；在今天，架构层面的性能决策必须在一开始就做，否则后期根本无法修改。

这些矛盾没有统一答案。定律给你的是框架，不是算法。知道这些规律，是为了在具体场景下做出更有意识的权衡，而不是为了找到一个万能的规则并死守它。

给工程师的实用地图

flowchart TD
    A[遇到工程决策] --> B{什么类型的问题?}
    B -->|项目延期/进度压力| C["Brooks's Law\nHofstadter's Law\n90-90 Rule"]
    B -->|架构设计选择| D["Gall's Law\nConway's Law\nYAGNI/KISS"]
    B -->|代码质量/维护| E["Boy Scout Rule\nKernighan's Law\nDRY/Law of Demeter"]
    B -->|团队与组织| F["Dunbar's Number\nBus Factor\nConway's Law"]
    B -->|指标与度量| G["Goodhart's Law\nGilb's Law"]
    B -->|技术决策倾向于放弃| H["Sunk Cost Fallacy\nConfirmation Bias"]

结语

这些定律存在的价值，不在于给你提供一套可以机械执行的规则，而在于给你一个词汇表——用来描述你已经见过、但可能还没有命名的现象。

当你下次看到一个团队因为引入了太多新成员导致沟通成本激增时，你知道那是 Brooks’s Law 在起作用。当你看到一个 API 的某个 bug 被用户当成特性使用，不敢轻易修复时，你知道那是 Hyrum’s Law 的经典案例。

有了名字，才能更清晰地讨论，才能更有意识地决策。