做好代码审查:思考、方法和实践
作者:网络转载 发布时间:[ 2013/3/15 11:35:47 ] 推荐标签:
近被要求做一个关于Code Review的讲演。首先要说明的是,我并不是太擅长开展Code Review的活动。做这个完全是因为答应了别人又不好反悔。不过在做准备的过程中还是有一些感想。
关于Code Review我所了解到的行业中的是Bill Gates汇报。这是微软在软件开发过程中的一个重要环节,因为Bill Gates亲自参加而备受关注,在行业中广为流传。
Ok,进入正题了。
我们面临的共同问题:
1、对于开发周期较长的软件项目,可维护差的代码对项目造成了极大的困扰
2、结构复杂的,体系不清楚的代码会导致新成员或者外部干系人很难融入。
3、软件项目代码质量低下,Bug众多并且有关联累积效应。
以上三个问题是我在以往的Code Review活动中总结出来,可以被影响或者解决的问题。也是说我的观点是如果没有上述问题,或者在目前的软件产品的规模、开发过程的成熟度还没有达到一定级别时Code Review是可以不做的。当然的开发人员会做自我审查,这是另外一个问题了。
总而言之,我认为开展Code Review活动的前提是
1、开发过程和质量控制达到了一定的成熟的。
Code Review必然与重构相关联。如果开发过程中更本没有重构这样的活动,那估计Review出来的结果不太容易得到执行。
其次是各种标准和规范的齐备性,没有规矩是不能成方圆的,如果只有一个命名规范,那可想而知Review的内容不会太深入,效果因此大打折扣。
2、代码达到一定那个的规模一般来说,功能单一的小型项目的体系结构不会太复杂。不太会出现Bug的累积效应。小型项目完全可以通过daily meeting和Test来保证。
Code Review并不是一个随便可以做,或者做了有好结果的活动。不过无论如何,一旦条件成熟或者资源充足都应该积极的开展Code Review的活动。因为它除了进行质量控制以外,还是一个团队成员之间进行沟通和相互学习的好机会。
Code Review的内容:
1、代码的规范性
a、混乱而散漫的命名,例如使用a、b、c这样的单字母对变量进行无意义的命名
b、随处可见的magic number或则hard code。软件中const在所难免,不过这些const应该被集中管理起来。而不是可以随意、随处的出现
c、缺少注释,或者注释不完备甚至错误
2、代码的结构问题
a、巨大的类或者巨大的方法
b、过于复杂的实现
c、紧耦合
d、重复的代码
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11