对于软件开发者来说，敏捷开发并不是一个新词。自 1990 年开始流行至今，敏捷开发已有近 30 年的历史。它因对需求响应迅速、注重团队沟通、可持续快速交付等优势令人称道，然而也有相当一部分人认为，不同成员间的协作可能会带来更多问题，使整个流程变得更加低效。关于敏捷开发的使用，始终存在很大的争议。
近日，移动互联网出海企业触宝的研发总监孟雷在出席 ArchSummit 全球架构师峰会 2019 深圳站 时提到，作为敏捷开发的方法之一，结对编程在国内仍是一个小众的软件开发方式，而触宝正是采用这一方法的少数企业之一。据了解，采用结对编程后，半年内，触宝电话在海量用户的前提下实现了高质量地从每月一个版本的发布周期逐渐提升至每周一个版本的快速迭代。同时，线上 P1 级 bug 数量减少至原来的 5%，代码架构、模块化程度以及团队都更加高效。所以，结对编程真的像传说中那样不具有可操作性吗？什么样的团队适合结对编程？结对编程会为企业与个人带来怎样的改变？
在 ArchSummit 全球架构师峰会 2019 深圳站，触宝研发总监孟雷发表了主题为《如何通过结对编程进行高质量的软件开发》的演讲，以下是 InfoQ 在大会期间对孟雷进行的采访全文：
InfoQ：您可以简单介绍一下目前在触宝负责的业务和具体开展情况吗？
孟雷：我在触宝目前主要负责触宝电话的相关业务。除了技术方面，还包括商业化以及增长推广的工作。我们在国内也正在孵化一些新的内容类 APP，具体也是由我负责。
InfoQ：我们了解到，您过去专注于敏捷开发。敏捷开发在国内有很大的争议，很多人说，国内做敏捷开发是为了“甩锅”，我们采用的敏捷开发并不是真正的敏捷开发。您认为产生这种误解的原因是什么？
孟雷：我平时和很多朋友的公司团队交流，在交流过程中，我发现比较常见的问题是大家对敏捷的定义往往过于表面。过于表面是说大家很容易就学到敏捷的一些形，这些形包括怎样组织文档，怎样开会，怎样把工作一个个拆分完成。这些资料市面上都有，大家就拿过来直接用了，但并没有思考这么做的原因。从某种程度上，大家还是在做瀑布式的软件开发，只不过是把一个相对长的瀑布的周期缩短成了一个相对短的敏捷的周期。在这个周期里，大家所做的事以及做这件事的思路和瀑布时代没有特别大的、本质的区别，这一点是大家比较容易进入的一个误区。之所以会出现这样的问题，我觉得主要原因在于，敏捷开发是一个舶来品，大家在过去几十年还是比较适应传统的软件开发方法。当这个舶来品来了的时候，人们很容易直接把它套进去，但并没有做深入的思考。
InfoQ：您说敏捷开发是一个舶来品，那么，结对编程也是舶来品吗？
孟雷：是的。为什么我会引入结对编程这个概念呢？其实严格来讲，结对编程也并不是一个非常新鲜的事物，很早以前就有人提出并实施了。目前，它的应用场景更多是在一些编程竞赛，或几十个小时的极限编程中，而真正把它推广到工程层面的人和公司都非常少。我为什么会发现它，并在一定程度上把它进行实践呢？我之前曾经在 EMC 子公司 Pivotal 工作，Pivotal 本身是硅谷一家特别极客、新锐的公司。我在公司接触到将近一千人，大家几乎全部是用结对编程的方式推进任务的，这在当时的业界非常少见，所以一开始我也不太理解。后来经过实践，我才发现，结对编程和敏捷开发是非常契合的。敏捷开发本身需要“小快灵”，但在“小快灵”的同时，又不能犯太多的错误。总结下来，我觉得结对编程是解决这个问题的非常好的思路。
InfoQ：您觉得结对编程主要适用于何种开发环境？国内团队可以在哪些情况下尝试结对编程？
孟雷：从我个人的体会来讲，如果大家真的有决心尝试它、使用它，其实它的适用范围是非常广的，任何公司和组织应该都是非常适用的。但是相对来讲，把结对编程落地这件事在国内还是比较少见的。我们可以在一些小团队，或者偏极客氛围的团队和公司先用起来，在局部取得比较好的效果后，再慢慢推广。
InfoQ：结对编程解决了工程或技术上的哪些难题？可以为企业或个人带来怎样的收益？
孟雷：通过结对编程的方式，我们可以在编写代码初期对它的架构、设计进行讨论，也可以更清楚地看到整个编写过程，更早地发现一些潜在的问题，尤其是设计上的问题。如果在设计阶段就能有一个比较好的处理，好过在测试阶段，甚至发布后，发现问题再补救，前者付出的代价要小得多，这就是结对编程为公司或项目带来的主要好处。对个人而言，它也是一个非常好的实践。我们可以将新老员工搭配，Senior 和 Junior 的人搭配，这样一来，Junior 的人的水平可以得到比较明显的提升。这是我的一个看法。
InfoQ：有人认为，结对编程对开发者的默契度要求较高，如果配合不好，反而会使整体效率降低。您如何看待这种说法？可以和我们分享一下您带领团队的经验吗？
孟雷：这个地方我需要澄清的一点是，结对编程并没有要求两个结对的人天生有什么默契。结对编程在实践时，为了取得比较好的效果，需要人员的不断轮换，所以它并不是固定搭配。在轮换的过程中，大家有不同的意见和想法都是非常正常，或者说非常正确的。因为在某种程度上，做结对本身就是要让不同的意见或设计理念进行碰撞和讨论，所以实际上我们并不指望大家有多么高的默契度。当然，当人们有太多的碰撞和讨论，甚至产生争议时，我觉得 Team Leader 要做的事情就是把握好一个度。一方面，你要让大家有适当的分歧和争论，因为这样才能保证代码写下去是大家共同接受的结果，而不是某一个人的想法。但另一方面，当争论过于激烈的时候，Team leader 要适时介入。你要去具体地看，讨论的到底是什么问题，这个问题的正确解法是什么，我们能不能达成一致，如果不能达成一致，可能就需要把它拓展到更大的范围，大家一起来讨论解决。
InfoQ：结对编程和普通开发模式下的编程，在团队管理上最大的区别是什么？
孟雷：最大的区别是，结对编程看待项目和人员的角度更加统一。无论是 Teamleader 也好，Team 成员也好，他们都会慢慢地通过结对编程对整个项目、整个编程的设计理念和方法有相对统一的认知。就像我前面所说的，在这一过程中，也会有一些争议和分歧，那么我们就要懂得如何在统一和分歧间把握好度。
InfoQ：您可以谈谈结对编程在企业中的普及情况吗？除了触宝之外，国内还有哪些公司也在采用这种方式？您还知道哪些比较前沿、极客的软件开发方式？
孟雷：据我所知，硅谷一些比较极客的公司在用结对编程。在国内，结对编程还属于比较小众的软件开发方式，使用它的公司相对较少。目前来讲，除了结对编程，业内大家谈论的比较多的可能就是 TDD 了，就是 Test Driven Development。我觉得这两者并不矛盾，TDD 更偏向于测试驱动开发，更强调测试。结对编程并不完全强调测试，而是更强调开发人员结对进行测试，测试力度也非常大。除了开发人员的互相保证之外，结对编程是靠一整套的持续集成和线上监控机制来确保软件开发的完整性的，所以我觉得两者可以有机地结合。
InfoQ：您刚刚说到测试驱动开发，现在有观点认为，开发也要懂测试，测试也要懂开发，运维也要做开发，开发也要做运维。您如何看待不同技术工种越来越趋向于融合的状态？未来会出现“独立的测试没有了，运维没有了”这种情况吗？
孟雷：根据我的经验，应该是不会的。尽管我们说，开发也要做些测试的工作，但就开发人员的工作重心与特性来讲，他们更适合做功能性的测试。所谓功能性的测试，是指我要做一个功能，这个功能自身是否完整，是否可用，这方面的测试由他们来做是比较合适的。但是当你把移动互联网的软件发布到线上，就会发现，除了功能测试以外，还有很多其他方面的测试。比如发布到安卓平台，安卓平台的碎片化特别严重，终端机型特别丰富，你就要把这些机型全部覆盖，那么仅靠开发人员就是不现实的。有时，很多 Bug 在小规模的集群或用户中是不会爆发出来的。这个时候，一方面我们要有更专业的压力测试。另一方面，有些问题真正到线上时，一定要通过数据运维的监控才能看到，这些相对就属于更专业的测试领域。如果开发人员花费更多的时间来做这些事，他个人的项目进度可能相应地就会受到一些影响。从这个角度来讲，粗略的工种分配还是会一直存在的。
InfoQ：我们了解到，您曾经推动建立了触宝电话的完整的研发测试流程，您是如何平衡软件交付与质量之间的关系的？
孟雷：一开始，我们迭代速度比较慢，又想向前快推的时候，遇到了很多问题。因为，当你想快推的时候，整个代码质量就会大打折扣。因此我结合之前的经历，推行了结对编程的方式，之后就发现它在某种程度上可以解决敏捷里面遇到的一些问题。它可以在整个过程中，既保证代码快速迭代，又保证高质量。至于效率问题，刚开始做这件事的时候，因为大家都不太熟，所以整体效率是会有一点降低，毕竟是两个人做原本一个人做的事。但当这件事执行一段时间以后，它就会处于一个相对稳定的状态，大家对这个模式熟悉之后，效率是会倍增的，相当于你写的每一行代码都经过完整的讨论和分析，所以它的质量更高，返工次数更少，后期花费的时间也更少。
InfoQ：结对编程会增加用人成本吗？
孟雷：严格来说是不会的。虽然是两个人在做一个人的事情，但相当于把后期的代码 review，交互测试等方面，两个人一起完成了。也就是说不像传统开发，写完代码以后还要做 code review，结对编程基本上是一次就过的。其实 code review 阶段，大家往往都比较忙，有时候也并不能真正做到有质量的 review，这样就会导致你前面埋的一些雷，到后期慢慢地爆发出来。所以像过去那样，有时质量也不好。两种方式比较起来，我觉得结对编程的效果是不错的。
InfoQ：触宝的技术团队在质量把控上有着怎样一套系统、完整、科学的方法流程？
孟雷：首先是采用结对编程写出质量较高的代码，同时我们专业的测试人员会做一些具有扩展性的，更系统的测试。同时，在正式发布后，我们相关的运维监控也会配套。做到从开发到测试到监控三方面的良好配合，从而达到比较理想的质量。
InfoQ：未来五年，触宝还将发力哪些前沿技术领域？
孟雷：过去，触宝主要做面向大众终端用户的一些基础性工具，比如触宝输入法、触宝电话。这种都属于比较小、轻的工具，整体的用户数量和规模都比较大。未来，除了工具，我们还要做很多新产品。随着用户数量的不断增多，结合触宝产品与用户交互的天然特性，后期我们会在大数据和 AI 方面持续投入。
嘉宾介绍：
孟雷，触宝个性化工具与内容事业部研发总监。曾先后就职于微软中国、EMC 中国，担任软件研发相关工作，专注于敏捷开发及分布式自动化测试的实践与团队管理。曾独立负责微软 SCCM 软件分发体系的测试，主导微软内部云测试和云部署服务 NOVA。在 EMC 任职期间成功推进 Pivotal 内部的敏捷开发转型，从零开始参与了 Pivotal Hadoop 的最初三个版本，并主导研发了适用于 Hadoop 系统测试的分布式测试框架 laphone。对于传统企业级软件如何进行敏捷研发的转型有丰富的经验。任职触宝期间，推动和建立触宝电话完整的研发测试流程，加速产品迭代，在保证高质量的前提下，实现了一周一发布的快速迭代周期，并培养了一大批精通移动互联网前后端、客户端开发的高素质研发团队人员。
评论