Code Review那些事儿
曾经有一段 垃圾代码放在我的面前,我没有拒绝,等我真正开始接手的时候我才后悔莫及,程序员最痛苦的事莫过于此!---------改编于周星星的经典台词。
虽然有点夸张,但编码界确实大大存在这种情况,每当接手别人的代码,都有一种想重新写一遍的感觉,等到别人再来接手你的代码时,同样的感觉。。。为什么会有这种现象存在?因为没有Code Review
一。前言
Code Review中文应该译作"代码审查"或是"代码评审",也叫代码QC,这是一个流程,当开发人员写好代码后,需要让别人来review一下代码,这是一种有效发现BUG的方法。review之后,可以发现代码的风格、逻辑、思路等问题。然后改进代码,提高代码质量。因为这是代码刚刚出炉的时候,所以,这也是代码调整、代码修改、代码重构的最佳时候。所以,Code Review是编码实现中相当重要的一个环节。
二。Code Review的内容
1.编程素养
见码如见人,代码风格在一定程度上反应一个程序员的能力和素养,如代码风格、注释、变量的命名、缩进、初始值、方法的长度、流是否关闭、连接是否关闭
2.业务逻辑
代码实现的过程,就是对需求理解的一种复现,如果业务逻辑都错了,代码写得再漂亮、再牛B也是枉然
3.架构设计
业务逻辑实现了,只能给60分,代码是否具有高内聚、松耦合、可扩展的特性?是否合理设计模式?
4.单元测试
没有经过单元测试的代码,不是好代码。大多数开发人员认为,测试的环境是测试人员做的事,不然要测试人员做甚?其实不然。
单元测试是一种无价的文档,它是展示方法或类如何使用的最佳文档。这份文档是可编译、可运行的,并且它保持最新,永远与代码同步。
单元测试也是架构设计的一部分,迫使我们在设计时把代码设计成可调用、可测试,从而降低代码的耦合。自动化的单元测试避免了代码出现回归,编写完成之后,可以随时随地的快速运行测试。
5.性能
对数据结构的选择和设置是否合适?
是否采用通用的线程池、对象池模块等cache技术以提高性能?
是否选择合适的IO类或采用良好的方法以提高性能?
同步方法的使用是否得当,是否过度使用?
6.安全
是否有后门?
如果是web页面,是否有csrf、xss漏洞?
是否明文存储了用户名密码?
日志中是否打印了敏感信息?
三。review的方式
1.借助软件,软件请看第四点。
建议开发人员都安装这些插件,发现问题时及时就改了
2.项目负责人或架构师review
晚上review是最好的时机,一般没有人打扰,没有会议,我一般选择这个时候
3.开发人员两两互review
开发人员两人一组,一天一次,review当天的代码。但过于频繁,久而久之就成了过场,然并卵。。。
4.开发人员在会议室review,个人更倾向于这种
代码review最好采用小会议室,开发人员一起review,时长一小时最好,不宜过长,在开发阶段一周一次review。讲解人(开发人员)选取自己本迭代做的某个功能点,先讲业务,然后讲架构、实现过程、再讲代码,期间有问题时可以随时打断,听众提问,讲解人一一作答。个人更倾向于这种。
四。常用的review软件
在敏捷开发中,每个迭代的工作量大概在两三周左右,代码量不是很多,但是如果要项目负责人或架构师一一QC所有开发人员的代码,也是个不小的任务,所以,往往需要借助第三方工具。
1.checkstyle
这是一个代码风格的检查工具,要求过于苛刻,一般很难让所有开发人员都按这个标准来。
2.PDM
这是一个静态代码扫描工具,直接扫描java源码,可以发现很多重复的代码、未使用的代码、复杂的表达式、潜在的bug。
3.findbugs
直接操作class文件而不是源码,着重于发现代码中的bug,不注重style及format
五。注意事项
1.代码review应该在良好的气氛中进行,这不是批判大会,不应有人身攻击,应就码论码。
2.代码review的目的是提前发现问题的好时候
3.代码review可以让知识共享,是互相学习的好机会
4.代码review能防止某个开发人员单点,让更多的了解他的代码,当他请假或离职,不至于手忙脚乱,有效HA
5.代码review一定要有记录,完事后发出会议纪要给所有开发人员,限期整改,项目负责人或架构师在上线前再次review
六。后记
从开发人员来看,代码review会逐步让TA改正不好的习惯,提高编码、设计、架构能力,从而走向人生巅峰,迎娶白富美,哈哈。。。
从团队来看,能改善工作氛围、提高团队的凝聚力。
从项目来看,可以提前发现问题,减少bug,提高稳定性,不再到处救火。
已有 0 人发表留言,猛击->> 这里<<-参与讨论
ITeye推荐