英文原文：Implementing Automated Governance for Coding Standards

　　作者：Mark Figley 译者：罗小平 

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