代码review的心得

1. WHY

代码review 是提高开发团队代码质量的一个非常好的技术手段，同时也是了解和培养新手程序员的一个非常好的方法，我个人的建议是所有的开发团队都应该努力推广代码review这一技术实践。

2. WHO

原则上，如果有条件，应该是团队中所有人相互进行代码review，或者说，确保每行代码都被除作者以外的人review过。也就是说，不仅仅团队LEADER要review 新人的代码，LEADER的代码也应该被新人或其他工程师review。

3. WHEN & WHERE

如果按照功能看，建议是每完成一个功能就进行review，从时间的角度看，原则上一到两天review一次，是一个合适的频率。如果未review的代码积累得很多的话，则review起来很花时间和精力，并且如果代码实现有一些瑕疵的话，需要改动的地方也会很多。而程序员的习惯是写代码比较有劲，写完以后再改，并且是因为所谓代码质量去改，则动力相对会不足。

这里有一个要注意的地方，那就是review和代码提交备份的先后顺序。原则上，我们要求所有提交到SVN的代码都是被review过的，也就是说，工程师完成某一功能的开发后，他的主管通过结对编程的方式在他的座位上进行code review，如果review中发现问题，简单易改的问题就当场修改掉，如果改动较大，则由开发工程师在review完成后自己进行修改，待修改完成后，再次review，直到没有问题方可提交代码服务器。

4．WHAT

代码review自然是review代码，不过，说实话，看代码是一件十分辛苦的事情，尤其还是看别人的代码。为了让看代码不至于太耗精力，我建议是看代码之前先想一下如果类似的功能自己来做，会怎么设计和实现，想明白之后，再重点看代码的头文件，是否和自己设计的思路比较一致，这时候如果发现与自己思路不一致的地方，就可以直接问一下代码的作者，了解一下他这样做的目的，总之，代码的头文件是review的重点，抓住这个重点，代码review的工作就可以做得既不过于占用精力，而最终的效果又比较好。

5．HOW

实际在代码review的过程中，建议以一个规范、两个规则作为review的指导思想。所以一个规范，指的就是团队的所谓编程规范，很多TEAM都有自己的编程规范，那么review就是检查是否有不遵守编程规范的地方，一般而言，这一条绝大多数人都可以做到。

所谓的两个规则，就是命名规则和对称规则，命名规则在我的<关于编程中的命名问题>一文中有比较详细的描述，这里重点说一下对称规则。

对称规则规定 1

类的方法除了run等方法外，其余方法都应当是对称出现的，我们把这样的对称出现的方法称为对称方法组，比如open和close、create和 destroy 等。这个规定要求，如果一个类里面有 SAVE方法，则必须要有对应的LOAD方法，也就是说，在review类的头文件时，只看到OPEN方法，而没看到CLOSE 方法，则头文件的设计一定要出问题，也就是说，程序一定存在与此相关的bug。

对称规则规定2

对称方法组中的实现，也应当是对称的。比如在OPEN 方法中，有某些内部数据的内存分配，某些文件的read 等等操作，则CLOSE 方法中，也必须有这些数据相对应的对称方法，即一定要write某些文件，然后再释放某些内部数据的内存。

一般而言，工程师看到规定1，都觉得不会有太大问题，接受起来也比较顺利，而对规定2，初看觉得也不会有太大问题，但深入的按照这个规定去检查自己的代码，就会产生这样一个问题：真的所有对称方法组都做到完全对称的实现吗？那我这个RELEASE函数怎么做不到和它的INITIALIZE 对称？

对称规则推论

对称方法组中的实现，如果无法做到对称，则程序设计很大可能出了问题，同时程序很可能隐含了重大bug，因此，程序员应该把这种情况视作程序需要重构的信号，认真和仔细的思考类的设计是否合理。

