演化架构和紧急设计: 利用可重用代码，第 1 部分：代码与设计之间的关系

核心提示：通过本 系列 的前几期，您已经知道，演化架构和紧急设计: 利用可重用代码，第 1 部分：代码与设计之间的关系，我的观点是软件的每个部分都包括可重用的代码块， 例如，其他工件只能为创建代码提供帮助，但是最终的设计成果还是源代码本身，公司处理安全性的方式在整个应用程序甚至多个应用程序中可能都是一致的， 这就是我所说的 惯用

通过本 系列 的前几期，您已经知道，我的观点是软件的每个部分都包括可重用的代码块。 例如，公司处理安全性的方式在整个应用程序甚至多个应用程序中可能都是一致的。 这就是我所说的 惯用模式 的实例。这些模式代表对构建软件特定部分时遇到的问题的常用解决方案。惯用模式有两种类型：

技术模式 —— 包括事务、安全性和其他基础结构元素。

域模式 —— 包括单个应用程序内或跨多个应用程序的业务问题的解决方案。

在前几期中，我将大部分注意力放在如何发现这些模式上面。但是，发现模式之后，必须能够将它们作为可重用代码加以利用。在本文中，我将研究设计与代码之间的关系，特别是表达性强的代码如何使模式的累积变得更容易。您将看到，有时候通过改变抽象风格，可以解决一些看似难以解决的设计问题，并且可以简化代码。

设计即代码

早在 1992 年，Jack Reeves 写了一篇题为 “What is Software Design?” 的思维敏锐的论文。在此文中，他将传统的工程（例如硬件工程和结构工程）与软件 “工程” 作了比较，目的是为软件开发人员拿掉工程这个词上的引号。这篇论文得出一些有趣的结论。

Reeves 首先观察到，一项工程最终交付的成果是 “某种类型的文档”。设计桥梁的结构工程师不会交付真正的桥。其最终成果是一座桥的设计。然后，这份设计被传到一个建筑团队手上，由他们来建造真正的桥梁。对于软件而言，类似的设计文档是什么呢？是餐巾纸上的涂鸦、白板上的草图、UML 图、时序图还是其他类似的工件？这些都是设计的一部分，它们合起来仍不足以让制造团队做出实际的东西来。在软件中，制造团队是编译器和部署机制，这意味着完整的设计是源代码 — 完整的 源代码。其他工件只能为创建代码提供帮助，但是最终的设计成果还是源代码本身，这意味着软件中的设计不能脱离源代码。