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

图 1. 设计图

图 1 中的图谱左侧表示您可以预见在开发软件时出现的所有成百上千个关注 点，并且尝试限制您对这些关注点的响应。您将在后续文章中阅读关于这句话的 更多内容。因为我不花大量时间定义 设计并不表示我不会花大量时间讨论它。在 编写第一行代码之前，本系列的大部分内容将介绍如何伴随着开发展开设计（而 不是一成不变）的各个方面。

演化架构与紧急设计：研究架构和设计(3)

架构及设计关注点

比较演化 与突发

注意本系列称为 演化架构和突发设计。演化 与突发 为什么会有区别？我的 同事向我指出，突发架构 不是一个热门的概念。如果您接受架构是以后难于更改 的部分这一前提，就很难接受逐步显现的架构。架构关注在启动应用程序之前必 须存在的基础元素。但是，仅仅因为您无法让架构显现并不意味着它无法演化。 如果您已经创建了一个灵活的架构并且避免作出无法撤回的决定，则可以允许它 在出现新关注点时演化。

使用手头现有的架构和设计定义，我希望深入研究一些全局性的关注点。所有 这些主题都与基础级架构和设计有关，因此预先介绍这些内容使我可以在本系列 后期文章中引用这些内容。首先，我将讨论技术债务（technical debt），然后 讨论复杂度，最后讨论过度的一般性（rampant genericness）。

本金和利息

每位开发人员都开始注意到技术债务 的概念，您可能由此而迫于外部压力（ 例如日程压力）在设计中有所折衷。技术债务类似于信用卡债务：您目前没有足 够的资金，因此您借用未来的资金。同样地，您的项目没有足够的时间来做正确 的事情，因此您使用一种及时的解决方案并希望在未来的一段时间回过头来进行 改进。糟糕的是，许多经理人似乎都不理解技术债务，因而不愿意重新完成旧的 工作。

构建软件并不是挖壕沟。如果在挖沟时有所折衷，则只能得到一条宽度不均匀 或者深度不同的沟。今天挖一条有缺陷的沟与您明天挖出一条好沟没什么关系。 但是您今天构建的软件是您明天所构建内容的基础。现在为了权宜而做的折衷将 导致软件中的熵 不断增大。在 The Pragmatic Programmer 一书中，Andy Hunt 和 Dave Thomas 谈到了软件中的熵以及为什么它有这样一种不利影响。熵是复杂 度的度量标准，而如果您现在由于某个问题的及时解决方案增加了复杂度，则必 须在项目的剩余生命周期内为此付出一些代价。

假设您需要向一个现有的长期项目中添加新功能。这些新功能拥有某些内在的 复杂度。但是，如果您已经拥有技术债务，则必须解决系统中那些折衷部分才能 添加新功能。因此，添加新功能的成本将反映财务状况。图 2 显示了在设计简约 的系统（例如，拥有很少技术债务或者没有技术债务的系统）中和在包含大量技 术债务的典型系统中，在添加新功能所需付出的努力方面的差别。

图 2. 技术债务与利息

您可以把内在复杂度视为本金，而把前几条作为权宜之计的捷径所强加的额外 工作视为利息。复杂度本身是一个非常有趣的题目。

演化架构与紧急设计：研究架构和设计(4)

本质复杂度与偶发复杂度的比较

我们在软件中解决的问题具有内在复杂度，我将它称为本质（essential）复 杂度。由导致技术债务的折衷引发的复杂度是不同的。它包含使软件变得复杂的 所有外部强加方法，并且这种复杂度是不应有的。我将此称为次要（accidental ）复杂度。我在 The Productive Programmer 一书中定义并深入讨论了这些术语

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