这个推论是我对规定2中提问的工程师的回答，如果RELEASE函数无法做到与INITIALIZE对称，那么这个类的设计肯定有问题，如果类的设计也没问题，则整个程序一定有某一个地方设计有问题，才导致了我们无法做到完美的对称实现。

这个推论我觉得是蛮有趣的，我刚开始介绍的时候，很多工程师听到以后都颇不“服气”，这里我举一个我遇到的很典型的例子。

某个类里面有一段数据需要在程序释放后保存，这个需求要满足，类的OPEN函数是这样做的：先判断是否存在该文件，如果该文件存在，这读取该文件中的数据，如果不存在，则创建该文件。对于这个类的CLOSE，如果要对称实现的话，就十分纠结了，问题的关键在于在CLOSE的时候，要不要删这个文件，如果不删，则程序应该在什么地方删除这个数据文件？如果删除，那么程序重新起来的时候，用户会发现上一次操作时的数据丢失了，要重新设置，这也就失去了保存文件的意义了。当时这个问题折腾了有一个小时，觉得怎么做都无法满足对称规则，最后，在坚信对称规则正确的情况下，找到了最佳解决方案，那就是把这个文件，放到配置类中去，这下对称规则也满足了，代码行数也下降了，而且程序架构更合理了。

代码review的心得相关推荐

由学习《软件设计重构》所想到的代码review（二）
前言对于一个程序员来讲如何来最直接的来衡量他的技术能力和产出呢?我想最直观的作法是看他的代码编写能力,就拿我经常接触的一些程序员来看,他们买了很多技术重构类书籍,但是看完后代码编写能力并没有显著提高 ...
如何有效地进行代码 Review？
研发都知道代码 Review 的重要性,在腾讯代码 Review 也越来越受大家重视,作为腾讯专有云平台研发的一员,我参与了大量的代码 Review,明显地感受到有效的代码 Review 不但能提高代 ...
代码review，瑞出事来了！
不久之前,部门进行了一次代码评审. 代码整体比较简单,该吹B的地方都已经吹过了,无非是些if else的老问题而已.当翻到一段定时任务的一步执行代码时,我的双眼一亮,觉得该BB两句了. 谁知这群家伙, ...
Gerrit代码Review高阶实战
Gerrit代码Review高阶实战 Gerrit代码Review高阶实战 Gerrit 是一个免费.开放源代码的代码审查软件,使用网页界面.利用网页浏览器,同一团队的程序员,可以相互审阅彼此修改后的 ...
Gerrit代码Review入门实战 1
Gerrit代码Review入门实战库代码审核 Android Gerrit 经验分享阅读23889 代码审核(Code Review)是软件研发质量保障机制中非常重要的一环,但在实际项目执行 ...
代码REVIEW的一般方法
代码REVIEW的工作是软件工程中不能忽视的工作,是软件质量活动之一,对保障和改善软件工程质量有比较明显的作用,特别是对团队进行开发的软件工程.本文主要以C代码的视角描述CODE REVIEW的一般方 ...
研发团队如何借助Gitlab来做代码review
代码review是代码质量保障的手段之一,同时开发成员之间代码review也是一种技术交流的方式,虽然会占用一些时间,但对团队而言,总体是个利大于弊的事情.如何借助现有工具在团队内部形成代码revie ...
如何进行代码REVIEW
一.代码REVIEW的利与弊软件工程中,最后都落实在代码的实现上,软件要运行的没有问题,除了软件架构和系统设计设计到位,代码实现也是至关重要的一部分,再好的设计如果软件代码实现有问题,软件也不能跑起 ...
java code review 工具_两款好用的代码Review工具 | 学步园
最近团队内部呼吁代码质量的声音越来越高,项目组引入了代码Review机制.上次我由于不了解主站URL替换的规则,险些造成客户端图片读取错误,而代码Review则有助于帮我们发现代码潜在的问题. 主讲的 ...

代码review的心得

代码review的心得相关推荐

最新文章

热门文章