微信扫描登录
或者
请输入您的邮件地址来登录或者创建帐号
提 交取 消
GITBOOK.CN需要您的浏览器打开cookies设置以支持登录功能

庄表伟:关于Code Review的真命题和伪命题
作者:Chat 实录

12月20日周二晚8点30分,华为公司内源社区平台架构师、开源社理事庄表伟带来了此次交流的主题“如何实践Code Review”。以下是主持人赫阳整理的问题精华,记录下了作者和与会者之间问答精彩片段。


问:请问作者对Pair Programming怎么看?适合国内的环境吗?

答:我的想法,可能有朋友不太同意。我认为,结对编程,是一个会被逐步边缘化的实践。而恰恰是code review这样的模式,会长存下去。总体来说,我认为在开发过程中的交流,应该是“异步”的,而非“同步”的。比如:一群人坐在一起开会,就同时花费了一群人的时间。大家回复邮件,就是各自异步的,自由的。借助工具的帮助,code review也是异步的。而结对编程,则是同步的。

所以,不是是否适合国内环境的问题,我对结对编程的前景...


问:1) 我们公司也是导入了review系统,但是有些项目组review活动流于形式。觉得review是累赘,反正有测试进行测试,也就忽略了review环节。形式大于了效果。
2)对于review意识薄弱的项目leader和工程师该如何引导他们? 如何评估review的有效性?
3)如何避免因为没时间导致code review不深入或者流于形式?

答:这三个问题其实都是关于“如何避免形式主义”,或者说,由于缺乏主动意识导致形式主义的问题。在我写的那篇文章里,谈到一个“寻找试点团队”的问题,这个非常关键。我们需要找到一个有追求的团队,首先来示范Code Review带来的价值。

再贴一下我之前的文字:

  1. 工作不算太忙。因为,在过于紧张的进度压力之下,刚刚开始的code review实践,很容易流于形式,最后不了了之。
  2. 大多数成员,认可这一实践。或者换言之,这得是一个有追求的团队。
  3. 至少有20%以上的,经验丰富的老手。如果纯粹是一群新手,所谓的code review,也不过是一场游戏。
  4. 人数不能太少,虽然三五个人的小团队,也非常适合code review,但是:对于在公司内部推广来说,太小的团队应用code review收到的效果不会太明显。10~20人的团队,是一个比较合适的规模,当然,人太多也会有各种问题。

有几个关于试点团队的细节,这里可以再讨论下。

  1. 通常而言,试点团队因为选择得当,一般都能够获得比较满意的效果。但是,这样的效果,如何能够在更大的范围内推广,这是一个很困难的问题。比如说:试点团队对于自身经验的充分总结,就非常关键。在推广者而言,他的“推销词”是外人的说法。而在“亲历者”的经验分享出来的,则是“自己人”的说法。
  2. 试点经验的总结,当然是需要向更高级的领导做一个汇报的。这个汇报,需要包含两部分的内容:一是效果,二是需要的支持。如果仅仅是报喜,让领导误以为,只要全面推广,就能够获得更大的收益,那就可能坑了其他的团队了。因此,需要阐明各种实际的困难,让领导意识到,更大范围的推广,他也需要提供更大力度的支持(要付出些什么的)
  3. 试点团队的实践,在更大的范围推广时,难免会遇到“动作走样”的问题,这种情况,只能不断的观察、总结、及时的考虑如何应对了。

问:是不是可以这样理解:团队成员(新手、老手)、系统、管理层三方如何来互相协调控制,从而达到自洽的稳定状态?

答:在上一篇文章《聊聊提交代码这些事》里,我曾经总结过:人、工具、流程,是三要素。不仅仅是Code Review,几乎在任何的组织管理领域,都无非是这三要素。从某种意义上类比,我们可以建立类似于网站监控这样的反馈系统,来分析当前的系统状态,看看是否(正常、合理、自洽、稳定)。但是,具体的观察入手点,应该分析哪些数据,则是非常困难的问题。


问 :1)没有量化数据,就很难管理、改进。REVIEW的困局:我如何证明有效性、如何改进、以及和其他手段(单元测试)的比较。在精益化、智能化的今天,有什么手段没?
2)团队做code review 很多时候是为了提升质量,如何在code review过程中有效发现问题,这点上有没有相对科学的方法适用于大部分团队。

答:我想聊聊关于量化、评估方面的问题,以上这两个问题非常有代表性。可能有很多朋友,都会比较反感一个词,叫做KPI。在我看来,KPI最大的问题,在于预设结论。

