简介： 本期将之前的 演化架构与紧急设计 文章中的紧急设计概念与一个案例研究相结合，展示如何 发现、积累和利用代码中意料之外的设计元素。一旦理解了如何识别设计元素，便可以使用该知识改进代 码的设计。紧急设计使您可以发现代码中意料之外但是已成为代码库重要部分的那些方面。
在本系列第一期 “研究架构和设计” 中，我曾断言每个较大的项目都包括超出所有人意料的设计元 素。详细考虑一个问题时，常常会发现有些本以为困难的事情实际上却更容易，有些本以为容易的事情实 际上却更困难。随后的几期则演示了发现隐藏的有趣的设计元素的一些方法。在本文中，我将那些思想相 结合，并提供一个扩展后的案例研究，在该案例研究中，使用一些工具和方法来发现代码库中被忽视但是 同样重要的部分。
在 “组合方法和 SLAP” 中，我介绍了惯用模式（idiomatic patterns） 的概念。与四人组撰写的 Design Patterns一书普及的常规设计模式（Design Patterns）相比，惯用模式并不适用于所有项目。但 是，它们是代码中普遍存在的、有代表性的常见设计惯例。惯用模式的范围很广，从纯技术模式（例如项 目处理事务的方式），到问题域模式（例如 “处理订单前总是检查客户的信用”），都可以是惯用模式 。发现这些模式是紧急设计的关键。
Big Design Up Front 设计方法学的支持者在开始编写代码前，要花费大量的时间确定当前应用程序 的所有必需的设计元素。编制的文档中的大多数内容对于解决方案的总体设计仍是重要的。但是，在实现 软件的过程中，会不断遇见意外。实现的每个设计元素与其他设计元素相互联系，形成极端复杂的依赖和 关系网络。代码中有些方面本以为平常不过，但是一旦要实现系统中其他所有必需的部分时，复杂度又随 之放大。由于不能理解代码中不同设计元素之间复杂的相互作用，导致在估算完成解决方案所需的努力时 困难重重。在软件方面，估算仍是一种玄妙的 “黑色艺术”，因为对于如此复杂的耦合和交互网络，实 在是难以理解，因而也难以分析。
依赖于紧急设计的敏捷方法学则尝试一种不同的方法。敏捷架构和设计在编写代码前也不会避开设计 ，但是它们的实际工作者已经知道，只有等到实现了重要的部分后，才能彻底地理解整个问题。紧急设计 中的开发技巧使您可以推迟做决定，直到掌握了更多的上下文。精益软件运动有一个很好的概念叫做 最 后可靠时刻（last responsible moment）：不是将决定推迟到最后时刻，而是最后可靠时刻。越是往后 推迟设计决定，就能掌握越多的信息，从而可以做出更精妙、更符合实际的决定。
积累惯用模式
紧急设计要求在已有代码中发现设计元素。可以将那些元素看作有复用潜力的有效的抽象。积累那些 惯用模式的一种技巧是使用指标组合。为了演示这种技巧，我将（像之前几期那样）使用 Apache Struts 代码库。之所以使用 Struts，并不是因为我认为它存在缺陷（实际上恰恰相反），而是因为它比较出名 ，并且是开源的。我认为每个代码库都包括惯用模式，所以可以使用任何项目。
使用指标
在 “通过指标进行紧急设计” 中，我讨论了使用指标来发现不熟悉的代码库中有趣的部分，作为重 构的目标，以改进设计。我使用了两个指标：圈复杂度（cyclomatic complexity） 和 传入耦合 （afferent coupling）。圈复杂度是衡量一个方法相对于另一个方法的相对复杂度的指标。因此，该指 标只有与其他圈复杂度指标相比较才有用。但是，可以说，具有较低圈复杂度的方法通常更简单。而传入 耦合则表示其他类通过字段或参数引用当前类的次数。我使用 CJKM 指标工具收集 Struts 代码库上的这 些数字。
对 Struts 2 代码库计算这两个指标可得到图 1 所示的表，其中只显示关心的两个指标：
图 1. ckjm 指标结果表
图 2 显示相同的表，按 Weight Methods per Class（WMC）排序：
图 2. ckjm 指标，按 WMC 排序
单看这个结果，可以认为 DoubleListUIBean 类是 Struts 代码库中最复杂的类。这意味着可以将这 个类作为重构的候选目标，试着减少一些复杂性，并看看是否能发现可抽象的、重复的模式。然而，WMC 数字并不能告诉您是否值得花时间重构这个类，以改进设计。注意这个类的 Ca（传入耦合）指标，它的 值为 3。这意味着只有 3 个其他的类使用这个类。花费大量的时间改进这个类的设计也许并不值得。
图 3 显示相同的 CKJM 结果，这一次按 Ca 排序：
图 3. ckjm 结果，按 Ca（传入耦合）排序
这个组合的视图表明，Struts 中最常用的类是 Component（这并不奇怪，因为 Struts 是一个 Web 框架）。虽然 Component 不如 DoubleListUIBean 复杂，但是有 177 个其他的类使用它，因此很适合作 为改进设计的目标。使 Component 的设计变得更好，可以在很多其他的类上取得良好的连锁反应。
通过 图 3 所示的视图，可以逐个查看复杂度和引用次数。要发现有设计挑战的类，可以看看两个数 字都比较高的组合（即被很多其他类使用的复杂的类）。我首先选择的用于研究的类是 UIBean 类，它的 圈复杂度是 53，传入耦合是 22。这是一个被很多其他类使用的复杂的类，所以我将对它作进一步的研究 。
ckjm 报告的圈复杂度数字表示这个类中所有方法的复杂度之和。我想确定是什么使这个类如此复杂， 所以需要各个方法的复杂度数字。对这个类运行开源圈复杂度工具 JavaNCSS，可得到图 4 所示的结果：
图 4. UIBean 类中各个方法的复杂度数字
到目前为止，最复杂的方法是 evaluateParams()，其复杂度为 43（也是代码行数最多的）。该方法 显然是用于处理常见的作为请求的一部分传递给 Struts 控制器的额外参数，将参数类型发送到实际的 Struts 类和组件。该代码中存在很多结构性重复，如清单 1 所示：
清单 1. evaluateParams() 方法的部分内容，其中有结构性重复
if (label != null) { addParameter("label", findString(label));}if (labelPosition != null) { addParameter("labelposition", findString(labelPosition));}if (requiredposition != null) { addParameter("requiredposition", findString(requiredposition));}if (required != null) { addParameter("required", findValue(required, Boolean.class));}if (disabled != null) { addParameter("disabled", findValue(disabled, Boolean.class));}if (tabindex != null) { addParameter("tabindex", findString(tabindex));}if (onclick != null) { addParameter("onclick", findString(onclick));}// much more code elided for space considerations
该代码可作为改进的候选目标（见下一小节 改进代码，第 1 部分），但是我想再多看一下，该代码 存在的原因 是什么，为什么它包含如此多的复杂性。
放眼其他圈复杂度和传入耦合值都比较高的 组合，我发现了 WebTable，它的那两个值分别为 33 和 12。对它运行 JavaNCSS，可以肯定我的怀疑： 它的第二复杂的方法是 evaluateExtraParams()。在这里我看到一个模式！看到这个重复的复杂元素出现 在很多不同的类中，我怀疑有很多偶然的与参数有关的复杂性，所以我做一个实验。通过使用一点 UNIX® 命令行魔术，我观察 Struts 中有多少类中包含名为 evaluateParams() 或 evaluateExtraParams() 的方法：
find . -name ”*.java” | xargs grep -l ”void evaluate.*Params” > pbcopy
这个命令查找当前目录以下的所有 Java™ 源文件，对于每个找到的文件，它在文件中搜索以 evaluate 开头，以 Params 结尾的方法定义。最后的重定向（>）将结果文件粘贴到剪贴板上（至少 在 Mac 上是如此）。当我粘贴结果时，看到了令我惊讶的事：
AbstractRemoteCallUIBean.javaAnchor.javaAutocompleter.javaCheckbox.javaComboBox.javaDateTimePicker.javaDiv.javaDoubleListUIBean.javaDoubleSelect.java File.javaForm.javaFormButton.javaHead.javaInputTransferSelect.javaLabel.javaListUIBean.javaOptionTransferSelect.javaPassword.javaReset.javaSelect.javaSubmit.javaTabbedPanel.javatable/WebTable.javaTextArea.javaTextField.javaToken.javaTree.javaUIBean.javaUpDownSelect.java
所有这些类中都包含以上两个方法中的一个或两个！我发现了一个惯用模式。显然，Struts 中的很多 类需要覆盖和定制处理参数的行为，所有这些类各自负责定制。现在的问题是：如何使之变得更好？
改进代码，第 1 部分
在 UIBean 的 evaluateParams() 方法中，可以看到很多不同的结构性重复，我的一个同事称之为 “ 相同的空格，不同的值”。换句话说，结构相同，但是代入不同的类或变量名。这代表着一种代码味道， 因为应用程序中前后出现实际上可以复制-粘贴的代码，这些代码差别很小。
修复结构性重复的一种常见的技巧是使用元编程将重复的结构封装到一个地方。清单 2 显示一个新的 方法，以及 evaluateParams() 方法中经过改进的前一部分，这里使用反射提供所需的不同的值：
清单 2. 通过元编程消除结构性重复
protected void handleDefaultParameters(final String paramName) { try { Field f = UIBean.class.getField(paramName); if (f.get(this) != null) addParameter(paramName, findString(paramName)); } catch (Exception e) { throw new RuntimeException(e.getMessage()); }}public void evaluateParams() { addParameter("templateDir", getTemplateDir()); addParameter("theme", getTheme()); String[] defaultParameters = new String[] {"label", "labelPosition", "requiredPosition", "tabindex", "onclick", "ondoubleclick", "onmousedown", "onmouseup", "onmouseover", "onmousemove", "onmouseout", "onfocus", "onblur", "onkeypress", "onkeydown", "onkeyup", "onselect", "onchange", "Accesskey", "cssClass", "cssStyle", "title"}; for (String s : defaultParameters) handleDefaultParameters(s);
清单 2 中的 handleDefaultParameters() 方法将原有的重复结构封装到一条 if 语句中。它接收一 个指定 Struts 参数名的参数，并通过编程方式使用反射获取适当的字段。然后，它对原始代码进行 null 检查，最终调用 Struts addParameter() 方法。
有了 handleDefaultParameters 方法后，就可以大大减少原有代码的行数（以及圈复杂度）。我为所 有适用的 Struts 参数名创建一个 String 数组，然后迭代那个数组，在每次迭代中调用 handleDefaultParameters() 方法。
将所有参数检查合并到一个简洁的地方，这不仅仅是消减了方法的大小。原始的方法的圈复杂度是 43 。之前每个 if 块占用 3 行代码（并贡献了 1 个点的圈复杂度）。我用一个含 9 行代码的方法（圈复 杂度为 4）消除了重复，减少了 66 行代码（22 个参数，每个参数需要 3 行代码）。这意味着这个简单 的改变使这个类因这个新方法而减少了 57 行代码，并使圈复杂度减少 18 个点（1 个 CC 点 x 22 个参 数 – 4 个 CC 点）。因为那样小的一个改变，我大大改善了应用程序的可读性、指标、大小和可维护性 。如果将来需要改变调用 Struts addParameter() 方法的方式，只需在一个地方做出更改。
这是一个短期的修复，这是为了演示简单的改变如何对代码的简洁度产生深远的影响。但是，如果是 我的代码库，我会采用一个长期的解决方案。
改进代码，第 2 部分
如果是我的项目，我会将整个参数处理机制抽象到它自己的一组类中，构建 Struts 中的一个子框架 。处理参数的代码的复杂性，以及它的广泛性和数量，意味着应该将它当做 Struts 中的一等公民。这不 是一篇文章所能详述的，但是可以看到，Struts 中有大量的复杂性是围绕这个问题产生的。
紧急设计和惯用模式
您认为 Struts 的原设计者曾经想到过处理参数所需的代码有多少吗？软件就是这样。有时候可以根 据问题域的理论知识预测复杂性，但是在编写代码时，又会产生新的约束和机会，这些实际上是无法预测 的。实际上，资深的开发人员在预测那样的 “硬骨头” 方面并不会做得更好。他们只是更相信，那个神 秘的硬骨头最终会出现。
紧急设计的魅力之一是有这样的认识：我们不能可靠地预测什么会变成硬骨头，但是我们应该对此保 持警惕。如果带着发现抽象和模式的期望去看代码库，就更容易有所发现。
最后我以一个案例研究作为结束，该案例研究基于一个 ThoughtWorks 项目，这是我间歇性地从事的 一个项目。在这个大型 Ruby on Rails 项目的早期，技术主管意识到，在一些单独的情况下需要异步行 为（例如，上传大量的图像时，用户需要能够暂时离开页面，之后再回到页面）。如果我们存着 Big Design Up Front 的思维，那么就会立即寻求一个消息队列。但是，在项目一开始，我们还不能完全知道 有哪些地方需要异步，一般的态度是寻求最大的消息队列，以确保能处理将来的新需求。但是我们的技术 主管非常明智地没有那样做。他决定我们已有的足以适合当前状况。
时间往后推移 2 年。到现在，应用程序有 3 个不同的异步行为，当前解决方案开始成为瓶颈。现在 ，是时候使用一个消息队列了。但是，由于技术主管推迟了如此长的时间才做决定，我们现在十分清楚这 个应用程序在消息传递方面的需求，因此可以采用最简单的工具来完成该任务。由于耐心等到最后可靠时 刻才做决定，我们避免了因一个并不那么需要的工具带来的意外复杂性而做的数年的工作 — 从而获得更 简洁的代码，使新特性具有更高的速度，也减少了相关的烦人的工作。
让代码引领设计，这意味着对需求有更好的理解。设计决定推迟得越久，最终做出具有长期意义的决 定时，便拥有更清晰的路线。
结束语
本系列的很多文章都是在向您灌输一些上下文，使您明了真正的优点。本期几乎将本系列之前的每篇 文章都贯穿起来，利用那些文章中提到的技巧、工具和态度。紧急设计要求具有看到和积累惯用模式和抽 象、工具和技巧的能力，以便在它们出现时能够利用它们。Design up front 有助于发现重要的部分（敏 捷项目要做足够多的预先设计，以决定那些事情），但是开始编写代码后，仍应该保持警惕，您将发现令 人惊讶的重要的设计元素。每个代码库都有惯用模式。您必须学会发现它们并采取行动。
在最近几期，我几乎都是在谈论设计和相关的问题。下一次，我将重新深入研究演化架构，并展示将 敏捷开发技巧与架构概念相结合时出现的一些常见问题和解决方案。
只是微笑地固执自己的坚持，
