原文:http://coolshell.cn/?p=1302 酷壳
Code Review中的几个提示
陈皓
Code Review应该是软件工程最最有价值的一个活动,之前,本站发表过《简单实用的Code Review工具》,那些工具主要是用来帮助更有效地进行这个活动,这里的这篇文章,我们主要想和大家分享一下Code Review代码审查的一些心得。
首先,我们先来看看Code Reivew的用处:
- Code reviews 中,可以通过大家的建议增进代码的质量。
- Code reviews 是一个传递知识的手段,可以让其它并不熟悉代码的人知道作者的意图和想法,从而可以在以后轻松维护代码。
- Code reviews 也鼓励程序员们相互学习对方的长处和优点。
- Code reviews 也可以被用来确认自己的设计和实现是一个清楚和简单的。
你也许注意到了在上面的Code Reivew中的诸多用处中,我们没有提到可以帮助找到程序的bug和保证代码风格和编码标准。这是因为我们认为:
- Code reviews 不应该承担发现代码错误的职责。Code Review主要是审核代码的质量,如可读性,可维护性,以及程序的逻辑和对需求和设计的实现。代码中的bug和错误应该由单元测试,功能测试,性能测试,回归测试来保证的(其中主要是单元测试,因为那是最接近Bug,也是Bug没有扩散的地方)
- Code reviews 不应该成为保证代码风格和编码标准的手段。编码风格和代码规范都属于死的东西,每个程序员在把自己的代码提交团队Review的时候,代码就应该是符合规范的,这是默认值,属于每个人自己的事情,不应该交由团队来完成,否则只会浪费大家本来就不够的时间。我个人认为“meeting”是奢侈的,因为那需要大家在同一时刻都挤出时间,所以应该用在最需要的地方。代码规范比起程序的逻辑和对需求设计的实现来说,太不值得让大家都来了。
10年前,上面这两件事会是理所当然的(10年前的中国的软件开发还没有Code Reivew呢),今天,在中国的很多公司上面这两件事依然被认为是Code Reivew最重要的事,所以,我能够看到很多开发Team抱怨Code Review就是一个形式,费时费力不说,发现的问题还不如测试,而评审者们初了在代码风格上有些见术,别的也就没什么用了,长而久之,大家都会开始厌烦这个事了。
所以,在今天,请不要把上面的那两件事分散了Code Review的注意力,取而代之的是,对于Bug,程序的作者要在Review前提交自己的单元测试报告(如:XUnit的测试结果),对于代码规范,这是程序作者自己需要保证的,而且,有一些工具是可以帮你来检查代码规范的。
当然,上述这些言论并不是说,你不能在Code Review中报告一个程序的bug或是一个代码规范的问题。我只是说,那并不是Code Review的意图。
下面是我们认为的几个小提示可以让你更好进行Code Review这项最有价值的活动。
1.- 经常进行Code Review
以前经历过几个相当痛苦的Code Review,那几次Code Review都是在程序完成的时候进行的,当你面对那近万行的代码,以前N我掺和在一起的功能,你会发现,整个Code Review变得非常地艰难,用不了一会儿,你就会发现大家都在拼命地打着哈欠,但还是要坚持,有时候,这样的Review会持续3个小时以上,相当的夸张。而且,会议上会出现相当多的问题和争论,因为,这就好像,人家都把整个房子盖好了,大家Review时这挑一点那挑一点,有时候触动地基或是承重墙体,需要大动手术,让人返工,这当然会让盖房的人一下就跳起来极力地维护自己的代码,最后还伤了团队成员的感情。
所以,千万不要等大厦都盖好了再去Reivew,而且当有了地基,有了框架,有了房顶,有了门窗,有了装修,的各个时候循序渐进地进行Review,这样反而会更有效率,也更有帮助。
下面是一些观点,千万要铭记:
- 要Review的代码越多,那么要重构,重写的代码就会越多。而越不被程序作者接受的建议也会越多,唾沫口水战也会越多。
- 程序员代码写得时候越长,程序员就会在代码中加入越来越多的个人的东西。 程序员最大的问题就是“自负”,无论什么时候,什么情况下,有太多的机会会让这种“自负”澎涨开来,并开始影响团队影响整个项目,以至于听不见别人的建议,从而让Code Review变成了口水战。
- 越接近软件发布的最终期限,代码也就不能改得太多。
我个人的习惯,并且也是对团队成员的要求是——先Review设计实现思路,然后Review设计模式,接着Review成形的骨干代码,最后Review完成的代码,如果程序复杂的话,需要拆成几个单元或模块分别Review。当然,最佳的practice是,每次Review的代码应该在1000行以内,时间不能超过一部电影的时间——1.5小时(因为据说那个一个正常人的膀胱可以容纳尿液的最长限度)
当然,在敏捷开发中,他们不需要Code Reivew,其实,敏捷开发中使用更为极端的“结对编程”(Pair-Programming)的方法 —— 一种时时刻刻都在进行Code Review的方法,个人感觉在实际过程中,这种方法有点过了。另外,大家可以看看本站的另一篇文章《结对编程的利与弊》来了解一下这种方法的问题。
2.- Code Review不要太正式,而且要短
忘了那个代码评审的Checklist吧,走到你的同事座位跟前,像请师父一样请他坐到你的电脑面前,然后,花5分钟给他讲讲你的代码,给他另外一个5分钟让他给你的代码提提意见,这比什么都好。而如果你用了一个Checklist,让这个事情表现得很正式的话,下面两件事中必有一件事会发生:
- 只有在Checklist上存在的东西会被Review。
- Code Reviews 变成了一种礼节性的东西,你的同事会装做很关心你的代码,但其实他心里想着尽快地离开你。
只有不正式的Code Review才会让你和评审者放轻松,人只有放松了,才会表现得很真实,很真诚。记住Review只不过是一种形式,而只有通过相互的讨论得到了有意义和有建设性的建议和意见,那才是最实在的。不然,作者和评审者的关系就会变成小偷和警察的关系。
3.- 尽可能的让不同的人Reivew你的代码
这是一个好主意,如果可能的话,不要总是只找一个人来Review你的代码,不同的人有不同的思考方式,有不同的见解,所以,不同的人可以全面的从各个方面评论你的代码,有的从实现的角度,有的从需求的角度,有的从用户使用的角度,有的从算法的角度,有的从性能效率的角度,有的从易读的角度,有的从扩展性的角度……,啊,好多啊,还让不让人活了。不管怎么说,多找一些不同的人会对你很有好处。当然,不要太多了,人多嘴杂反而适得其反,基本上来说,不要超过3个人,这是因为,这是一个可以围在一起讨论的最大人员尺寸。
下面是几个优点:
- 从不同的方向评审代码总是好的。
- 会有更多的人帮你在日后维护你的代码。
- 这也是一个增加团队凝聚力的方法。
4.- 保持积极的正面的态度
再说一次,程序最大的问题就是“自负”,尤其当我们Reivew别人的代码的时候,我已经见过无数的场面,程序员在Code Review的时候,开始抨击别人的代码,质疑别人的能力。太可笑了,我分析了一下,这类的程序员其实并没有什么本事,因为他们指责对方的目的是想告诉大家自己有多么的牛,其实,靠这种手段来表现自己的程序员,其实是就是传说中所说的“半瓶水”。
所以,无论是代码作者,还是评审者,都需要一种积极向上的正面的态度,作者需要能够虚心接受别人的建议,因为别人的建议是为了让你做得更好;评审者也需要以一种积极的正面的态度向作者提意见,因为那是和你在一个战壕里的战友。记住,你不是一段代码,你是一个人!
5.- 学会享受Code Reivew
这可能是最重要的一个提示了,如果你到了一个人人都喜欢Code Reivew的团阿,那么,你会进入到一个生机勃勃的地方,在那里,每个人都能写出质量非常好的代码,在那里,你不需要经理的管理,团队会自适应一切变化,他们相互学习,相互帮助,不仅仅是写出好的代码,而且团队和其中的每个人都会自动进化,最关键的是,这个是一个团队。
(请勿用于商业业用途,转载时请注意作者和出处)
相关推荐
而CodeReview宏则进一步提升了其在团队协作和代码审查中的效率。 **CodeReview宏的主要功能**: 1. **代码评审**:CodeReview宏允许开发者在Source Insight中直接进行代码评审。它可以标记出待审代码,记录评审...
Code Review是软件开发过程中的一个重要环节,它有助于提高代码质量,发现潜在的错误,以及确保团队成员间的代码风格一致。本文将详细介绍两款Eclipse插件——Jupiter和Reviewclipse,它们是进行Code Review的有力...
一个很方便的功能是其建立了review问题跟具体源代码的对应关系(通过点击review问题列表中的问题可以跳转到对应的代码段,通过点击代码段上的review问题标记可对应到具体的问题描述),review问题列表支持各种filter...
CodeReview工具的作用:1.减少评审人的缺陷记录和汇总时间,方便责任人查找问题出处;2.检视完成后生成检查报告,代码作者点击按钮可以直接找到错误处;3.任务责任人修改完成后,直接修改问题状态,组织者按快捷键...
Employing lightweight, tool-based code review of code changes (aka modern code review) has become the norm for a wide variety of open-source and industrial systems. In this paper, we make an ...
在实际使用中,下载的压缩包文件"IntellijIDEA-CodeReview-Plugin-master"包含了插件的源代码,开发者可以对其进行定制或扩展以满足特定团队的需求。安装插件通常包括以下几个步骤: 1. 解压下载的压缩包。 2. 打开...
在Redmine中,Code Review插件是一个重要的扩展,它致力于帮助开发团队进行代码审查,提升代码质量和团队协作效率。本文将详细介绍如何使用Redmine的Code Review插件。 首先,安装Code Review插件是必要的步骤。...
Code Review 是一个非常重要的步骤在软件开发过程中,特别是在开源项目中。通过 Code Review,可以确保代码的质量和可维护性。在 GitHub 上,Code Review 是一个非常流行的实践,它可以帮助开发者提高代码质量,减少...
我一直认为CodeReview(代码审查)是软件开发中的最佳实践之一,可以有效提高整体代码质量,及时发现代码中可能存在的问题。包括像Google、微软这些公司,CodeReview都是基本要求,代 我一直认为CodeReview(代码...
`CodeReview.em`可能是一个包含了代码审查过程记录或结果的文件,而`codereivew.docx`可能是详细的代码审查报告,其中可能详细列出了审查过程中发现的问题、建议的修改以及后续的行动计划。通过这两个文件,团队成员...
静态测试方法之代码审查(CodeReview)的清单。代码审查可以帮助提高代码质量,避免由于代码习惯而造成的bug。下面列出的这些要点因该可以作为大部分代码审查的指导,如果是Java应用的话,这些建议应该被视作最佳实践...
### CodeReview中的常见代码问题分析 #### 一、引言 在软件开发过程中,CodeReview(代码审查)是一项至关重要的活动。它不仅有助于提高代码质量,还能促进团队成员之间的知识共享和技术交流。本文将深入探讨Code...
code review(程序员必看)code review(程序员必看)code review(程序员必看)
代码审核,是对应用程序源代码进行系统性检查的工作。它的目的是为了找到并且修复应 用程序在开发阶段存在的一些漏洞或者程序逻辑错误,避免程序漏洞被非法利用给企业带来不必 要的风险。
C++代码 Code Review时使用的检查清单和问题记录模板
zyh-code-review.rarzyh-code-review.rarzyh-code-review.rarzyh-code-review.rar
source insighet 集成code review,代码审核时非常好用,使用起来比较简单,加入工程,同步,添加快捷键,使用快捷键即可正常使用,保存即可。
根据给定的文件信息,我们可以提炼出关于代码审查(Code Review)及其在谷歌开发流程中的应用的关键知识点。 ### 什么是代码审查? 代码审查是一种软件工程实践,其中一名开发者编写代码后,由另一名开发者进行...
漫谈codereview,关于review的一些基础知识和总结。
Steven Code Review 2009.12M1发布包.rar 代码在线审查工具 @date: 2009-12-28 @author: YF @email: yifi@tom.com 功能: 1 方便学员学习教师的代码,无需在本机运行IDE即可以代码加亮的方式查看服务器共享的代码...