代码规范的自动化监管

多数大型开发组织都有一套自己的编码和实践规范。但是对这些团队而言，光是将这些规范文档化，并保证实时更新，就是一个巨大的挑战。此外，在工作中长期、忠实地执行这些规范和标准，难度就更大。我们团队在这些方面做了积极探索，在整个构建过程（build process）中实现了代码规范的自动化监管。

积极主动、未雨绸缪是工作取得好成果的重要保证。即使在很成熟的组织中，建立了代码复审流程，审查结果也能直接反馈给责任人，但如果复审是在事后进行，仍然存在很大风险。因为这个时候，错误已成现实，很可能已经进入测试和产品环境，从而造成实质性损失；而这时候再回头修改，开发人员也有抵触情绪，缺乏积极性。从我们的经验看，构建过程必须自始至终处于受控之中，在所有的软件开发过程中，对应的代码审查工作都应该自动完成。只有这样，错误代码才能在第一时间消除，从而避免到最后阶段采取回溯式审查方法所产生的成本高昂和开发人员抵触等问题。不带任何感情色彩的自动化系统可实时向开发人员反馈 Web 页形式的报告，帮助他们解决可能存在的问题；而且通过反复提醒，也可以让开发人员被动熟悉新的编程规范。

中心化的构建过程管理

为保证我们的上述策略真正落到实处，必须做好两项工作：

1. 构建过程必须是基于服务端的、中心化管理的。我们曾在 Ant 脚本基础上自行开发了一个构建管理系统（Build Management System，BMS），因为那时候像 AntHill、Maven 等产品还没有发展成熟。如果是现在，我肯定会选择第三方的 BMS，而不是自己从头做起。自己开发，方便实现一些特殊的定制化需求，但现在很多第三方 BMS 都有功能集成能力。
2. 必须树立这样的观念：深度使用 BMS，是团队大幅提高代码质量的唯一途径。我这不是搞教条，在这个问题上，其实别无选择。如果开发人员可以绕过监管系统，直接将 Java 类文件 FTP 传送到服务器，那么我们正在这里讨论的解决方案的有效性就大打折扣了。我们应该控制对服务器上相关目录的访问，只将写入权限授予负责运行 JVM 过程（即我们的构建系统的宿主）的帐户，这样，开发人员必须通过 BMS，才能将代码传递到生产和测试环境。这样一个过程，有连个显而易见的好处：（1）保证在测试和生产环境中的源代码控制；（2）确保在这些环境的所有代码都通过了自动化的软件审查。

工具化的软件自动审查

我们使用的代码自动审查工具是 Parasoft 的 Jtest，当然还有很多工具可以完成类似功能。总的来说，Jtest 是一个有效的管理工具，不过也存在一些问题。比如在使用之前，必须搭建一个基础运行环境；另外，它并不是一个黑盒式的解决方案，这也是背离我们希望的。Jtest 包括静态分析和动态分析。其动态分析功能比较强大，不过这已超出了本文的讨论范围。

4 年前，我们团队因为数据库连接未关闭问题焦头烂额。资源未能在 try/catch/finally 块中得到正确清理（大家是否感觉很熟悉？），因此引入了 Jtest。在当时，Rod Johnson 大仙（译者注：Spring 框架和《Expert One-on-One J2EE Development without EJB》的作者）还没有下凡，没有给我们带来 JdbcTemplate，因此很多公司都还在与此问题奋战。而解决这类问题，恰是 Jtest 的强项。其运作原理是：分析 Java 类的结构和内容，检查它们与既定规则的匹配程度。比如规则可能是这样的：若在某个方法体中创建或从连接池中取得了数据库连接，那么必须保证存在一个 try/catch/finally 块，且在 finally 块中关闭了连接，或将连接放回了连接池。4 年前，我们就利用 Jtest 设立了这样一个规则，将其严重程度定位一级，并在构建系统中设置：当 Jtest 错误出现时，构建过程自动暂停当前工作。这个系统工作得很好，数据库连接问题再也没有出现过。

现在，我们有了 Rod 和他的 JdbcTemplate，但对于那些还没有转换到 Spring 的遗留 Java 应用来说，上述规则仍可发挥作用。此外，Jtest 还可以强制执行很多其他结构性标准检查工作。比如，我们团队实施日志标准后，就引入了另一项规则，以杜绝代码中再出现 System.out.println 语句的可能。上述这些功能，不过是 Jtest 的冰山一角。在 Jtest 魔盒中，规则多达数百项，你还可以根据自己需要创建新的规则。

