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

核心提示： 图 1. 设计图图 1 中的图谱左侧表示您可以预见在开发软件时出现的所有成百上千个关注点，并且尝试限制您对这些关注点的响应，演化架构与紧急设计: 研究架构和设计(5)，您将在后续文章中阅读关于这句话的更多内容，因为我不花大量时间定义 设计并不表示我不会花大量时间讨论它，糟糕的是，许多经理人似乎都

图 1. 设计图

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

架构及设计关注点

比较演化 与突发

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

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

本金和利息

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