代码REVIEW的一般方法

代码REVIEW的工作是软件工程中不能忽视的工作，是软件质量活动之一，对保障和改善软件工程质量有比较明显的作用，特别是对团队进行开发的软件工程。本文主要以C代码的视角描述CODE REVIEW的一般方法。

一、代码REVIEW前的准备工作

了解软件的基本架构，软件层次关系以及模块间关系，业务流程的任务划分。这个要求是对设计文档需要比较详细的了解。如果没有详细的设计文档，至少要有比较清楚的业务流程和模块划分。

二、代码REVIEW的一般性检查

1、代码文件和目录的REVIEW

检查软件目录是否安排合理，是否按一定的规则进行，有的是按照软件的层次进行目录的分配，有的是按照功能模块进行目录的分配。比较糟糕的目录结构是按照部门和小组进行分配，对于整个软件系统来讲没有机构的概念，支持层次和模块的概念。检查文件命名是否符合编程规范，让人一看就知道此文件或目录说明了什么。

2、代码头文件的检查

容易犯的错误是代码头文件中，不区分内部使用还是外部使用头文件的包含关系是否按层次

3、函数名称的检查

文件中内部使用函数和外部使用函数，内部使用的函数不应暴露在对外使用的头文件中，内部使用函数名称是否和对外函数名称容易区别，函数命名是否符合编程规范，函数命名中使用的参数检查，是否函数中有太多的参数，是否可以使用结构来进行命名和描述

4、结构和变量

内部使用的结构和对外暴露的结构也要分辨清楚，头文件中只声明对外使用的结构，内部变量和外部变量分清楚，外部变量尽量少用，可以通过函数的方式进行获得。

5、函数体内的变量

是否定义太多的变量，很多时候，在调试中加入测试代码和变量，正式版本没有将多余的部分删除掉，在编译过程中一般都会有警告，可以关注变量没有使用的警告。

6、函数输入参数合法性

函数体内定义外变量，通常就是函数输入参数的检查，特别是空指针的检查，参数值的范围检查，这些都是代码可靠性的必须要进行的工作。

7、变量的初始化

在函数体内部使用的变量，通常都需要进行初始化，给变量一个缺省值，编译器不一定会给变量一个缺省值，定义的指针要赋值空间。

8、检查空间越界

数组下标的越界，指针空间的越界，需要重点关注，memcpy, memset, strcpy等的C函数也需要重点关注，常常犯错误。

9、循环执行体检查

FOR, WHILE， DO WHILE 循环的退出条件和中止条件的检查，常常是条件不对，数值多一个或少一个就退出或中止，特别是N,N+1, N-1到底是哪个值，还有是大于还是大于等于，小于还是小于等于。对于复杂的退出或中止条件一定要仔细检查，与或条件的检查，括号以及优先级检查。

10、条件执行体检查

IF ELSE 和SWITCH的检查，IF ELSE条件的充分完整性检查，SWITCH 多路选择的完整性检查，经常会出现遗漏的情况，IF 条件中“==”误写成“=”，眼神不好容易遗漏，同时编译警告有时也会不注意。

11、函数返回前检查

MALLOC临时申请的空间，是否释放FREE，在函数中途异常退出的地方，没有FREE，大家都习惯在函数最后进行释放，这个常常遗漏。返回值是否在设计范围内，返回的空间指针是否被收回。

三、代码REVIEW高层次检查

1、函数的多任务调用

全局变量的保护，加锁解锁，有的是函数下又封装了函数，这个问题就比较容易隐藏起来，定位比较困难。另外一个解决办法改多任务调用为单任务调用，从调用的架构上来修改。

2、临时内存数据传递的保护

在多任务系统中，有的任务将数据写到一空间以便另外的任务来读取，另外的任务在读的过程中，任务改写此空间内容，极端的就释放此空间。这种情况表现形式多样，不同的业务场景代码实现不同，比如读写通道，关闭通道，消息传递等等。

3、多任务下状态机迁移混乱

这个就属于设计不足，要么是设计中有遗漏的情况，要么就是设计状态机过于复杂，迁移条件太多。

4、下层模块的代码调用上层代码

这种情况不是不允许，而是不好，容易导致调用关系混乱，特别是多任务系统中，容易导致多任务调用。比较好的凡是是下层代码发消息给上层代码。

