演化架构与紧急设计：研究架构和设计 - 编程入门网

我的一个同事为一家具有工会组织的公司做过一个工资系统。该工会为其某些 成员争取的一项福利是在狩猎季节开始时有一天额外的休假（嘿，他们一定是有 优秀的谈判代表）。涉及的员工只在一家工厂工作，但是提供额外的休假是整个 公司的工资系统的合法部分。这项更改给软件增添了许多复杂度，但是它是本质 复杂度，因为它属于待解决的业务问题。

图谱中更远一点始终出现另一个示例：输入表单的字段级安全性。许多业务人 员都认为 他们需要对每个字段的安全特性进行精细控制。实际上，一旦实现这样 的精细控制，他们几乎总是很讨厌它，因为这将给需要定义和维护所有元数据的 用户带来负担。我们的一个项目中的业务人员真的非常需要此功能，因此我们为 他们在其中一个屏幕中实现了部分此功能。在他们粗略意识到使用此功能所需的 工作后，他们决定，由于访问应用程序的惟一方法是通过一间上了锁的办公室， 因此他们可以采用更粗粒度的安全性。这是一个在业务人员认识到他们认为必需 的功能之后做出设计决定的优秀示例。

在图谱中朝向偶发复杂度的最远端是纯管道实践，如 Enterprise JavaBeans （EJB）技术的前两个版本和 BizTalk 等工具。许多项目都需要这些工具所引入 的额外负载，但是它们只是给使用它们的大多数项目增加了复杂度而已。

有三个问题可能会产生偶发复杂度。我已经讨论了第一个：由于日程或其他外 部压力而导致临时大量削减代码。第二个是复制，The Pragmatic Programmers 中称其为对 DRY（不要重复自己，Don''t Repeat Yourself）原则的违背。复制是 软件开发中最能让人在不知不觉中降低软件质量的因素，因为在开发人员甚至还 没有觉察的情况下，它会蔓延到许多位置。一个明显的例子是复制并粘贴代码， 但是也存在大量更复杂的示例。例如，几乎所有使用对象-关系映射工具（例如 Hibernate 或 iBatis）的项目都存在大量复制。您的数据库模式、XML 映射文件 和后端 POJO 拥有略为不同但是重复的信息。通过创建这些信息的标准来源并生 成其他部分有可能解决此问题。复制对项目有害，因为它不利于做出结构更改或 重构为更好的代码。如果您知道需要在三处不同的位置更改某个内容，那么即使 有利于代码的长期运行，也应该避免这样做。

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

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

过度的一般性

架构与设计的最后一个全局关注点，我将之称为过度的一般性。Java 世界里 似乎有一个弊病：

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!