规范代码检查的一点心得

   刚进入公司时，代码检查只是一个很简单的形式，由开发经理指定一个人负责检
查开发人员的代码，检查的力度很粗，主要只涉及到业务方面是否符合要求。而且很
多时候只走形式。
   随着项目的逐步扩大，需求的不断增长，产品的开发过程也需要逐渐的步入规范，
引入了CMMI，代码检查也逐渐规范起来。由于以前的检查过程缺乏积累，除了开发语言
本身的一些规范，符合公司整体框架的一些开发规范并没有制定完整。而且以前的那种
通过肉眼的方式去看每一行代码的方式也存在很多问题。需要在开发阶段就让开发人员
形成统一的编码风格，不然编码风格成为个人的标签。通过引入一些开源的插件，例如
checkstyle,findbug,klockwork等，让开发人员在提交代码前先通过工具检查一遍。这样
很多存在的问题在代码提交前就已经修复了。而其它一些通过工具检查不到的问题，例如
代码的实现是不是符合整个公司架构的要求，是不是在现有的框架体系下实现,这些就需要
通过制定检查标准，然后由资深的开发人员来检查。
  主要通过以下过程实现：
     1. 项目管理组提供需要检查的需求清单及对应的开发人员
     2. 开发组内部进行对应的组内检查，主要是涉及到业务及编码质量。
     3. 开发组内部检查完成后，由开发组和开发组之间进行交叉的代码质量检查。
     4. 最后再由架构组对一段周期内的代码质量进行抽查，完善代码质量检查的规范。
     5. 积累到一定程度再通过部门统一的培训来规范整个代码质量。
  经过一段时间的积累，代码质量有了较明显的改善，同时也存在很多问题，主要有以下
几个方面：
     1. 规范还不够细，很多问题检查人员在检查代码的时候完全只按照规范来检查。
     2. 不良的代码会带来性能隐患，虽然现在有对应的插件，可以让开发人员在编码时
         监控一些性能问题，开发人员普遍比较抵触。目前只有通过对整个产品进行性能测试，可以得到
         一些数据，再对问题代码进行修复。