规范代码检查的一点心得

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

阅读更多
想对作者说点什么? 我来说一句

代码检查规范

2015年12月02日 43KB 下载

ARM的一点心得 ARM的一点心得

2011年04月09日 120KB 下载

权限管理设计的一点心得

2011年11月10日 137B 下载

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