一般的 IT 公司有严格的代码审查吗啥书中说的很重要的东西. 实际上我们公司没有

我目前工作过三家IT公司,一家1000+,一家300+,目前这家200+,公司从来没要求过代码审查。我们只是在个别团队中实行过代码审查,但是说起来容易,实施起来却困难重重;主要原因主要有以下几点:1.大部分人的代码我想除了他自己可以看懂,其他人很难理清逻辑——说白了只能说明此人代码烂,没别的原因;2.每个人有每个人的代码风格,在审查别人代码时很容易自作聪明的提出自己喜欢的方式去要求别人;3.即使以上两点都解决,也做不到坚持审查,主要是项目产品时间压力,让你无暇去顾及别人;我的建议是代码审查最好在两人间进行,而且这两人要有较显著的技术差距,对于高水平人员来说让低水平人员来检查自己的逻辑(防止自己粗心),对于低水平人员来说,可以通过高水平人员的指导和学习高水品人员的代码来提高自己;
■网友
我们公司现在有比较严格的代码审查,使用gerrit。从使用到现在有以下感受:1. 确实会提高质量 Review本身提出的意见只是一方面,另一方面是如果code拿过去review,大多数人都会在review之前更加严格的审视自己的code2. 加重了沟通负担 现在approve权利还是在国外,几乎每次提交都需要解释一大堆。3. 主要还是注重对架构的影响 虽然有时候提出的意见是细枝末节的,不过有时候确实会出现提交的代码破坏了之前的架构设计,这是最关键的审查要点。4. 基于gerrit的code review比面对面的更严格一些 以前一直是面对面的code review,不但耽误时间,而且由于被审查者会从头到尾解释一遍代码,审查者很多时候不会去仔细查看代码,而是听听讲解就算了。这样一些细微的问题就不会被发现,还有就是在面对面code review时提出的修改意见,有很多不会被落到实处。
■网友
感觉做Code review, 不能只是看代码。我们公司的流程是这样的:在每次check in 之前,发一个Code Review Request给相关的同事,在这个Request内除了code change外,还要描述: 要解决的问题是什么?怎么解决的?(可选). 有没有什么局限性? 代码上的改动,比如数据结构或者主要函数的变化;如果有regression test的话,结果如何等。实践下来,感觉还不错,如果还不清楚,就一对一的坐在一起做review.
■网友
公司的代码审查流于形式而内容空虚,原因如yaocoder所言。个人感觉还不如自己用静态审查工具(CppCheck类)跑一遍来得直接。


    推荐阅读