一文趣说 Code Review 与结对编程之优劣

这篇文章的起因是在“敏捷中国史”交流群群里的一个争论,我希望能够通过这篇文章说明自己的一个观点:相对于结对编程,Code Review 是一种更加合理与普适性的研发实践。

背景情况介绍

基于变更的 Code Review 按照维基百科的定义,结对编程也是 Code Review 的一种形式。所以,当我想要把Code Review与结对编程对立起来的时候,实际上是指一种更加特定形式的 Code Review。在GitHub上,这样的形式非常流行,甚至不需要再做更多的说明。在维基百科上,这一类型被称为正式的基于变更的代码审查(Regular change-based code review)。除了Github 的 Pull Request,还有由 Gerrit 支持的基于 Changeset的模式。

后续为了比较,我将会展开一些具体的实践细节。

结对编程 这可能是众多敏捷软件开发方法中,“极限编程”区别于“其他敏捷”最大的一个特征。或者说,其他的那些敏捷方法中,已经不再强调必须结对编程了。按照维基百科上展示的一些研究成果,结对的好处有以下一些:

  • 更好的设计与更好的代码
  • 有助于团队内成员互相学习(尤其是老手带新手的情况下)
  • 不太会忘记编写单元测试,花时间上网或处理个人电子邮件,或偷工减料
  • 相比一个人工作,2个人结对工作时,更加不容易被人打断

围绕结对编程的一些争议

事实上,结对编程的好处,是否存在夸大,是存在争议的。

  • 有研究发现结对编程往往一定程度地缩短了开发时间,而且对代码质量产生了正的边际效益,但是结对编程大大增加了开发人员的工时;也就是说与单独编程相比花费大大增加了。[1]
  • 在简单的,程序员都完全了解的任务上,结对编程导致生产力的净下降。[2][3]
  • 还有研究者指出:有关结对编程的研究遭遇了发表偏倚,有些不利于结对编程的研究要么没有开展研究,要么没有投稿,要么没有被授权发表。

为何基于变更的 code review 会比结对编程更好?

一、提升代码质量

结对编程也能够提升代码质量,但是这个可能性是发生在结对的2个人身上的。也就是说,两个聊完了,代码写出来了。代码的质量也就这样了。

而一个人写代码,想要提交去被review的时候,可能看到代码的人,是不确定的。在开源社区,看到代码的人也许成千上万,这些人走过路过都可能会发表一些意见。即使是在企业项目、团队内部,这个代码也不仅仅是这个功能的Pair搭档能够看到。

所以,当一段代码,可能被走过路过的开发者,+1分或者-1分,甚至直接-2分的时候。他有可能会更加注重自己的代码质量。不仅仅是让自己的搭档看懂,更要让所有潜在的批评者看懂。

二、分享与传播知识

当然,结对编程也可以做到这一点,但是:这样的分享与传播,存在两个限制:一对一的交流,知识从A传到了B。C何时能够知道呢?除非是,某一天A与C结对,或者B与C结对,而且在结对过程中,正好聊到了这一话题。

第二个限制,是因为结对编程时的交流,往往是口头的。而基于变更的Code Review,各种评审意见,都是数字化且可以再检索的。这就使得后续的员工,想要学习组织的知识时,可以更方便的顺着代码,顺着提交记录与讨论记录了,了解到当时发生了什么。

三、工具性增强

因为基于变更的 Code Review 需要工具支持,所以我们也可以不断的改进工具,使得开发的过程不断得以优化。

  • 得分门禁:我们可以规定,一个变更只有得分超过N分,才能够被合入。而每个人最多只能+1或+2分。假设一个团队有20个人,我们可以规定得分至少超过5分。那么开发者至少需要找到团队内部的3个人看过并认可他的代码,才能够合入。这就像是分布式存储中的N备份策略。越是重要的数据,我们备份的数量越多,数据也就越安全。
  • 工具门禁:现在很多的CI工具,可以直接集成在Code Review的过程中,甚至以机器人的身份,直接参与打分。比如:XX测试不通过,直接-1分。再和上面提到的得分门禁配合起来。就能够对一次代码提交的质量,做出更加全面与深入的分析
  • 研发数据:以上这些开发行为所产生的数据,都会保存在一个Code Review的系统里。较之过去的开源社区完全通过Email文字交流。这些研发数据的结构化,可分析性变得更高了。我们也因此能够进行更加深入的分析,甚至用上某种机器学习的手段,帮助我们不断改进代码的质量。