我们举个例子来说:一个系统100万行代码,通过测试发现100个缺陷,于是可以得到一个缺陷率是0.1每千行。那么,这个0.1的数值,到底是好,还是不好呢?再者,如果这个团队通过改进,将缺陷率从0.1降低到了0.05,是不是就更好呢?也许,从另一个角度来说:会不会是测试的人员没有以前用心了呢?

再举个例子来说:一个Code Review的过程,当然需要有人参与讨论,那么1个人发表了1个评论与10个人发表了20个评论,哪一个更好呢?是不是参与讨论的人,越多越好呢?在我看来,针对一个复杂系统,应该尽可能的收集更多类别的数据,并尝试从多个角度,去解读这些数据。但是:不要急于下结论。或者说,针对目前的Code Review状况,我们能够统计出100种不同的特征数据。但是从这些数据中,能够看出哪些问题,则是非常考究功力的事情。在这一句之前,再加一段:“通常,我们需要具备深入数据、返回事发现场、鉴别数据背后的真相的能力。”


问: Code Review 工具的使用有没有更详细一点的说明?Code Review是正式会议么,推荐的流程是什么?

答:在我看来,Code Review是与代码提交流程紧密相联的。因此,需要寻找与配置库管理工具,紧密集成的工具。逻辑上来说,我们希望一个工具能够在代码提交的过程中充当一扇门的角色,站在这扇门前的是一个一个的Committer。由他们来决定是否允许某一次代码提交,进入主干。这个过程,如果是工具支持的,那么很简单:只需要Committer在自己的电脑前,点击某个按钮,就完成了。不需要开会。

我的文章里写的:Gitlab、Gerrit、Phabricator都是不错的选择。另外,还漏了一个VSTS,微软的一个工具,也有Code Review。要点在于这个工具能够帮助团队,在代码提交合入主线之前进行review,一定不是事后review!其实,Github也是不错的选择。小团队可以直接在Github上使用,有钱的也可以在公司内部购买部署Github企业版。

关于工具,我的建议是:先用起来。至于A工具与B工具,哪一个更好,对于尚未养成Code Review习惯的团队而言,是一个伪命题。


问:对于前端开发的Code Review实践有什么好工具和经验分享吗?和后端CR的区别在哪里?移动iOS的端的Code Review有什么好的实践工具及流程?

答:我没有觉得。特定的领域需要有特定的CR工具或实践。或者说,只要是能够被review的代码,某种特定的语言能高亮就可以了。当然,也可以换一个角度来回答一个相关的问题:“Code Review应该review些啥?”我的文章里,其实也写到了这个方面,首先是努力“看懂”代码。如果看不懂,就提出review意见。其次是执行全员认可的代码规范。最后,是尝试发现各种潜在的问题。


问: Code Review感觉有些像项目管理中全员参与的PDCA循环呀……是一个软件开发项目持续改进的手段吧?作者怎么理解二者的关系?

答:顺便来说说这两者之间的关系。

enter image description here

这个图中的PDCA,究竟代表什么含义,是不是能够提升某某领域的质量,其实并不是很重要。核心在于:这是一个反馈循环。这个反馈循环,告诉我们:做一件事,能够通过不断的总结反思,进而精益求精。

在Code Review的领域,最为重要的实践目标,在我看来是形成“团队共识”,这个共识,是需要不断讨论、提炼、总结、修正的。这就是我写的那句很绕的话:在实践Code Review的过程中,我们还应该定期“Review”这个活动本身。Code Review能够改进代码质量。过程Review,能够不断的改进Code Review。随着不断的总结团队共识,一次Code Review应该检查哪些内容,应该发现哪些问题,就会被明确下来成为一个CheckList。

另外需要强调一下的是:CheckList,不是越长越好,这里面有一个“边际收益递减”的规律。

问:我曾经做过一段时间信息系统工程监理,监理是基于项目管理而言的,但对于软件开发项目,一般很难受控呀……

答:的确很难受控,或者说,需要付出很大的努力才能控制住。

问:在我们的团队,Review的Checklist会被要求自动化。

答:你们的团队,自动化程度太高了!

Jeff Wang:自动化可以解决80%的部分,质量管理没法完全脱离人工的。


问:能否用一种快速的方式验证处出代码的一般问题,另外是不是必须review的人水平要比被review的人水平高很多呢?

答:在我的文章里,提到过工具检查的作用,的确可以辅助Code Review,但是:人才是最终做出review决定的人。另外,review的人,是不必水平高很多的。人人皆可围观嘛。但是:我们认为Committer(决定代码是否能够合入的人),应该是团队内部水平最高的20%。