但现在的一个问题是，Parasoft 对服务端 Jtest 的支持不够理想。该公司的主要产品是一个 Eclipse 插件，此插件负责在 IDE 内部对代码执行静态和动态分析。这不是我所想要的，我需要的是一个基于服务端的 Jtest 产品，服务端环境可以集成并调用它的功能。Parasoft 认为我们讨论的这种最终式的组织控制和监管，可以通过购买 IDE 插件（安装到所有开发者的 IDE），外加一个中心化的 Parasoft 报告服务器实现。但我们发现事实并非如此。Parasoft 不能保证所有开发人员在将代码签入 CVS 前都会自觉执行静态检查。我们没有办法控制这类插件，没有 Jtest 插件报告“停！在有一级错误前你不能签入”这样的控制点。因此，这种审查不宜放在客户端执行，而必须有一个中心化的控制点，也就是一个中心化的 BMS。我们需要的是服务端版本的 Jtest，由我们自己完成对它的集成（虽然有点麻烦）。

当然，我得再次强调，Jtest 不是唯一选择。Adrian Colyer 等人谈到过利用 AspectJ 完成代码强制检查。在中心化的监管服务器上，这样的功能很容易实现。我不能确定 Jtest 是否能满足你的全部要求，不过它有免费的优势。其他同类型产品以及 eclipse 插件一般能完成 Jtest 的不同部分功能。如果你想图省事，可以选择 eclipse 中的标准插件 JDT，它支持从格式和句法两个方面对源代码做标准检查。

实施监管的最佳实践

软件自动化监管策略远比你选择什么样的技术构建解决方案更为重要。如下是我们多年来从实践中总结的经验教训：

• 监管结构要简单。我们只有 1、2、3 共三种等级规则。违反第一等级规则时，工作将暂停，项目将无法进入测试和生产阶段，直道问题解决。第二等级主要是指一个预备阶段。它告诉开发人员，在下一个 6-12 月内，此等级的问题会上升到第一等级，因此在此之前应该将这些问题解决掉。第三等级问题不具实质危害。这个等级只是建议解决某些问题，但在上升到其他等级前，这些问题不会对工作造成影响。
• 实施过程尽可能保守些。我在上面提到过，Jtest 包括数百条规则，但在应用初期，我们只实施了两个第一等级规则。原因很简单：循序渐进，免得一下子出现太多问题，让项目经理手忙脚乱、无所适从。
• 实施前做好压力分析。公布新的第一等级规则前，你应该对问题出现的频率、修改代码所造成的时间和财务成本作到心中有数。这一点并不困难——你只需用新规则对现在项目做一次静态分析，然后考察分析报告。由此可避免第一等级规则实施后，让整个组织难以为继，最后又将其降级为第二等级的情况出现。如果分析结果显示压力很高，那么可首先确定为第二等级，到以后合适时期再提升等级。实施严格的第一等级规则之前，应该反复多次考察，必须确保管理者理解它带来的冲击并支持这样的决定；而一旦实施，就应该坚决执行。
• 充分沟通。和你的团队就新规则及其价值、实施的原因充分交流沟通。在绝大多数情况下，他们一般都能支持你，但你也不应该让他们无征兆“惊喜”。

尽管我们在实施过程中，还遇到了很多细节问题，但这样一个主动的、自动化的软件审查过程给我们的组织带来了巨大利益。我们的软件质量得到了提升，而且更重要的是，依靠这样一个可信赖的系统，无需投入大量精力维护。人工维护过程的工作量非常浩繁。通过合理设计你的支持结构，的确可以在投入成本更低的前提下，给整个组织带来更高的安全性。

作者简介

Mark Figley：拥有 8 亿美元资产的美联保险公司（AIG United Guaranty）的架构组负责人。

查看英文原文： Implementing Automated Governance for Coding Standards - - - - - -

译者简介：罗小平，上海某大型公司互联网中心技术总监， CSDN 大版主，网络 ID 为 lxpbuaa(桂枝香在故国晚秋)，曾著有《Delphi 精要》一书。个人博客为 http://blog.csdn.net/lxpbuaa ，现在 CSDN 主持翻译国外专家 Herb Sutter 的中文博客。他的 Email 和 MSN 为 lxpbuaa AT 263.net 。