用简单规则避免过度工程 | AI生成和翻译
问题：Wang Yin 的《The Wisdom of Programming》中“防止过度工程”部分说了什么？
答案：
防止过度工程
Wang Yin 一开始承认了一个讽刺的事实：尽管每个人都知道过度工程很糟糕，但工程师们仍然反复陷入其中——包括他自己。因此，他分析了早期的警告信号，这样你就能在它扎根之前捕捉并避免它。
警告信号 #1：对未来的痴迷
第一个主要信号是当你开始过多思考尚未发生的事情时。他举的例子：
- “如果有一天我们有数百万行代码和数千名工程师，这个工具就不会 scale。”
- “将来我可能需要这个功能，所以现在就写好代码并留着。”
- “以后很多人会扩展这段代码，所以现在就应该让它 reusable。”
这正是为什么这么多软件项目变得如此复杂的原因。实际上，并没有完成多少实际工作，但代码库却因为“未来”的名义而膨胀了不必要的复杂性。当下的问题甚至还没有解决，项目却已经被假设的未来担忧压垮了。
他的观点：有时在实际工程中，你需要聚焦眼前——先解决眼前的问题，然后再谈未来的 extensibility。
警告信号 #2：对代码重用的痴迷
过度工程的第二个来源是对 reusability 的过度关注——甚至在你还没有写出能工作的代码之前。过早试图让代码 reusable 会导致构建复杂的框架，反而束缚自己的手，最终连一个基本的能工作版本都写不出来。如果你一开始就无法写出能工作的代码，让它“reusable”又有什么意义？
他指出，许多从第一天起就围绕 reusability 构建的项目最终完全被废弃——因为其他开发者觉得代码太难理解，干脆从头重写更容易。
警告信号 #3：对测试的痴迷
过度关注测试也会导致过度工程。有些开发者将原本简单的代码扭曲成“test-friendly”的形状，引入了如此多的复杂性，以至于代码——本可以一次写对——最终充满了 bug。
他区分了两种“无 bug”的代码，这让人印象深刻：
- “没有明显 bug 的代码”——复杂、大量测试、覆盖率指标很高，我们 假设 它正确，因为测试通过了。
- “明显无 bug 的代码”——如此简单直接，即使没有很多测试，你一看就知道它不可能错。
他明显更喜欢第二种。
他的三个防止过度工程的原则
他将一切总结为三个简洁规则：
- 先解决眼前的问题，并解决好——然后再考虑未来的 extensibility。
- 先写出能工作的代码，反复精炼——然后再考虑是否需要 reuse。
- 先写出能工作、简单、明显无 bug 的代码——然后再考虑测试。
本节贯穿始终的底层哲学与文章其余部分一致：简单性是一种美德，过早的复杂性——无论听起来多么前瞻——仍然是一种失败形式。
参考：