问:评审是为了控制代码质量,如果没有一个很好的把关者,不但会流于形式,还可能会使不明就里的人效仿错误的代码,commiter就成了一个关键的角色。

  • 代码复核的重点是什么?
  • 如何保证代码复核的质量?
  • 代码复核的最优阶段是什么?
  • 团队中如何做,谁来做代码复核合适?
  • 代码复核工具如何能避免沦落成走形式?
  • 代码复核后的问题如何确认解决?再次复核?尤其是性能等

答:在我看来,代码检视的目标肯定是为了提升代码的质量。但是我们并不能指望他发现所有的问题。

或者换句话来说,我们可以认为这是一个边际收入递减的问题。我们投入了代码检视的人力,然后让他检查出,各种可能的质量问题。相比我们的检查列表来说,在投入和产出相比划算的情况下。我们就可以继续做这样的,代码检查。其实我们还应该,区分代码检视当中的两种角色。一种是评论的人,而另一种则是决策的人。评论的人是不需要为代码的质量负责的,而决策的人需要看护代码的质量。确保代码评论的意见被落实,在我们的内部工具里,有code review 转 issue的功能。


问: 对于大型后端项目的重构(为了解耦啊,更好的扩展性啊,新增功能啊,等等等等),面对老的项目代码以及新增修改的代码,应如何通过code review保证代码质量和交付时效。

答: code review是一种过程手段,首先确保重构成功的,还是充分的测试用例。然后,对于重构的方案,先review,可以叫做doc review。在大家都对重构的方案达成共识的情况下,code review才会生效。

所以,次序是这样:高手的经验 -> 团队的共识 -> 自动化的规则。在检查规则自动化之后,团队才能够花费更多的精力,去发现更加深层次的问题。


问:如果公司没有引入Code Review工具,我们想轻量地进行Code Review 操作思路是什么?

答:说服公司,引入Code Review工具,没有工具,很难搞。


问:做Code Review是否要结合业务逻辑去做,还是仅仅去做编码规范的检查,如果做业务逻辑的Review,那和白盒测试有什么样的不同,是否检查的耗时很长,是否会影响正常的产品发布速度?

答:借用刚刚我收到的意见:“代码逻辑和业务本身是review的重点,其他尽量交给自动化工具”,我很认同。但是,我还想补充一句,在团队达成共识,并且养成足够好开发习惯之后(不会犯太多低级错误),再引入自动化工具比较好。


问:作者在实践中有没有具体的统计数据,比如代码从提交到 review 的平均时间,使用 review 前后项目质量的比较。还有 review 一般有哪些检查点?

答:这些数据我们内部的确是有的,各个团队,都在统计自己的数据。我们作为内部的研发平台,提供了一组公开的API,供他们获取自己的数据,然后自己做各种统计报表。

展开说:一方面是不便透露具体的数据,另一方面,我也不认为:某种特定的指标,可以用于跨团队之间的比较。或者说,很多指标的最大作用,是团队自身,做前后对比。而不是:做横向对比。


问:在一个有很多外包人员的项目,committer本身确认代码可能都有些问题,团队一起review的时间点怎么选择两周一版本(敏捷项目)有其他好的方式进行吗?如果一定要会议,会议的频率和时间有什么建议?补充背景 : 敏捷项目,两周一个版本,很多外包人员构成。committer本身确认代码能力有限,目前团队以会议形式review。

答:聊聊会议形式的review吧,总比没有好,对吧。如果要开一次review的会议,会前准备工作,非常重要,能否挑选足够的典型性的问题,进行全员普及教育,是会议成败的关键。

会议的频率,取决于你发现典型问题的频率。会议的时间长度,取决于你开会的讨论深度,与参会者的接受度。


问:用类似redmine这样的管理工具做code review有什么缺点?可以把code review直接转成问题,感觉也很好用。IDE的一些插件工具,比如 findbugs,checkstyle这样的工具是否是有价值在团队中推广的?

答:实话说,redmine+review board,也是一直选择,不过有些“落伍”。当然,还是前面那句话,较之选择何种工具,更重要的是review起来。IDE的一些插件工具,自动化的检查工具,都很有价值。但是:前提是:团队成员要先认可那些检查规则。如果在团队内部尚未任何某一种工具的情况下,推行自动化的检查工具,会起到反作用。很多人会吐槽工具:毫无意义,弱智,误报,浪费时间。

Chat文章:《如何实践Code Review?》


在此感谢图灵公司,为本场Chat的获奖者提供了以下书籍。

enter image description here


enter image description here

enter image description here