原文链接

结对编程系列

这篇文章主要是基于作者在开发与结对编程方面的丰富经验而提出的论点. 如果你想阅读关于科学研究结对编程的总结, 请查看的我们的这篇Scientific Research Into Pairing文章.

用三句话

随着时间的推移, 团队的产出会变慢, 因为他们积累了一些欠佳的代码, 而这阻碍了团队的进度.

一对程序员会倾向于写出比独立工作的程序员更好的代码.

经常进行结对编程的团队将更长时间地保持快速的产出速度.

用三段话

一个产出速度慢的团队总是一致产出慢, 因为他们正同一个欠佳的代码(codebase)作斗争. 这将花费非常多的时间来修复 bug 和回退, 然后发现你的代码变更以惊人的方式对整个系统都产生了影响, 需要深入探索才能够作出改变. 你可以写出将这些问题最小化的代码, 只是难度更大.

结对编程为这一挑战带来了更多的睿智的火力! 通过两双眼睛, bug 会被更早地被发现. 有了两个脑袋在头脑风暴, 能够找到更多的创造性的解决方案. 一个人在一直观察, 可以少走一些弯路(也可以少分一些心).

通过结对编程来投资高质量的代码, 可以带来更好的代码库(codebase), 从而使未来的开发工作能够更快的进行.

用三小节

到底是什么拖慢了开发速度?

解答这个问题的最好方式, 就是看看产出速度慢的团队花了这么多时间做了什么事:

  • 回退. 慢的团队经常在无意中破坏了之前正常工作的特性.
  • 修复新 bug. 慢的团队无法覆盖新功能中的所有边界情况, 而是在已经"完成"工作后, 生产环境中才发现它们.
  • 对抗坏的架构. 慢的团队在不稳定的基础上进行构建. 当发现架构不好时, 他们不会咬紧牙关去修复它.
  • 重写. 慢的团队发现他们的项目质量到了一个"理解和改变比扔掉一切重写"的水平.
  • 分散注意力. 慢的团队经常被会议和社交媒体分散注意力.

结对编程如何帮助解决问题?

  • 回退. 回退是可以通过一个测试套件(test suite)来预防的. 多数人都知道他们应该写测试, 但是他们没有坚持这样做. 在结对编程中, 测试的水平会趋向于两位参与的开发者的最大值.
  • 修复新 bug. Bug 往往隐藏在未被考虑的边界情况中. 在结对编程中, 一位开发者明确地负责思考这些边界情况, 而另一位开发者负责打字, 这增加了边界情况被正确处理的机会.
  • 对抗坏的架构. 当每个架构上的决定都由两个人共同考虑时, 团队倾向于找到优秀的解决方案.
  • 重写. 这仍然有可能会发生, 但如果有了更高的质量, 在必须重写前它能够撑得更久.
  • 分散注意力. 没有什么比一个你桌子旁的人, 更能够改变你刷 Twitter 的习惯了.

咋开始呢?

查看我们的指导: 你的第一次结对.