前几天修复了一个历史遗留 Bug，和同事讨论时他提到了一个词——“严丝合缝的设计”。
这个词几乎瞬间击中了我，因为它与我过去坚持的设计理念完全一样，不过我将其称为“设计正确”。 但过往经验也证明，这类“设计正确”反而制造过不少 Bug，彼时我将问题归咎于“抽象不完善”。
支持这一理念的典型论据是：人体的各器官就是严丝合缝合作的。作为万物之灵的人类，值得我们从中汲取灵感。
现在重新审视这个问题时，我发现过去的理解过于片面了。
疫情期间学到的医学常识给了我新视角：人体各器官的合作并非绝对的严丝合缝，而是充满冗余和容错机制。最简单的例子，你把手指上的血管割破了，并不会造成你整个手指的缺血。
同样，若必须依赖“完美抽象”才能避免 Bug，这样的“严丝合缝的设计”真的是理想方案吗？
《程序员修炼之道（第二版）》中反复强调的核心观点是：代码应“易于修改”。
无论是设计模式还是编程准则，终极目标都是应对需求变化。无法灵活调整的设计，终将沦为技术债务。
而我曾经的“设计正确”理念，本质是落入了契约式编程（Design by Contract）的陷阱。
当时的逻辑是：A 模块调用 B 模块时已确保参数合法，因此 B 无需验证输入。
尽管我早年就意识到“设计闭环”的重要性，但在实际编码时，“性能强迫症”仍驱使我走向极端。
近年来随着对性能执念的淡化，我开始反思：这种追求“设计正确”的代码真的易于修改吗？答案显然是否定的。
精密代码如同多米诺骨牌阵列，看似严谨，却可能因一处微小改动引发系统性崩溃。过去踩过的坑已充分印证了这一点。
从“高内聚，低耦合”角度来重新审视这个问题。
若 B 模块要求调用方保证参数合法性，本质上已经形成了隐性耦合。用设计原则来描述，这违背了最少知识原则（Law of Demeter）。
根据多年经验，实现“高内聚，低耦合”的关键只有一条：
设计模块（函数/类/服务）时，永远不要假设调用方会遵守任何约定。
无论外部如何调用，模块内部必须维持自身数据一致性。
这既是我曾提过的“设计闭环”，也可称为防御式编程或容错冗余。
原则看似简单，实践却困难重重。
一个典型的开发场景是：先实现调用方 A，再开发被调用方 B。
当编写 B 时，由于已知 A 的实现细节，开发者会不自觉地利用这些信息优化 B 的性能。
这恰恰是坏的味道的开始——尽管短期运行高效，却埋下长期隐患。
假设需求变更后，需要用新模块 C 替换 A：
由于 C 与 A 的相似性，开发者容易忽略细微差异。若 B 的实现依赖了 A 的某些隐性特征，便可能催生极难发现的边界 Bug。
更棘手的难题在于：容错冗余的粒度如何把握？函数级、类级、模块级还是服务级？这需要开发者基于场景反复权衡，而每个人心中的天平刻度未必相同。
我自己现在的准则是：
ps. 函数的抽象绝不仅仅是代码复用，甚至可以说根本不是为了代码复用——抽象的本质是建立认知边界。只有深刻理解这一点，才有可能做出更好的抽象决策。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。