设计过度，构建恰到好处

Source: Dev.to

“过度工程是缺乏经验的工程师的标志”

引言

“最简单的解决方案永远是最好的” 这一理念在全球的计算机科学课堂上被反复灌输。我也曾深信不疑，花费数小时重新设计系统，以期让它们尽可能简洁——结果却发现自己走得太远，最终又得重新设计。到一天结束时，我花在微调设计上的时间比实际实现的时间还多。

在实习期间与资深工程师的交谈让我认识到，过度工程也可以是一种资产。例如在机器人领域，我开始把过度工程视为一种可以被拥抱的技能，而不是必须压制的缺点。

事实是，简单的实现比过度工程的实现更好，但 过度工程的设计是确保这些简单实现正确的有价值工具。

基本准则

过度工程是危险的；人们之所以被警告不要这么做，是有原因的。为了避免弊大于利，我们需要遵循严格的基本准则。

过度工程的方案绝不应完整实现

先设计一个覆盖尽可能多边缘情况的宽泛方案，然后在实现时毫不留情地简化。设计阶段思考失败模式要比事后发现它们容易得多。把过度工程当作一种心理压力测试，而不是生产蓝图。

方案复杂度应匹配问题复杂度

一个待办事项应用不需要虚拟机的架构。对复杂问题进行过度工程可以是风险管理；对简单问题进行过度工程则只是拖延。

清晰胜于巧妙

最终方案必须清晰。没有人会在乎那些妨碍理解的巧妙单行代码或“10 倍工程师”技巧。编写稳健的代码，让他人（以及未来的自己）能够阅读，并记录 为什么（why）而不是仅仅是 做了什么（what）。

理解问题空间

“我唯一知道的就是我一无所知。” – 苏格拉底

过度工程不应是炫耀，而是探索。没有人能对每个问题了如指掌，而要辨别自己需要了解的内容也并不容易。过度工程迫使你提出正确的问题：

• 我的模拟器是否应该使用空间哈希，还是会带来太多开销？
• 我的均衡磨损算法是否需要包含位掩码，还是我在存储不必要的信息？

没有必要把不属于的东西强行塞进设计中，但排除的门槛应该设得很高。准确知道某个问题 不需要 某种解决方案的原因，与知道它 需要 的原因同样重要。

扩大设计的覆盖面还能带来一个隐藏的好处。

失效覆盖

“你能做的最好的事，就是在写代码之前把所有可能出错的情况都想清楚。过滤掉非问题要比事后再去补救好得多。”

我技术主管对我的均衡磨损方案随口说的一句评论一直让我记忆犹新。我最初尝试处理每一种可能的错误：页面磨损、写入中途的掉电、辐射导致的位翻转等。一次性实现所有这些几乎不可能，但这个练习帮助我辨别出哪些边缘情况真正重要。

当你在设计阶段进行过度工程时，你为未来的自己铺平了道路。实现本身已经很困难；如果还要为未预见的失效模式临时发明新的设计部件，只会增加决策疲劳。

收益并非仅仅是务实的。过度工程可以很有趣——一种探索性的游戏，能激励你前进。如果你倾向于过度工程，拥抱它，但要适度约束。