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

核心提示： 构建软件并不是挖壕沟，如果在挖沟时有所折衷，演化架构与紧急设计: 研究架构和设计(6)，则只能得到一条宽度不均匀或者深度不同的沟，今天挖一条有缺陷的沟与您明天挖出一条好沟没什么关系，这些术语一般不是一成不变的：它们存在于图谱上，就像设计一样，但是您今天构建的软件是您明天所构建内容的基础，现在为了

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

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

图 2. 技术债务与利息

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

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

我们在软件中解决的问题具有内在复杂度，我将它称为本质（essential）复杂度。由导致技术债务的折衷引发的复杂度是不同的。它包含使软件变得复杂的所有外部强加方法，并且这种复杂度是不应有的。我将此称为次要（accidental）复杂度。我在 The Productive Programmer 一书中定义并深入讨论了这些术语。这些术语一般不是一成不变的：它们存在于图谱上，就像设计一样。一些示例将帮助阐明差别。