如何进行代码REVIEW

一、代码REVIEW的利与弊

        软件工程中，最后都落实在代码的实现上，软件要运行的没有问题，除了软件架构和系统设计设计到位，代码实现也是至关重要的一部分，再好的设计如果软件代码实现有问题，软件也不能跑起来。

        代码编写的质量直接影响软件程序运行，所以不同的阶段都有措施来进行软件代码的质量检查。其中代码REVIEW是对代码质量非常有用的检查办法，对提供代码质量和程序运行的稳定性，其作用也是非常大的。

首先着重讲一下代码REVIEW的好处，可以分几个方面来描述

       代码REVIEW直观的好处是提升了代码质量，将问题放在前期来解决；问题越拖到后期，解决的成本越大，这是大家都熟知的理论，更重要的是项目的质量通过这些措施可以得到一定的保障，是质量活动的一部分。

        代码REVIEW还有纠偏的作用，就像导弹打飞机的场景，目标是飞机，导弹不断纠正轨迹，确保在有效的射程中击中目标，如果不能及时纠偏，势必要大角度机动来靠近目标，这样在有效的射程，很有可能没有打到目标，燃料就已经耗尽了；同样在项目中REVIEW的道理也是一样的，及时纠偏，确保项目进度和目标达成。

        代码REVIEW对应团队养成良好的编程规范有很好的促进作用。同时对应团队良好的沟通也会产生积极作用，代码风格一致，大家一看就懂，形成开发中的默契，可以有效提高开发效率。

       代码REVIEW对于编写代码的人和REVIEW代码的人，都是种提高，提高读代码的能力，提高编写代码的能力，别人的经验教训可以为我所用。

      代码REVIEW对系统设计同样有积极作用，可以发现系统架构中不合理的地方，特别是模块间，任务间，层次间的接口的扩展性，易用性，代码的隔离上有很大的帮助，促进架构演进。

下面对代码REVIEW的弊端也分析下，代码REVIEW的工作会使工作量加大，这是肯定的。人是会偷懒的，所以REVIEW的效果有会打折扣，REVIEW工作流于形式，代码带病进入下一个环节，甚至到上线运行出问题。

       对于写代码的人，有可能就放松了要求，反正有人需要进行REVIEW，代码差些就差些，REVIEW的时候，可以指出就可以了，产生依赖心理。对自己的代码责任心就会降低。代码后期或上线运行出问题，大家都替写代码的人“背锅”，“我的代码，你们也REVIEW了，你也没有检查出来”，互相推卸责任。导致REVIEW代码的人工作积极性受到损伤。

       同时对写代码的人，他是有抵触情绪的，相当于对他的工作找毛病，特别是对应一些不改也对，没有原则错误的代码，改了性能维护性更好的代码，容易导致写代码的人和REVIEW代码的人产生对立情绪。

二、代码REVIEW的层次

代码REVIEW的程度也是有高低之分的，所以REVIEW代码发现问题的深度也是有的。可以将代码REVIEW分成以下几个层次：

 

层次	解释	难度
1	代码风格和编程规范的REVIEW	低
2	代码中语法的REVIEW	低
3	代码中输入输出的REVIEW	低
4	代码中算法和逻辑的REVIEW	较高
5	代码中异常处理的REVIEW	较高
6	代码REVIEW对系统设计和实现符合度	高

 

      代码风格和编程规范的REVIEW，这个层次的REVIEW主要是检查代码的规范性，每个软件团队都相应的有自己的编程规范，方便进行沟通和对接；代码中语法的REVIEW层次里，通过编译器，执行器都可以将大部分语法问题解决掉，这里强调的是语法当中有的是提示和警告，此类的问题往往容易忽略掉，代码编写的人员一定要看一下这些警告是否会对代码有影响。

       代码中输入输出的REVIEW，主要是针对接口的REVIEW，不同的模块层次需要使用接口来进行数据的传递，检查重点是接口对数据传递的适用性，有无限制，扩展性如何。

        代码中算法和逻辑的REVIEW，包含逻辑的正确与否, 算法的复杂度，此层次应该是REVIEW的重点，代码中的问题有相当部分隐藏在这里，而且有时是很难发现的，特别是牵扯的模块代码比较多，调用关系复杂的情况下。

       代码中异常处理的REVIEW，程序员写代码有个习惯，就是正常的业务逻辑功能都实现的很好，流程也对，可一上线运行，这问题那问题，很重要的一个原因就是对异常的处理没有全面的考虑，这个也是一般程序员和有经验程序员的一个重要区别，有经验的程序员考虑问题相对全面。对业务流程的异常处理，有的设计文档如果做得很细的话，可以比较方便的实现，如没有详细的设计文档，则全凭借经验。代码中的异常这个完全是个人编程功力的体现，没有设计文档可参考。此层次的REVIEW也是需要重点关注的。

       代码REVIEW对系统设计和实现符合度的检查，通过REVIEW代码可以了解系统设计和实现是否一致的，程序员和设计师有时的思路是不一致的。

三、代码REVIEW的方法和步骤

       假如有系统设计文档中的详细设计的话，通过预先阅读详细设计文档，基本上了解软件运行的整个过程，然后在进行代码的阅读，通过代码的REVIEW检查是否和详细设计文档的符合。这个是比较好的一种方式，而且相当来说阅读的难度会降低，但是很多软件的设计文档是缺失的，有的甚至连规格功能说明都没有，都是口口相传，没有书面的资料，REVIEW代码的人要硬着头皮去看代码，非常考水平，要根据代码理解算法后逻辑，代码需要反复交叉去阅读，非常费时间，这种REVIEW多半没有什么效果。

       代码串讲也是很好的一种REVIEW的方式，这个弥补了一部分没有文档资料的困难，由写代码的人进行介绍，将业务逻辑和代码运行讲给REVIEW代码的人，这样REVIEW代码的人就可以直接现场提出问题和质疑，和写代码的人员直接沟通，效率是比较高效的，一般的做法是写代码的人召集REVIEW的人员进行开会来集中讲解代码，然后进行问题讨论，会后分析修改代码。

 

附：代码REVIEW的一般方法

https://blog.csdn/DQWKLC/article/details/97652783