较之无需任何工具就可以开展的结对编程,我相信:工具的力量会更加强大。

针对熊节观点的一个反馈意见

在微信群里,熊节提到了一个很有意思的观点:软件开发到底是一项科技活动还是一项社会活动?使用流程与工具,其实是假设了程序员不爱交流,也无法改变,所以要用某种工具来帮助他们。(大意如此)

在我看来,面对面的交流固然是交流,借助工具的交流同样也是交流。作为程序员,其实我们会更加偏爱简洁、高效,甚至结构化的交流,而不是低效的,容易产生歧义的“口头交流”。

从某种意义上来说,我是支持不断的发展与改进工具的,无论是开发工具,还是交流的工具,都有可能变得更好。

Talk is messy, the code is clear. :D

作者:庄表伟 链接:https://www.jianshu.com/p/cf6c953ebf0c 来源:简书

本文分享自微信公众号 - DevOps时代(DevOpsTimes)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-03-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏机器之心

线性模型已退场,XGBoost时代早已来

我对十五年前第一天工作的情况还记忆犹新。彼时我刚毕业,在一家全球投资银行做分析师。我打着领带,试图记住学到的每一件事。与此同时,在内心深处,我很怀疑自己是否可以...

14920
来自专栏学习日记

Golang Leetcode 687. Longest Univalue Path.go

更多内容请移步我的repo:https://github.com/anakin/golang-leetcode

7010
来自专栏Java架构-筑基

浅析spring——IOC 之 分析 bean 的生命周期

在分析 Spring Bean 实例化过程中提到 Spring 并不是一启动容器就开启 bean 的实例化进程,只有当客户端通过显示或者隐式的方式调用 Bean...

11500
来自专栏区块链大本营

必读!未来月薪10万的五大利器(三)

目前各类区块链项目大多是在自己的孤岛上单独存在,而跨链(Cross-chain Atomic Exchange)技术可以把这些孤岛连接起来。因此,跨链将是区块链...

7920
来自专栏程序员的知识天地

大牛带你打牢Python基础,看看这10语法

都说Python简单,易懂,但是有时候却又很深奥,许多人都觉的自己学会了,却老是写不出项目来,对很多常用包的使用也并不熟悉。学海无涯,我们先来了解一些Pytho...

11510
来自专栏wfaceboss

6.2 集合和映射--集合Set->底层基于链表实现

在6.1中我们实现了底层基于二叉搜索树的集合,本节就底层如何基于链表实现进行学习,注意:此处的链表是之前自己封装的.

11220
来自专栏学习日记

Golang Leetcode 697. Degree of an Array.go

更多内容请移步我的repo:https://github.com/anakin/golang-leetcode

9920
来自专栏数据的力量

数据分析师的算法推荐是否会陷入“真实的谎言”?

在这个时代,推荐引擎成了很多公司获得用户流量的利器,那请问一下,在机器学习进步如此神速的背景下,你收到的网站或APP的推荐,是否效果更好了呢?

13830
来自专栏Fundebug

JS常用正则表达式备忘录

正则表达式或“regex”用于匹配字符串的各个部分 下面是我创建正则表达式的备忘单。

23140
来自专栏Java架构-筑基

面试必备——关于Java ClassLoader你真的了解吗

类加载机制作为一个高频的面试题经常会在面试中被问到,前几天一个电话面试就问到,之前有了解过,但是没有梳理成自己的体系,所以说的有点凌乱,今天花点时间整理一下,分...

11700

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励