导读：Neal Ford是全球IT咨询公司ThoughtWorks的软件架构师。除了常规工作，他做的事情还包括设计和开发应用程序、教学材料、杂志文章、课件和视频/DVD演示，同时还是各种技术书籍的作者或者编辑，其中包括最近的新书The Productive Programmer。他专注于设计和开发大规模企业应用程序，同时，他也是世界开发人员会议的国际知名演说家。关于他的更多介绍，请查看他的个人站点。

在演化架构与紧急设计系列文章中，Neal Ford通过介绍帮助用户在演化架构和紧急设计中的灵活实践，解释演化架构和紧急设计的基本原则。他还对各种项目紧急设计的适用性，怎么确定何时制定决策以及与此相关的一些要点做出了自己的总结。

ThoughtWorks架构师Neal Ford

他在文中开头引用了美国前国防部长Donald Rumsfeld的诗：世界上有已知的未知，也就是说我们知道我们还不知道的那些事情。但是，还有未知的未知，那些我们不知道我们不知道的事情。

未知的未知数

Rumsfeld对未知进行区分，有些知道存在但是人们找不到，但是他也承认还有一些存在是超出人们的知识和经验的，人们甚至不知道要去寻找：这就是“未知的未知”。

Rumsfeld讨论的是战争的不确定性，但也是在说软件。如果某人曾编写过一些重要软件，可能涉及过未知之未知问题——软件设计中最大的一个问题。那么大家对解决方案实现过程中所遇到的问题都有一个很好的理解，但是不可避免还是会出现一些不可预料的问题。同一个开源框架交互不是大家想的那么简单，问题可能比原来所预计的更细微，需要更加精细缜密。

不可预期的设计问题会不断出现，因为软件的容错能力很低——比物理系统低很多。例如，以大家身边的建筑物为例，构建一个大楼是一个多人数月（甚至数年）的项目。现在考虑类似时间段上的一个多人软件项目。这些项目有类似的规模，但是物理建筑往往更加宽容结构缺陷。如果一个开关不能完全掩盖墙上安装电线的洞，整个大楼不会倒塌。但是软件中的一个小问题可能会导致系统崩溃。将其比作原子，位元的容错都是不可原谅的。当然，软件易于修复：大家可以在洞上抹墙粉（修复bug）立即改造房子。

如果一个机翼脱落了，工程师首先会查看机翼连接的位置：在物理系统上，错误和功能的临近度通常很高。但是在软件中，执行一行可能导致不稳定的代码，通常会使数百行甚至几千行似乎不相关的代码出现问题。

软件预先设计（Design up front）比较困难，因为各个部分之间以无数种、甚至不可预期的方式相互作用。预测这些交互的实现目前不在能力范围之内，紧急设计包含这些不可避免的令人惊讶的复杂性，试着减少变化的破坏。

设计波谱

紧急设计不是一个二元状态。不能肯定地说某人的设计是100%敏捷的或是0敏捷的；有图1所示的这样一个波谱：

图1.设计波谱

在图1的最左边，有传统的Big Design Up Front（BDUF），具体反映在很多常见开发技术中。BDUF以其优秀的稻草人（straw-man）形式体现了象牙塔架构，创建设计工件，不作任何更改直接交给开发人员来进行实现。在nonparody格式中，该设计方法努力尝试在编码之前找出所感兴趣的一切。这是一个预测模型，设计软件的预测模型。

图1右边显示了某人在中学时期所做的各种编码：可以进行修改使之运行，然后继续改进。这在小范围内可以很好地运行（基本上，只要这个问题小到用脑子想想就可以解决），但是不能超出太多。

紧急设计通常在两个极端情况下失效，但是和左边比起来更趋向于右边。紧急设计是一个响应式的、被动的软件设计方法。

面对这么多的失败和不被看好的项目，还有这么多组织机构继续使用BDUF，真的很令人费解！并不是说某人不能成功地使用BDUF。（事实上，他曾做过很多这类项目。）但是数十年间关于这个开发技术的记录很少。Fred Brooks的重要著作Mythical Man Month探讨了以该模式构建软件存在的问题，于1975年发布（见参考资料）。

