团队代码评审的思考

【声明】本文为AdamsLee原创,转载请注明出自围炉网并保留本文有效链接:团队代码评审的思考, 转载请保留本声明!

这么多年从事研发,经历过几家公司。每家公司都会推动code review。然而code review的方法和效果可能还是有些差异的。

code review的方法和效果最好的我认为是我的第一家公司微软。微软那是的代码库使用的是Source Depot。代码变更可以使用工具打包生成.dpk文件后邮件发送给同事进行评审。评审人员可以把变更应用到本地后进行评审。后来也有些工具就可以更方便的对代码进行标注反馈了。我们部门的同事code review基本上是私下发邮件或者两个人坐一起看代码。微软的同事code review氛围比较好,评审都很认真。

后来进入的公司,发现有的团队会进行整个小组在一个会议室里评审一个人的代码,由被评审人员讲解,其他人在下面看。这种方法我不太主张,因为我发现这种方式下效果不一定好。因为看代码有的时候需要根据函数调用前后翻着看的。这种团队评审式的code review,坐在下面的人无法跟随自己的思路去翻阅代码,可能遗漏本该发现的问题。另外因为同时有多个评审人员,责任并不明确,会有一部分人懒于提出自己的意见和想法,从而没有起到应有的评审效果。

我的建议:

  1. 需要培养好团队的重视质量的文化,人人积极参与的文化。

  2. 允许花时间和资源进行评审。不要因为赶项目进度而忽视评审质量。

  3. 给评审人员自由翻阅代码和思考的机会

  4. 团队本身有编码标准,并且标准取得了团队人员的认同

  5. 找到良好的code review工具

此条目发表在未分类分类目录,贴了标签。将固定链接加入收藏夹。