演化架构与紧急设计: 积累惯用模式

紧急设计和惯用模式

您认为 Struts 的原设计者曾经想到过处理参数所需的代码有多少吗？软件就是这样。有时候可以根据问题域的理论知识预测复杂性，但是在编写代码时，又会产生新的约束和机会，这些实际上是无法预测的。实际上，资深的开发人员在预测那样的 “硬骨头” 方面并不会做得更好。他们只是更相信，那个神秘的硬骨头最终会出现。

紧急设计的魅力之一是有这样的认识：我们不能可靠地预测什么会变成硬骨头，但是我们应该对此保持警惕。如果带着发现抽象和模式的期望去看代码库，就更容易有所发现。

最后我以一个案例研究作为结束，该案例研究基于一个 ThoughtWorks 项目，这是我间歇性地从事的一个项目。在这个大型 Ruby on Rails 项目的早期，技术主管意识到，在一些单独的情况下需要异步行为（例如，上传大量的图像时，用户需要能够暂时离开页面，之后再回到页面）。如果我们存着 Big Design Up Front 的思维，那么就会立即寻求一个消息队列。但是，在项目一开始，我们还不能完全知道有哪些地方需要异步，一般的态度是寻求最大的消息队列，以确保能处理将来的新需求。但是我们的技术主管非常明智地没有那样做。他决定我们已有的足以适合当前状况。

时间往后推移 2 年。到现在，应用程序有 3 个不同的异步行为，当前解决方案开始成为瓶颈。现在，是时候使用一个消息队列了。但是，由于技术主管推迟了如此长的时间才做决定，我们现在十分清楚这个应用程序在消息传递方面的需求，因此可以采用最简单的工具来完成该任务。由于耐心等到最后可靠时刻才做决定，我们避免了因一个并不那么需要的工具带来的意外复杂性而做的数年的工作 — 从而获得更简洁的代码，使新特性具有更高的速度，也减少了相关的烦人的工作。

让代码引领设计，这意味着对需求有更好的理解。设计决定推迟得越久，最终做出具有长期意义的决定时，便拥有更清晰的路线。

结束语

本系列的很多文章都是在向您灌输一些上下文，使您明了真正的优点。本期几乎将本系列之前的每篇文章都贯穿起来，利用那些文章中提到的技巧、工具和态度。紧急设计要求具有看到和积累惯用模式和抽象、工具和技巧的能力，以便在它们出现时能够利用它们。Design up front 有助于发现重要的部分（敏捷项目要做足够多的预先设计，以决定那些事情），但是开始编写代码后，仍应该保持警惕，您将发现令人惊讶的重要的设计元素。每个代码库都有惯用模式。您必须学会发现它们并采取行动。

在最近几期，我几乎都是在谈论设计和相关的问题。下一次，我将重新深入研究演化架构，并展示将敏捷开发技巧与架构概念相结合时出现的一些常见问题和解决方案。