作者：Mark Figley 译者：罗小平
多数大型开发组织都有一套自己的编码和实践规范。但是对这些团队而言，光是将这些规范文档化，并保证实时更新，就是一个巨大的挑战。此外，在工作中长期、忠实地执行这些规范和标准，难度就更大。我们团队在这些方面做了积极探索，在整个构建过程（build process）中实现了代码规范的自动化监管。
积极主动、未雨绸缪是工作取得好成果的重要保证。即使在很成熟的组织中，建立了代码复审流程，审查结果也能直接反馈给责任人，但如果复审是在事后进行，仍然存在很大风险。因为这个时候，错误已成现实，很可能已经进入测试和产品环境，从而造成实质性损失；而这时候再回头修改，开发人员也有抵触情绪，缺乏积极性。从我们的经验看，构建过程必须自始至终处于受控之中，在所有的软件开发过程中，对应的代码审查工作都应该自动完成。只有这样，错误代码才能在第一时间消除，从而避免到最后阶段采取回溯式审查方法所产生的成本高昂和开发人员抵触等问题。不带任何感情色彩的自动化系统可实时向开发人员反馈Web页形式的报告，帮助他们解决可能存在的问题；而且通过反复提醒，也可以让开发人员被动熟悉新的编程规范。
中心化的构建过程管理
为保证我们的上述策略真正落到实处，必须做好两项工作：
- 构建过程必须是基于服务端的、中心化管理的。我们曾在Ant脚本基础上自行开发了一个构建管理系统（Build Management System，BMS），因为那时候像AntHill、Maven等产品还没有发展成熟。如果是现在，我肯定会选择第三方的BMS，而不是自己从头做起。自己开发，方便实现一些特殊的定制化需求，但现在很多第三方BMS都有功能集成能力。
- 必须树立这样的观念：深度使用BMS，是团队大幅提高代码质量的唯一途径。我这不是搞教条，在这个问题上，其实别无选择。如果开发人员可以绕过监管系统，直接将Java类文件FTP传送到服务器，那么我们正在这里讨论的解决方案的有效性就大打折扣了。我们应该控制对服务器上相关目录的访问，只将写入权限授予负责运行JVM过程（即我们的构建系统的宿主）的帐户，这样，开发人员必须通过BMS，才能将代码传递到生产和测试环境。这样一个过程，有连个显而易见的好处：（1）保证在测试和生产环境中的源代码控制；（2）确保在这些环境的所有代码都通过了自动化的软件审查。
我们使用的代码自动审查工具是Parasoft的Jtest，当然还有很多工具可以完成类似功能。总的来说，Jtest是一个有效的管理工具，不过也存在一些问题。比如在使用之前，必须搭建一个基础运行环境；另外，它并不是一个黑盒式的解决方案，这也是背离我们希望的。Jtest包括静态分析和动态分析。其动态分析功能比较强大，不过这已超出了本文的讨论范围。
4年前，我们团队因为数据库连接未关闭问题焦头烂额。资源未能在try/catch/finally块中得到正确清理（大家是否感觉很熟悉？），因此引入了Jtest。在当时，Rod Johnson大仙（译者注：Spring框架和《Expert _disibledevent=> 标签： 代码规范
最新评论