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

核心提示： 我的一个同事为一家具有工会组织的公司做过一个工资系统，该工会为其某些成员争取的一项福利是在狩猎季节开始时有一天额外的休假（嘿，演化架构与紧急设计: 研究架构和设计(7)，他们一定是有优秀的谈判代表），涉及的员工只在一家工厂工作，如果您知道需要在三处不同的位置更改某个内容，那么即使有利于代码的长期

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

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

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

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