一个实习生花三周把系统改到"极致简洁"，结果上线前发现漏了7个边界条件。这不是段子，是谷歌机器人团队的真实案例。重写耗时比初次开发还多40%，而mentor的反馈只有一句："你设计时想太少，写代码时想太多。"
01 被误解的"过度设计"
计算机课堂上有个铁律：简单即正义。复杂是坏味道，是新手标签。作者曾深信不疑，把系统改到不能再简，再推倒重来——循环往复，设计时间远超编码。
但谷歌的资深工程师给了他另一套视角。过度设计不是恶习，而是一种可训练的能力。关键区别在于：设计阶段尽情展开，实现阶段无情删减。前者是压力测试，后者才是交付物。
机器人领域的特殊性放大了这种需求。物理世界的边界条件比软件更难预测，一个未考虑的碰撞场景可能让整台机器报废。设计时的"过度"在此变成风险对冲。
02 两条铁律：什么时候该"过度"
作者总结了明确的操作边界。第一，复杂问题的过度设计是风险管理；简单问题的过度设计是拖延症。待办清单应用不需要虚拟机级别的架构，但自动驾驶的传感器融合模块值得投入十倍设计时间。
第二，最终代码必须"无聊"。没人关心你的单行魔法或10倍工程师式循环初始化——作者确实见过这种炫技，实测性能差异为零。可读性、可维护性、文档化的"为什么"才是硬指标。
这套方法的本质是认知分工：设计阶段对抗无知，实现阶段对抗虚荣。苏格拉底那句"我唯一知道的是我一无所知"，被作者当作过度设计的正当性来源——既然不可能预知所有问题，就用系统性探索来补偿。
03 从"知道"到"知道该知道什么"
具体怎么操作？作者举了两个技术决策案例。空间哈希（spatial hashing）是否值得引入？磨损均衡算法要不要加位掩码？这些问题的答案不在Stack Overflow，而在对问题空间的深度遍历。
过度设计的价值不是选出正确答案，而是逼问出正确的问题。排除的门槛应该设得很高——不是"不需要"，而是"证明不需要"。这种强迫性追问能暴露隐藏的依赖关系和失效模式。
一个细节：作者强调"不要强行把东西塞进不属于它的设计"，这与"设计时尽情展开"并不矛盾。前者是工程洁癖，后者是认知策略。区分两者的能力，作者认为是资深工程师的核心标志。
04 为什么现在重提这个话题
行业语境正在变化。AI辅助编码让"实现"成本骤降，但设计阶段的判断反而更难——当Copilot能秒出方案，人容易跳过深度思考直接验证。作者的方法论在此显得反直觉：故意放慢设计，系统性过度思考，再快速收敛。
这与精益创业的最小可行产品（MVP）哲学表面冲突，实则互补。MVP验证需求，过度设计验证技术假设。前者回答"值不值得做"，后者回答"能不能做对"。
谷歌机器人团队的实践提供了一个中间态：设计文档可以写三百页，最终代码控制在五十行。文档是思维实验的残骸，代码是幸存者的名单。
那个花200小时重写系统的实习生后来怎样了？他在复盘笔记里写："下次我会先写三百个'如果'，再决定哪十个值得代码实现。"
你的团队是怎么处理"想太多"和"想太少"的？设计评审会上，最后一个被问到的边界条件通常是什么？
热门跟贴