团队想使用这种风格进行开发并不奇怪，因为这更符合设计在传统工程中的工作方式。如果开发者正在设计小部件或iPods，必须进行所有的预先设计，因为开发者不能重构原子。看看原始的Intel Pentium处理器。在它发布之后，在浮点数据单元中发现了一个bug，需要每个操作系统创建者来编写特定代码解决这个问题。一旦操作完成，就不能对硬件进行更改。软件截然相反：软件项目的多数生命周期是在原始版本发布之后发生，通过增强、bug修复、以及其他“维护”活动。开发者处理位元而不是原子，位元的可塑性是无限的。

多少预先设计？

敏捷设计并不是要在项目开始阶段忽略设计。对问题的本质知道得越少，在此过程的早期所能做的就越少。他常常会问，“如何决定在一个项目开始阶段进行多少设计合适？”不同项目有不同的准则，它们在种类和复杂程度上的变化比多数非技术人员所意识到的要多很多。大致上说，需要平衡两件事：如果开发者的早期决策足够精准可以避免日后进行更改，那么要考虑预先设计。如果后期修改成本太大，就要考虑收益问题。因此，需要对早期阶段以及开发技术（可能会是后期更改代价昂贵）有一个很好的了解。敏捷设计反对这个观点，因为人们倾向于过高地估计他们在早期制定精确决策的能力，因而他们将遭受不断扩大的后果。

这里是一些项目示例，了解一下开发者应该为哪些项目做更多的预先设计：

• 有严格的稳定性需求，数年之内没有更改计划的项目。
• 高度隔离的环境（比如太空傲游，水底探险），出于安全性考虑的项目。
• 所编写的项目与之前的软件完全相同、同一组人、没有范围变化。（对该项目有一个极度精确的评估。）
• 对环境高度约束的项目，比如，嵌入式系统，确保考虑到了环境约束条件。（他仍然会尽量使行为功能性尽可能多地出现。）

不需要进行太多预先设计的项目有：

• 有高度可变性、项目需求不断变化的项目（几个月或几周），像多数商业应用程序。
• 需要响应外部因素（比如，市场条件）的项目。
• 还不能确定技术或业务细节的项目，注意这实际上包括每个项目，又回到Rumsfeld的“未知之未知”理论上了。
• 从订阅到部署都可以从中收益的项目，而不是那些人为地区分为“已完成的”项目。没有软件项目是彻底完成的，因此开发者总是需要购买一个订阅，越早认识到这一点，就表现的越像。

选择正确的时间制定决策比较困难，但很重要。所有项目都是独一无二的，给出具体建议无用。但是，这有一些通用的指导方针：

• 注意当“最简单的工作”已经工作一段时间之后，需要解决的问题变得更重要更复杂，例如，假设开发者正在使用一个数据库作为基础后台、异步活动的一个简单消息传递队列。然而现在，在性能变差的同时将两个新需求添加到各种异步活动中了。现在是重新访问“最简单事情”决策的最佳时间，因为解决方案不能匹配该准则。
• 在查看问题的整体规模时，试着隔离将趋向紧急设计技术的数据包。例如，假设开发者正在处理一个需要地理编码支持的应用程序，开发者不可能在此之前就使用一个地理编码库。应该执行一些spikes（简单直接的研究与开发项目）来确保可以理解评估目的。尽量避免在不完全理解的基础上制定架构决策（后期很难改变），重新访问应用程序其余部分和这个隔离部分之间的接口点，看看是否能在更好理解的基础上进行改进。
• 试着保留应用程序之间的交互作用点。Simple Object Access Protocol (SOAP) 这类协议的一个副作用是在刚性结构和强类型（strong types）上的持久性。灵活性的秘密是特异性少，这种认识推进了Representational State Transfer (REST)和相关技术的广泛应用。构建一个API时，试着接受最通用的合理性，这也将应用于集成。

演化架构与紧急设计系列总结

