关于代码复查的一些笨想法

我们为什么要做代码复查?

软件行业与其他行业还是略有不同,制造业会有相应的制造业的行业质量标准.质量问题比较直观.并且制造业几乎是无法进行变更的.设计出的内容几乎无法改变.
但对于软件行业来说,就比较纠结.客户需求比较抽象,并且伴随着需求不断变化.往往最初良好的设计,做着做着就会慢慢的违背了最初的设计,代码质量直线下降.代码修修补补千疮百孔.开发的人慢慢对自己的代码也失去了信心.如果有幸将代码交出去还好,如果交不出去,只能拍屁股走人.接手的人继续进入这个恶性循环.悲剧天天发生.
开发者不爽,测试不爽,开发经理不爽,客户不爽.最终导致的结果大家也可想而知.
当然还有另外一种抱怨(包括我之前也是这么想的),工期紧工作量还那么大.再进行代码复查.这额外的工作压力是不是更大了?但反过来想,是不是大家也感觉到了测试阶段,缺陷不断产生而导致不断修改代码痛苦呢?磨刀不误砍柴工,往往有些困难和痛苦是由自己想出来的.
说了这么多,我们也来看看代码复查是否能给我们带来更多的好处呢.以下为我个人观点:

降低严重缺陷​

对于软件开发而言,最恐怖的缺陷无疑是代码内部产生的,表面上风平浪静.一旦爆发,必将酿成大祸.这样的错误往往又是黑盒测试很难测试出来的.通过代码复查能够避免掉一些类似的错误.
要寻找深藏不露的程序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等工具.由于没有亲自测试过,这里也不做广告了就.
另注,这篇文章在进行复查的时候,有人也给我了一些建议.说明文档是不是可以通过代码注释来进行简化?(如何能够让开发者不抵触复查,就需要更加简单高效的方法).但是注释一定是需要充分表述清楚相应代码的逻辑,这种方法才是可行的.代码注释可能会单独再进行一篇文章进行说明.这里也不在累述.

提交代码复查的量不要过多

提交代码复查量不要过多,其实跟代码复查的频率也是有关系的,如果一周进行一次代码复查,那提交的复查代码一定是很多的.如果是每天进行复查.复查的量就会少很多.而且对于目前的MIS系统而言,代码复查的重点其实也就集中在service和数据库交互的部分.而不是所有的代码都需要进行集中复查.代码复查也是一个需要思考的过程.如果代码复查的量过大的话,其实不利于复查者复查的质量.

进行复查的时间固定而且不要时间过长

复查者在日常工作中其实也是一线的开发者,日常的工作安排还是比较多.如果进行复查的时间不是很固定,是不利于复查者日常的工作安排.建议项目组以固定的时间安排代码复查.复查者在固定的时间内需要完成,对于之前代码复查的结果跟踪,是否已经完成了修改.然后在对新的代码进行复查.复查时间建议在60分钟左右.时间过长同样会降低复查者的复查效率.

限时修改相应的复查问题

限时修改的说法,写的时候还是有了一丝犹豫的.代码这个东西,有时候表面上觉得很简单的事情,其实修改起来并不容易.限时修改我这里想说的其实也是开发者对复查者的一个承诺,对于类似的复查问题,我可以在什么时间内修改完.而不是将复查的问题高高挂起.避而远之.如果复查的问题,没有跟踪.久而久之也就没有人理会相应的问题.代码质量还是飞流直下三千尺的.

重视交流

代码复查本身其实就是技术交流,但是范围还是局限在复查者和被复查者之间,定期的进行对复查问题的整理,并及时进行分享.对于整个团队的代码复查质量也会是一种提升.

后记

​ 代码复查这件事儿本身而言,其实并不是一件讨巧的事情.功能没有新增,样式也没有变化.客户永远不知道你都付出了多少.但对于开发者而言,这是一件既能提高自己又能方便他人的事情.至少是件没有坏处的事情.
真想从代码复查中获利就需要不断的坚持.量变带动质变.当我们的团队都有良好的编程习惯的时候,相信不断加班修改缺陷的日子也会逐渐离我们远去.