5、单个资源被多个任务使用

常用的解决方式是使用一个单独的调度任务进行此资源的使用，多个任务向这个任务请求使用，保证单个资源由一个任务来控制。

6、多任务的互锁

这个在多任务的程序中也不经意的会犯，好的解决方式是减少锁的设计，甚至是无锁设计，通过将资源进行管理的方式来降低多任务下的调用。

7、非阻塞和阻塞的使用

在多任务系统下，合理使用阻塞和非阻塞的函数实现，这个应该是设计时加以注意。明确那些任务是非阻塞运行，那些任务是可以阻塞运行。

8、业务流程中异常的处理

在复杂的业务流程中，正常的流程一般设计和编写代码都可以完成的很好，但是业务流程中都会有异常出现，设计中和编写代码中，如何尽可能将异常都考虑全面，处理的全面，是比较考功底的，异常的REVIEW也是关键，牵扯到业务流程的覆盖程度。

9、代码的扩展性进行REVIEW

业务经常是变化的，所以接口代码就要跟随修改，如何为后续修改带来方便，对接口设计和编写就要有一定的灵活性和可扩展性。可以参考链接https://blog.csdn.net/DQWKLC/article/details/91491972

10、代码复杂度的REVIEW

代码中的复杂度也是需要进行REVIEW的，特别是性能优化上，代码复杂，执行的效率一定会打折扣，而且容易出错。关键的算法应该通过设计减小复杂度，通过前期的伪码设计，减少或降低实际编写代码的难度。

代码REVIEW的一般方法相关推荐

如何进行代码REVIEW
一.代码REVIEW的利与弊软件工程中,最后都落实在代码的实现上,软件要运行的没有问题,除了软件架构和系统设计设计到位,代码实现也是至关重要的一部分,再好的设计如果软件代码实现有问题,软件也不能跑起 ...
代码REVIEW的流程化工作
一.CODE REVIEW工作组织建立代码REVIEW的工作,多数人认为是程序员的事情,其实恰恰理解的不充分,代码作为软件最基本要素之一,仅仅是之一,软件其实还有很多方面,设计,推广,销售,服务等等 ...
代码安全检视方法有_武汉地域SE沙龙第二期——安全代码review方法学习
原标题:武汉地域SE沙龙第二期--安全代码review方法学习 Part1 1 继6月26日开展的SE第一期沙龙--安全编码TOP问题之后,武汉地域于7月11日晚19:00-20:30又开展了第二期S ...
由学习《软件设计重构》所想到的代码review（二）
前言对于一个程序员来讲如何来最直接的来衡量他的技术能力和产出呢?我想最直观的作法是看他的代码编写能力,就拿我经常接触的一些程序员来看,他们买了很多技术重构类书籍,但是看完后代码编写能力并没有显著提高 ...
如何有效地进行代码 Review？
研发都知道代码 Review 的重要性,在腾讯代码 Review 也越来越受大家重视,作为腾讯专有云平台研发的一员,我参与了大量的代码 Review,明显地感受到有效的代码 Review 不但能提高代 ...
代码review，瑞出事来了！
不久之前,部门进行了一次代码评审. 代码整体比较简单,该吹B的地方都已经吹过了,无非是些if else的老问题而已.当翻到一段定时任务的一步执行代码时,我的双眼一亮,觉得该BB两句了. 谁知这群家伙, ...
研发团队如何借助Gitlab来做代码review
代码review是代码质量保障的手段之一,同时开发成员之间代码review也是一种技术交流的方式,虽然会占用一些时间,但对团队而言,总体是个利大于弊的事情.如何借助现有工具在团队内部形成代码revie ...
Android产品研发（二十）--代码Review
转载请标明出处:一片枫叶的专栏上一篇文章中我们讲解了如何在Android studio中进行单元测试.实际开发过程中有一些功能性的需求,比如测试工具类,测试数据存储等测试工作,如果还是通过重复执行a ...
代码REVIEW指南
一.概要代码Review 是被鼓励在开过过程全阶段执行,在一些关键点代码Review是被正式要求执行.本指南中规范代码审查活动,并指导审查人员按照该指南执行该活动. 二.过程 1.新增代码 ACTI ...

代码REVIEW的一般方法

代码REVIEW的一般方法相关推荐

最新文章

热门文章