没亲手写过代码,就谈不上懂软件开发

来源：seangoedecke.com

只有那些深入参与大型软件系统开发的工程师，才能真正有效地参与设计。之所以这么说，是因为如果你不深入理解系统的具体细节，根本无法做出优秀的软件设计。

换句话说，对于解决大多数实际的软件设计问题，泛泛而谈的设计建议通常毫无用处。

什么是通用软件设计？

所谓通用软件设计，就是一种“针对问题进行设计”的模式。当你对业务领域有一定了解，但对现有代码库几乎一无所知时，给出的往往就是这类建议。

遗憾的是，我们在软件书籍和博客文章中能读到的，基本也只有这种建议。工程师们之所以热衷于分享通用设计经验，就像所有技术专家都喜欢“聊行话”一样。

但是，在解决日常工作中的具体问题时，你必须非常谨慎地使用这些通用建议。

在处理实际工作时，具体因素的影响力远超通用因素。

看清当前代码的真实面貌，比掌握通用的设计模式或原则要重要得多。比如：

• 在大型代码库中，一致性比“好的设计”更重要。这一点我在此不再赘述，我在《工程师在大型既有代码库中常犯的错误》一文中曾详细讨论过。
• 真实的系统往往牵一发而动全身，充满了难以预料的连锁反应。如果你想安全地完成代码变更，现实情况往往会把你的实现方案压缩到仅有的几种可能之中。
• 大型共享代码库从不会只体现某一种设计思想，它们总是处于不同设计方案交替的中间状态。因此，比起追求理想中的“北极星”架构，确保单次变更后代码依然能协调运行才更关键。

如果我们可以随心所欲地重写整个系统，通用软件设计建议确实会更有实践价值。

有些项目确实如此，但绝大多数软件工程工作都是在无法安全重写的系统上进行的。

这些系统不能指望理想化的“软件设计”，而必须依赖内部的一致性和工程师的严谨。

什么是具体的软件设计？

那么，好的软件设计究竟是什么样子的？

根据我的经验，最有用的软件设计往往发生在少数几位资深工程师的交谈中。他们每天都在一线编写代码，对系统有着极深的理解。

由于讨论内容大多围绕着系统内部那些晦涩、具体的细节，而不是任何技术人员都能听懂并插上几句的通用原则，所以这些讨论在局外人看来往往非常枯燥。

他们讨论的话题不是“DRY（不要重复）原则是否优于 WET（写两次也行）原则”，而是这类对话：“我们能不能把这个新功能放在子系统 A 里？

不行，因为它需要信息 B，但在上下文 C 中子系统 A 拿不到这些信息。除非重写子系统 D，否则没法暴露这些数据，但如果我们在这里拆分一下子系统 E……”

在这种讨论中，高深的设计哲学很难派上用场。

相反，最核心的贡献通常是纠正对具体细节的小误解，比如：“哦，你以为上下文 C 里拿不到 B 吗？我们最近刚重构了 C，现在根据需要已经可以把 B 传进去了。”

通用软件设计何时有用？

虽然通用建议在解决实际设计问题时作用有限，但这并不代表它一无所知。

通用软件设计建议非常适合从零开始的新项目。 正如前文所述，在现有系统中设计新功能时，系统的具体因素占据主导地位。

但当你设计一个“全新系统”时，没有任何现成的具体因素束缚你，这时完全可以参考通用建议。

通用软件设计建议可以作为具体决策时的“打破僵局者”。 我并不主张从通用设计出发，但如果你手头有几个看起来都可行的具体实施路径，通用原则可以帮你做出最终选择。

在公司层面，这一点尤为明显。也就是说，通用设计建议有助于确保不同代码库之间的一致性。

这也是“软件架构师”这一正式职位的核心价值所在：提供一套通用原则，让每位工程师在面对具体决策时，都能朝着同一个方向进行权衡。

此外，通用原则还能指导公司级的架构决策。 比如：我们应该自建机房还是上云？是否使用 Kubernetes？选 AWS 还是 Azure？一旦涉及到这种宏观层面，单个服务的具体细节就不再那么重要了，因为无论怎么选，后续的工作量都是巨大的。

不过，即便在这种决策中，具体细节依然不容忽视。有些事在云端做不到（比如依赖定制化的硬件），有些事在自建机房做不到（比如在全球 12 个地区进行边缘部署）。

如果你的代码库核心逻辑依赖这些特性，而在做公司级决策时又忽视了它们，那麻烦就大了。

架构师与“局部最优”陷阱

以上都是通用设计的合理用途。但公司热衷于搞通用设计还有一个糟糕的原因：对于那些不在一线写代码的人来说，这听起来像个绝妙的主意。

一旦开始推行，各种激励机制就会让人停不下来。许多科技公司都陷入了这种“局部最优”的怪圈。

为什么不让那些薪水最高的工程师把精力全都花在最抽象、影响力最大的决策上呢？毕竟，你肯定希望结构工程师负责画图，而不是去搬砖。

我不确定建筑行业是否如此，但我确定软件行业绝非这样。

在实践中，一线人员往往不得不无视架构师给出的建议。原因很简单：在现有系统的背景下，这些抽象建议根本无法转化为可落地的代码。

然而，这种并不凑效的做法——“让顶尖工程师只做通用设计”——却在企业中出奇地稳固。之所以如此，是因为架构师不需要为结果负责（即“没有利益相关”）。

他们把设计方案丢给实际的工程团队去实现，而由于这些设计永远不可能被完美落地，架构师既可以在成功时居功（毕竟是按我的设计做的），又可以在失败时推卸责任（要是那些笨蛋完全照我的设计做就好了！）。

总结

在处理大型既有代码库时，有价值的设计讨论要比大多数人想象的具体得多。这些讨论通常会深入到某个特定的文件，甚至某一行代码。

因此，如果你不亲近代码库（在实践中，这通常意味着你得是个活跃的代码贡献者），就无法做出真正有用的软件设计。

纯粹的通用架构并非一无是处，但其作用应严格限定在以下范围：(a) 为新系统铺路；(b) 在现有系统决策中打破僵局；(c) 协助公司做出重大的技术选型。

在我看来，那些整天只负责勾勒项目初始蓝图、脱离实际的“大局观架构师”注定会失败。

这种职位听起来很美（对架构师本人也很有利，因为可以揽功而不担责），但对于真正负责写代码的团队来说，几乎提供不了什么价值。

我个人坚信：如果你为一个软件项目构思了设计方案，你就必须为该项目的成败负责。

只有这样，才能确保设计系统的人正是那些知道如何交付系统的人。

同时也只有这样，才能让那些真正痛苦地权衡代码库各种瑕疵、完成艰难设计工作的“实干派”设计师得到应有的认可。