演化架构与紧急设计: 研究架构和设计

核心提示： 偶发复杂度的第三个诱因是不可逆性，您做出的无法逆转的所有决定都将最终导致某种程度的偶发复杂度，演化架构与紧急设计: 研究架构和设计(8)，不可逆性将同时影响架构和设计，尽管它的影响在架构级别上比较常见并且比较有破坏性，每篇文章将深入探究这些概念中的一个或两个概念的特别说明，其中包含大量详细信息和

偶发复杂度的第三个诱因是不可逆性。您做出的无法逆转的所有决定都将最终导致某种程度的偶发复杂度。不可逆性将同时影响架构和设计，尽管它的影响在架构级别上比较常见并且比较有破坏性。尽量避免作出不可逆转或者难于逆转的决定。我的一些同事信奉在最后责任一刻 做决定。这并不表示您应当把决定推迟得太久，只要推迟得比较久就足够了。什么时候才是决定某些架构关注点的最后责任时刻？做决定的时间拖得越晚，您为自己留下的可能性就越多。问问您自己：“我是不是现在就需要做那个决定？” 以及 “我做什么能让我推迟那个决定？” 如果在决策过程中应用一些技巧，那么您将会对您可以推迟的内容感到十分惊讶。

前面所述的框架级架构和应用程序架构之间的区别将与 “最后责任时刻” 原则联系起来。应用程序架构一般为逻辑架构。例如，假定您知道需要分离模型-视图-表示器（Model-View-Presenter）关注点。通常，通过选择满足部分或全部需求的框架，您可以成功实现这种逻辑架构的物理实现。看看您是否可以推迟该决定，因为一旦物理实现就位后，它将限制必须考虑的其他类型的决定。尽可能推迟框架决定将使您获得受实际情况影响较小的更好选择。

过度的一般性

架构与设计的最后一个全局关注点，我将之称为过度的一般性。Java 世界里似乎有一个弊病：通过尝试使解决方案尽可能一般化来过度设计解决方案。这样做的动机十分明显：如果我们构建许多扩展层，我们稍后可以在其上更轻松地构建更多层。但是，这是一个危险的陷阱。因为一般性将增加熵，所以您将破坏在项目初期中通过有趣的方式演化设计的能力。增加过多灵活性将使对代码库的每一次更改都变得更加复杂。

当然，您不可以忽略可扩展性。敏捷的移动性在决定如何实现功能时很重要：YAGNI（You Ain't Gonna Need It）。这是避免过度设计简单功能的信条。只实现目前需要的功能，在以后您需要更多功能时，可以再进行添加。我看到过某些 Java 项目为了实现一般性和可扩展性，在架构与设计方面使用了大量折衷，最后导致项目失败。这是个令人感到讽刺的教训，因为本来希望尽可能延长项目的生命周期，结果反而缩短了生命周期。了解如何把握可扩展性与过度设计之间的微妙界限十分困难，而且它是我将反复说到的主题。

路线图

本文包含大量文字叙述而没有源代码，因此不同于本系列中所有其他后续文章。讨论像架构与设计这样的复杂主题时，固有的问题之一就是必须具备可以确保所有人都在同一个情境中的上下文设置。我已经为本系列的其余文章打好了基础，我将在其中深入探究与演化架构和紧急设计相关的具体领域。每篇文章将深入探究这些概念中的一个或两个概念的特别说明，其中包含大量详细信息和源代码。下一部分：我将通过测试驱动开发（我已经将其命名为 测试驱动设计）讨论紧急设计。