他将对这18期中的主要主题做出了总结：

代码作为设计

回到“演化架构和紧急设计：利用可重用代码，第1部分”，他引用Jack Reeves的这篇文章，他认为软件设计是由一个项目的全部源代码构成，而不仅仅是开发者通常所认为的工件（白板图（white-board diagrams）、Unified Modeling Language，等等）。他将源代码和工程的规划进行了比较，工程师的规划指出了生产团队将设计转换成原子所需的一切。开发者的规划是源代码，编辑器将其转换成位元。如果对代码进行设计，那么所用的计算机语言和架构就定义了开发者可以设计的原始资料。

功能强大的语言的影响优势抵消了对其先进功能的恐惧。尽管选择和标准化有10多年历史的语言很不错，因为有足够充足的低成本开发人员，但是必须接受这个事实，不能赶上竞争对手，因为他们有更现代的语言和工具。很多机构过分强调标准化，甚至以创新和稳键为代价。他曾见过很多被迫使用标准框架的项目，这很可笑也不利于问题发现，这会妨碍任何类型的设计问题发现，因为会被意外噪音所干扰。

这并不意味着就允许每个开发人员都选择使用自己的工具堆栈。这意味着开发者要密切关注标准化所提供的真正价值，然后考虑合理方案。例如，或许开发者想继续使用Java技术开发项目，可以使用更高级的工具进行构建、测试和其他开发任务。软件项目中代码似乎无处不在，这一切都体现在设计中，不管是有意识还是无意识的。

接受不确定性

许多方法都想要避免不确定性。如果开发者使用原子方式进行构建，不确定性很糟糕，因为一旦原子被强制形成一定形状再更改其配置代价极为昂贵。但是，如果使用位元进行构建，更改十分容易且十分必要。在软件中避免更改很困难且没有必要。

敏捷方法想要找到一种方法使得修改更为容易，使用诸如单元测试、重构、持续集成和交互开发之类技术。紧急设计体现在设计的敏捷哲学中，当出现设计决策时，问自己：

• 现在需要制定这个决策吗？
• 可以安全地推迟这一决策吗？
• 能做些什么使决策可逆？

如果开发者是在这样一个易于重构代码的环境中，临时制定一个非最佳决策并不可怕，因为可以轻松地进行修复。如果设置项目以适应变化，推迟决策不会发生故障，因为可以实时优化。接受修改需要有能力客观对待决策以及更改那些使事情糟糕的决策。

收获惯用模式

紧急设计的另一方面是能够看见代码中的有用设计元素，然后作为惯用模式进行保存，这是他在“演化架构和紧急设计：利用可重用代码，第1部分”中作为已有问题的有效解决方案定义的。这些已发现模式就像是某公司皇冠上的珠宝，因为它们是实现公司运行方式的设计元素。令人担忧的是，开发者所编写的少量代码囊括了惟一值：余下的大部分只是拖放到数据库、构建HTML，等等。惯用模式比在Joint Application Design(JAD)或象牙塔设计中编造的模式要更有价值，因为它们已经达到了实用的关键条件之一：它们已经被用来解决了一个实际问题。

开发者可以通过各种方法收获惯用模式。可以创建一个API，这只是很简单并没有什么特别的—看起来和所使用的其他API没什么两样。也可以捕获一些使用元程序和属性的惯用模式（见“演化架构和紧急设计：利用可重用代码，第2部分”）。在“演化架构和紧急设计：使用DSL”、“演化架构和紧急设计：连贯接口”、“演化架构和紧急设计：使用Groovy构建DSL”和“演化架构和紧急设计：使用JRuby构建DSL”中，他也讨论了使用特定域语言捕获惯用模式。

总是想要识别有用设计元素，避免制定人工难以执行的决策。例如，当这些元素被添加到代码基中，在没有使用它们时向应用程序（比如，可扩展层或面向服务架构的服务）中添加架构元素使代码更为复杂。务必确保在正确的时间添加复杂性，因为在使用它之前，它都是偶发复杂性。