值得花时间结对编程吗?

2020/08/04 技术管理 共 1917 字,约 6 分钟
拔菜集

每次我兜售「结对编程」,都会引起一些人的恐慌和惊诧:两个人一台电脑?一个人写代码另一个人看?!生产力岂不是减半了?万万不可啊!

果真如此吗?

这些人往往没有意识到:程序员写代码上的时间少得可怜。

能花 30% 的时间在写代码上的程序员就是顶级程序员了,同样的,能花 30% 的时间在写代码上的团队就是顶级团队了。

一定有人表示怀疑,那我们就来看看程序员的时间都去哪了?

写 bug

面对 30% 这么苛刻的数字,我们对「写代码」的定义也是严格的,那就是:写 bug 不算。

非但不算,还要倒扣。

什么意思呢?

假设我写了 10 小时代码,其中 3 小时写的代码是 bug,那我还有 7 小时,也就是 70% 的时间在真正地「写代码」啊。

不对,那个 bug 通常会引发很多事情,需要占用团队的时间,比如:

  1. QA 额外的测试时间,沟通 bug 的时间
  2. 修复的时间
  3. 回归测试的时间
  4. 发布 hot fix 的时间

这些时间如果花了 20 个小时,相当于 30 (而不是 10)个小时里,只有 7 个小时在真正「写代码」。

所以: 如果多花 3 小时用来结对编程提升质量,能省下这 20 个小时,还会认为结对编程是浪费时间吗?

读代码

面对遗留代码,每个程序员花在读代码的时间,远超花在写代码的时间。这是老生常谈的话题了。

我们姑且认为,为了理解原有代码,读代码的时间也是写代码的一部分。(不然定义顶级程序员的数字就不是 30% ,可能是 10% 了)

但是这件事给我们的启发应当是,

写代码是一把双刃剑,产生价值的同时,也在产生成本。

就算是没有 bug ,它也在产生后续「读代码」的成本。

所以: 多花几小时提高代码的可读性,节省的是后续读代码时读到骂娘的大量时间,何乐不为?

知识的传播

我们大量的时间都用在「知识的传播」上。

这有点抽象,举几个例子:

  1. 团队开需求会,产品经理把需求说了又说,无非是让需求这个知识传递给程序员。
  2. 程序员把对需求的理解抽象成设计,然后写成代码,无非是把知识传递给编译器。
  3. QA 把需求传递给测试用例
  4. 编译好的软件传递给 QA 去验证。

这些步骤,包含着知识在团队成员之间,以及人和工具之间的无数的沟通和传递。

传递那一霎那花的时间是很少的,花时间的是为了传递而需要的沟通。

所以: 写代码只是简单的享受,难的是敲键盘之前的,对需求和设计的深思。你不让程序员结对,他们各自也在对着电脑冥思苦想(发呆)。

从这个角度,结对没有浪费时间,而且至少能让他们把心里所想快点跟对方说出来;免得一个人想了一天,思绪不知偏到哪去了也不知道。

说的理论一点:结对编程提供的「实时反馈」,是节省总时间的最佳手段。

学习

「知识的传播」属于学习 known unknowns;

而这边的「学习」,强调的是 unknown unknowns。

对软件行业的一个思维的误区是「线性思维」,以为我们要解决的问题是已知的。

启动一个产品时,桌面上铺满了 100 个待解决的问题,好,让我们用 1 年时间解决这 100 个问题。这就是线性思维。

非线性思维是:这 100 个待解决的问题,在未来的 1 年里,可能有 40 个仍旧要解决,剩下 60 个不再是需解决的问题;而且,还会冒出来另外 80 个要解决的问题。

那 80 个不能在一开始就知道的问题,和那 60 个不能在一开始就确定要不要解决的问题,就是 unknown unknowns。

一个产品的成功与否,不在于启动之初的那 100 个问题是否如期被解决,而在于团队多快可以识别出 60 个伪问题,多快可以发掘出那 80 个未预见到的问题。

团队的核心能力之一,就是这种「把 unknown unknown 尽快转化为 known unknown 」的学习能力。

所以: 结对编程这件事,做好了有助于这种能力的提升;就算没有,盯着程序员的这点表面上的时间,实在是盯着芝麻无视西瓜,狗咬火车不懂科学。

唯一不该结对编程的场景

说了那么多道理,还是很多人对「结对编程」有不好的体验。

任何人都可以总结不适用「结对编程」的场景,而我的总结是两点:

  1. 没有配口香糖。
  2. 没学会「结对编程」。

TDD 不适合我们。 Scrum 不适合我们。 「结对编程」不适合我们。

这种句式,保守点 80% 的原因都不是 TDD/Scrum/结对编程 本身,而是:我不会。

「结对编程」是一项需要学习的技能,不是两个人坐在一起就可以自然发生的。

如果配了口香糖,也学会了这项技能,不知道还有什么不结对的理由和场景?

Pair everything

事实上,pair programming 很早以前就被扩展到 pair everything;

SAFe 里也把 Pair 当成通用的质量实践,不再限于技术团队。

还有,我读过的唯一一篇咪蒙的文章,是讲她怎么写公众号的: 她写文章时,不是一个人在写,而是在同事的注目下写。每句话写完,同事都可能给她最实时的反馈。

虽然不了解咪蒙,但这段话看得我不禁感慨:要做大 v,还是要有若干把刷子的。

文档信息

Search

    Table of Contents