我们为什么要做代码复查?
软件行业与其他行业还是略有不同,制造业会有相应的制造业的行业质量标准.质量问题比较直观.并且制造业几乎是无法进行变更的.设计出的内容几乎无法改变.
但对于软件行业来说,就比较纠结.客户需求比较抽象,并且伴随着需求不断变化.往往最初良好的设计,做着做着就会慢慢的违背了最初的设计,代码质量直线下降.代码修修补补千疮百孔.开发的人慢慢对自己的代码也失去了信心.如果有幸将代码交出去还好,如果交不出去,只能拍屁股走人.接手的人继续进入这个恶性循环.悲剧天天发生.
开发者不爽,测试不爽,开发经理不爽,客户不爽.最终导致的结果大家也可想而知.
当然还有另外一种抱怨(包括我之前也是这么想的),工期紧工作量还那么大.再进行代码复查.这额外的工作压力是不是更大了?但反过来想,是不是大家也感觉到了测试阶段,缺陷不断产生而导致不断修改代码痛苦呢?磨刀不误砍柴工,往往有些困难和痛苦是由自己想出来的.
说了这么多,我们也来看看代码复查是否能给我们带来更多的好处呢.以下为我个人观点:
降低严重缺陷
对于软件开发而言,最恐怖的缺陷无疑是代码内部产生的,表面上风平浪静.一旦爆发,必将酿成大祸.这样的错误往往又是黑盒测试很难测试出来的.通过代码复查能够避免掉一些类似的错误.
要寻找深藏不露的程序bug,正式地进行代码检查,其效果是任何已知形式测试的两倍,而且是移除80%缺陷的唯一已知方法。 ——Capers Jones的《估算软件成本》
提醒开发者加强自查
你知道你的代码没有人会看的话,你编写的代码往往会比较随意.反正没有人看,写成什么样也就无所谓了.但是反过来,如果你知道你提交的代码一定会有人检查的话,也就会更加谨慎的编写自己的代码.相信很多开发者责任心和自尊心比较强的.没有开发者希望自己的代码会被人鄙视.逐步逐步的改善个人的代码质量,这本身就是对技术的一种提高.其实个人感觉,技术上并不存在无法掌握的内容,但是之所以有的人能够成为大牛,就是他从最开始就对自己的代码有高度负责的精神.你的代码质量反映了你对这个行业的热情.
把代码复查作为一种学习或者交流
新手可以有更多的机会向老手学习和指导,提高自身的设计水平,老手通过对新手的指导,整理和升华自己的设计思路与理论,同时也是对自己另一方面的锻炼与提高。另外,当你发现并指出了别人的一个问题以后,同时也是在警示自己不要犯同样的错误,这对审查与被审查者都是有益的。
避免重复创造轮子
在代码复查中经常会发现一些大段重复的代码,跟开发者进行交流后了解,是由于工期比较紧张,直接拷贝过来的.功能是实现了.但是一旦需求变化,需要修改的地方就多了一个点.
还有一种情况,在代码复查的过程中发现很多人还是使用java基本的文件读写API,而不使用apache commons包中的api.对开源已经实现的功能不熟悉,导致编写大量重复的代码内容.
这种代码结构和开源API的使用上,其实可以在代码复查中及时发现,并进行组内分享.让大家能够编写出更加良好代码结构.
对项目了解的更为全面
如今的项目都不是一个人在战斗,项目大人多,对于项目的理解也往往会局限于自己的模块.在代码复查的过程中,一方面了解别人的代码风格,也顺便了解了其他人的模块业务.对于整个项目团队而言,也避免了产生"代码英雄"的情况.
如何进行代码复查?
之前项目组也做过几次代码复查工作,但是效果不是很明显.
一是没有很好的坚持,觉得代码复查是个负担.项目工期一紧张也就疏忽了.
还有个原因可能是开发者不是很明确如何进行代码复查.发现的问题比较表面,例如:注释问题,String使用"+"号进行拼接等问题. 代码复查过程中并没有思考相应的开发者的开发逻辑,也就很难发现严重的问题.
那如何进行有效的代码复查工作,以下为我个人观点:
首先保证有能够有良好的代码自查
为什么说了半天的复查,为什么突然说上代码自查来了?其实编写代码好比写作文,如果你一堆的错别字就教了卷子,估计文采再好也难得好分数.
其实代码自查的辅助工具有很多.包括checkstyle findbug pmd等等,这里就不累述了.这里只是想说说最基本最简朴的checklist.
checklist应该是每个开发者有的最基本的代码自查工具.checklist的点不宜过多.如果过多,容易造成开发者的抵触.太少又达不到效果.之前做过一个组内使用checklist,7个大类.每个大类不超过5条内容.自查的内容是在提交复查之前一定要自己先检查的内容.如果复查者发现提交的代码还有checklist里的问题,可以直接停止复查.并退回给提交开发者进行重新自查.
提交代码复查流程
之前在项目组中都只是分配了谁来复查谁的代码,但并没有明确的代码复查流程.导致的问题是,复查人不知道被复查的人都提交了哪些代码,提交的这些代码都是实现了什么样的业务逻辑,当然也就无法发现相应的代码里的问题.我简单整理了下代码复查的简单流程,如下:
这样做其实也存在一个问题,会产生大量的提交代码复查的说明文档,并且不能及时通知复查者进行复查.网上倒是有一些工具可以简化这样的事情,例如:
Review board 或者 code collaborator等工具.由于没有亲自测试过,这里也不做广告了就.
另注,这篇文章在进行复查的时候,有人也给我了一些建议.说明文档是不是可以通过代码注释来进行简化?(如何能够让开发者不抵触复查,就需要更加简单高效的方法).但是注释一定是需要充分表述清楚相应代码的逻辑,这种方法才是可行的.代码注释可能会单独再进行一篇文章进行说明.这里也不在累述.
提交代码复查的量不要过多
进行复查的时间固定而且不要时间过长
限时修改相应的复查问题
重视交流
后记
代码复查这件事儿本身而言,其实并不是一件讨巧的事情.功能没有新增,样式也没有变化.客户永远不知道你都付出了多少.但对于开发者而言,这是一件既能提高自己又能方便他人的事情.至少是件没有坏处的事情.
真想从代码复查中获利就需要不断的坚持.量变带动质变.当我们的团队都有良好的编程习惯的时候,相信不断加班修改缺陷的日子也会逐渐离我们远去.