演化架构与紧急设计: 积累惯用模式

核心提示：在本系列第一期 “研究架构和设计” 中，我曾断言每个较大的项目都包括超出所有人意料的设计元素，演化架构与紧急设计: 积累惯用模式，详细考虑一个问题时，常常会发现有些本以为困难的事情实际上却更容易，因为对于如此复杂的耦合和交互网络，实在是难以理解，有些本以为容易的事情实际上却更困难，随后的几期则演

在本系列第一期 “研究架构和设计” 中，我曾断言每个较大的项目都包括超出所有人意料的设计元素。详细考虑一个问题时，常常会发现有些本以为困难的事情实际上却更容易，有些本以为容易的事情实际上却更困难。随后的几期则演示了发现隐藏的有趣的设计元素的一些方法。在本文中，我将那些思想相结合，并提供一个扩展后的案例研究，在该案例研究中，使用一些工具和方法来发现代码库中被忽视但是同样重要的部分。

在 “组合方法和 SLAP” 中，我介绍了惯用模式（idiomatic patterns） 的概念。与四人组撰写的 Design Patterns一书普及的常规设计模式（Design Patterns）相比，惯用模式并不适用于所有项目。但是，它们是代码中普遍存在的、有代表性的常见设计惯例。惯用模式的范围很广，从纯技术模式（例如项目处理事务的方式），到问题域模式（例如 “处理订单前总是检查客户的信用”），都可以是惯用模式。发现这些模式是紧急设计的关键。

Big Design Up Front 设计方法学的支持者在开始编写代码前，要花费大量的时间确定当前应用程序的所有必需的设计元素。编制的文档中的大多数内容对于解决方案的总体设计仍是重要的。但是，在实现软件的过程中，会不断遇见意外。实现的每个设计元素与其他设计元素相互联系，形成极端复杂的依赖和关系网络。代码中有些方面本以为平常不过，但是一旦要实现系统中其他所有必需的部分时，复杂度又随之放大。由于不能理解代码中不同设计元素之间复杂的相互作用，导致在估算完成解决方案所需的努力时困难重重。在软件方面，估算仍是一种玄妙的 “黑色艺术”，因为对于如此复杂的耦合和交互网络，实在是难以理解，因而也难以分析。