代码走查优秀实践集合

公司内部人员总结的，感觉很有成效，分享一下：

代码走查优秀实践集合

轰轰烈烈的代码质量竞赛结束了，各产品部陆陆续续开展了代码走查交流会，会上各位组长或代码走查负责人分享了优秀的实践，也提出了各式各样的问题，现把遇到的典型问题与优秀实践收集整理，与大家分享，感谢物资系统产品部与移动互联网产品部质量管理人员与开发组长、代码走查负责人以及相关同事。

1. 一、  座位上还是会议室走查代码、以及如何组织代码走查小组？

这个公司并没有强制要求，在会议室或座位上都可以，看实际情况吧，如果是人多集中走查安排在会议室好些；特别是新员工较多的情况下，非常适合集中走查：一般新员工的问题会比较多，走查的人多，发现的问题就越充分，新员工多看别人的代码，也有利进步。如果团队成熟度比较高，成员都比较有经验，两两走查效果较好，在座位搞定就OK。

组织代码走查小组方面，上面提到的集中走查与二人组合都可以，还有其他的组合方式，如：让高手与低手组合，容易发现有价值的问题，低手也会学到很多东西，但这种组合不可长期开展，因为这样组合对高手价值不大（一般情况下，不是互利的合作难于长久，不是吗？）。最要避免的组合是低手与低手的组合，除了彼此感觉不错外，难于发现有价值的问题，低手也难有所成长。

行业敏捷的常见做法：每日临下班前（如在17：30-18：00），埋头写了一天的程序员累了，这时换换脑子，两两结对，在座位上互相走查一下代码是个不错的做法。

公司的优秀实践（来自技术研究中心）：采用Jupiter工具，在会前主持人把待走查的代码路径上发送给每一位走查人，走查人在各自的座位上走查代码，用Jupiter问题记录，走查一段时间后，集中到会议室，确认每个人发现的缺陷是否是缺陷。注意：在会上确认是否是缺陷，不是在会上现场发现问题。这种做法能保证参加走查的人员都能够认真走查代码（要不然提交不了走查的缺陷）；避免了集中在会议室走查时，只有一、两个人看代码提问题，另有一些人则“身在曹营心在汉”。

1. 二、  代码走查应关注哪些问题？

一提起代码走查，有人就皱起眉头：我又不懂别人代码的业务，怎么走查别人的代码呢？！我们一起思考一下：走查的目的是发现哪些问题呢？统观软件开发整个生命周期，发现业务问题有很好的实践：迭代评审时对产品的评审、系统测试，甚至黑盒检查都能很好地发现业务问题，代码走查不去发现业务问题也无伤大雅。那么期望代码走查发现哪些问题是比较合适呢？事实证明代码走查去发现技术逻辑、性能隐患、安全隐患比较有效。如果代码走查能发现一些这一类的问题，已经善莫大焉，回想一下系统更新上线后出现的五花八门的问题，如果代码走查能够发现其中的一部分，我们是不是少些人加班加点去追查问题？能够更坦然地面对客户与用户？

1. 三、  可以针对主题开展走查吗？可以设置哪些走查的主题？

有些开发组长或代码走查负责人开展代码走查一段时间就有点茫然了，每次走查都是随机抽的代码，也不知能否走查出有价值的问题，有点没底的感觉；能否有针对性的开展代码走查呢？答案是肯定的。技术研究中心为了平台与组件的性能，曾经开展过SQL的专项走查取得不错的效果。代码质量委员会也曾把重大质量问题作为主题开展过代码走查。有些开发组长认为架构很重要，把走查架构方面的问题作为主题当然也是不错的选择。

1. 遇到重大的需要重构的问题怎办？（通常这些问题，修改起来很费时间啊？！）

一位组长表示以前代码走查发现过诸如此类的问题，结果因为没有时间改，最后不了了之，有点郁闷。遇到这种情况，不要气馁，需要抱点同理心，毕竟一个项目面临着客户进度与成本的压力，改写架构这种大手术会对项目造成很大的影响。这种问题建议根据项目的实际情况安排到计划中去，或者报到产品部，统一安排时间与人手修改（有时需要协调组外（如技术管理组）的高手一起参与），代码走查不只是开发组的事情，PDT经理、部门经理在不同层面均应与以关注。

1. 五、  代码走查时发现的历史问题怎么处理？

有些处于维护期的项目，开发组代码走查时，发现不是当前修改者引入的问题，就没有去修改。现在需要改进一下做法，既然走查的初衷是为了保证系统的质量，不用问缺陷是谁引入的，凡对质量有影响的，均需要修改，切莫让代码最后落得：作者不知何处去，BUG依旧笑春风。

1. 六、  可以编制一个代码走查模块的计划吗？

有开发组长想到：有些代码模块相对重要一些，有些一般，能否事先选一些重要的模块开展走查？想法不错，好的想法离实现还有十万八千里，关键是：去实现呀！

1. 七、  代码走查的心态？

有些开发组长提到组员参加代码走查，觉得把自己写的代码投影出来让大家发现问题有点不情愿，人性的确如此，但想想那些在刊物上发表文章的名家的稿件不也一样需要编辑部人员的审核？走查一下代码又有何妨？况且代码走查实为同行评审。人性也有一个弱点：自己的问题自己不容易发现，正因为如此才需要别人帮自己评审。大家抱着这样的心态是比较合适的：同事是帮我发现问题的，走查后提交的作品才代表自己的水平。越是高手越谦虚，认为自己是人不是神。有人说自己的问题，自己更容易成长，哪天没有人说自己的问题了，麻烦就真的来了。

1. 八、  代码走查时请高手讲解他/她写的代码怎样？

有些开发组长提到代码走查时请高手讲解他/她写的代码，主意不错，建议与其他的做法穿插开展。

1. 九、  代码走查时用插件检查规范

有些开发组采用插件来检查规范类的问题，并且在加入SVN库之前强制检查，为这些组点个赞，希望能够坚持。

十、  我们组就我一个用这项技术，怎么走查呢？

有些开发人员犯愁了，一项技术在开发组里只有一个人在用，怎么走查代码呢？类似的情况业界也有，一般需要跨组来开展，如果同一个产品不同开发组有用相同的技术，ＰＤＴ经理作为交付负责人来做协调走查的工作，如果产品开发团队内部也没有，那么产品部内部有没有用相同技术的呢？业界有做得好的公司，部门墙相当薄，别说公司内部，跨公司组织个代码走查也是经常的事情。

十一、         典型缺陷总结与学习

    有些开发组长打算把代码走查发现的问题总结出来，组织学习，提高产品质量的同时，提高成员开发水平，让我们期待好的结果。