有效开展代码走查工作的实践过程分析

周玫

摘  要：本文主要总结在前一段代码走查实践工作中的一些收获，同时对工作开展过程中存在的问题和困难进行分析，提出解决思路，并在实践的过程中对其进行验证，最后收集实践过程所得到的数据并对其进行深入分析，以获得今后工作的改进思路。

关键词：代码走查;过程改进;模块故障

中图分类号：TP311.5    文献标识码：A 文章编号：2096-4706（2019）01-0190-02

Analysis of the Practice Process of Effective Code Checking

ZHOU Mei

（Jiangxi Industry Polytechnic College，Nanchang  330039，China）

Abstract：This paper mainly summarizes some achievements in the practice of the previous section of code checking. At the same time，it analyses the problems and difficulties in the process of work development，puts forward solutions，and verifies them in the process of practice. Finally，the data obtained from the practice process are collected and analyzed in depth in order to obtain the improvement ideas for future work.

Keywords：code checking;process improvement;module failure

0  引  言

在小組开发工作中，代码走查工作一直是一个较难开展的工作。由于在代码走查过程中发现的问题和故障较少，所以这部分工作总是收效甚微。所以在开发进度较紧张的情况下，代码走查工作往往是第一个被省略。

笔者认为代码走查工作展开难的原因主要有以下两种：首先，代码走查工作人员安排问题，比如以往某个模块编码完成后，会安排其他开发人员对其进行走查，如果开发人员做过类似的模块工作，则能查出一些问题，但大多数情况下，开发人员对此模块不熟悉，其在查看整个模块代码之前首先需要花费较长时间查看模块设计文档，在有限的时间内，他们在没有搞清楚复杂模块代码功能的情况下，就匆忙填上几个问题，提交走查报告，以按时完成任务;其次，问题排查难及验收标准模糊，走查过程中对模糊问题界定及其位置确定困难，同时在有限的时间内对代码走查到什么程度，没有一个验收标准。针对上述问题，我们实践情况如下。

1  工作安排

从2017年8月23日到同年10月21日，小组进行了12次代码走查，共覆盖8个模块，其中经过测试的模块有3个，未测试的模块有5个，走查的代码总量达到：22.06kloc。而这些工作往往又是在研发进度相当紧张的情况下完成，既要对模块进行代码走查，还有其他项目工作。由于时间紧张关系代码走查工作就不会全面走查。因此在工作安排中，要特别注意时间问题，并在小组中强调一定要保证走查工作时间的准确性，本次所得数据基本能反应真实投入时间。走查工作时间汇总如表1所示。

从数据中可以看到，由于单次代码走查的规模控制到了2Kloc，单次走查所用的时间最大10个小时，也就是一个多工作日。所以从计划上讲，单次走查的工作很好安排，在开发过程的任意阶段都可以安排。并且这个最大值是某一个模块第一次走查的时间，该模块第二次走查的时间已经下降到6小时。这也就是我们能在不到两个月的时间内连续安排12次代码走查工作，并能有效实施的原因。

那么开发人员是否认为工作量过大或认为走查工作影响了他们负责模块的进度呢？笔者就此询问了两个走查工作做的最多的人，他们反馈工作安排上没什么问题，完全能按计划完成，也容易达到要求。虽然第一次走查的工作有一定难度，需要看相关的文档，但第二次就较为轻松。

2  走查工作效果

走查效果是笔者在实施改进工作中最担心的。笔者从PR中收集走查效果数据如表2所示。

由于没有其他参考数据，相对以往的数据空白，这个数据体现了我们的工作效果。本次代码工作总耗时为92.25人时，故障发现率为1.1/人时。与单元测试，集成测试以及系统测试相比较，代码走查故障发现率最高。

因走查人员理解偏差，以及模块负责人和走查人员对问题界定存在差异，这些故障数据也存在一些问题，例如提交的大部分是代码确实存在问题的故障，而其中某些问题代码已经经过两轮测试。笔者之前以为经过测试的代码基本不存在问题，但此次走查在三个已经测试的模块代码中仍然发现了57个故障，占所有故障总数的55.88%。这些问题虽在所难免，但在后续工作中我们也应该着力解决。

3  故障类型

笔者根据PR故障分类对所有模块故障进行分类，结果如表3所示。

从故障分类结果可以看到，大部分故障都与功能的实现相关，在数据方面的体现就是程序处理和异常保护占了最大的比例，而不是程序功能。程序功能问题提出人员分两种，一种是模块设计人员，一种是模块接口人员，他们对模块较为熟悉，走查结果显示利用对模块熟悉的人员走查代码能更好的效果。但是实际的工作中，我们不可能为每一个模块都配备对其熟悉的工作人员进行走查工作，这种通过为模块配备对其熟悉的工作人员来提高故障排除效率的方法缺少实用性。因此在实际工作中，通过不熟悉模块的工作人员进行走查，仍是代码走查工作的主要方式。从代码实现本身也能发现很多问题，至少目前的数据能证明这一点。

根据以上数据分析，我觉得此次走查工作达到了以下目标：第一，改进了走查工作;第二，走查结果超出预期。第三，此次代码走查得到的数据，为我们改进后续工作提供了参考。如果把代码走查放到一个软件工程中，作为一个过程控制的节点，我们一定希望这个关键点提供一个可控的、客观的、标准的检测缺陷的方法，我们不希望代码走查的质量过分的取决于走查者的技术水平。

4  结  论

虽然代码走查不能解决所有问题，但可以发现很多问题，而且这些问题的发现对后续工作意义重大。代码走查的长处是发现一些比较直观的东西，包括细节层面的如规范层面、内存层面、编码层面等和宏观层面主要是设计层面和需求层面.因此，针对代码走查工作在具体的操作中存在的问题代码覆盖率不高，重大问题发现较少，走查方法较为单一，走查技巧缺乏等。我们会继续关注并努力解决，从而提高走查代码覆盖率和代码走查质量。

参考文献：

[1] 孙卫红.代码走查的研究与实践 [J].计算机与网络，2007（22）：41-42.

[2] 王志，刘斌，钟德明，等.代码走查辅助工具的MDA开发模式 [J].计算机工程，2007（23）：87-89.