从我上一份工作到这份工作，从结对编程开发文化到同行代码审查的转变是一次有趣的经历。我想我应该记录下我注意到的一些变化。你可以找到很多标题为/(pairprogramming|codereview)(pros|cons)/这种风格的文章，这些文章的作者可以给出清晰且令人信服的实施方案。我认为只要权衡利弊，这两种选择都非常有效。我想就两者之间的权衡策略提供一些相对客观的讨论。专有术语的定义因为术语“结对编程”和“代码审查”有许多完全不同的解释，所以让我在本文中首先定义这两个术语的含义。当我提到结对编程文化时，我指的是几乎100%结对的团队。实际上是2个开发者在屏幕前合作完成一个任务。一位开发人员负责运营，另一位负责指导。两位开发人员都参与了代码构建过程。每天的编程、开发工作就是与您的合作伙伴不断沟通。一旦团队（2名开发人员）完成任务，完成的代码将直接提交给所有者，无需进一步审查。当你在会议室盯着投影仪上的代码时，代码审查文化可以让团队思考很多问题——至少对我来说是这样。当然这不是我对代码审查的定义，这里我指的是借助自动化工具进行同行代码审查的过程。使用GerritPatchsets或GitHubPullRequests等机制，开发人员自己编写代码并将完成的代码提交给团队的其他成员进行审查。逐行注释用于对代码风格和代码功能进行质疑和注释。一旦提交被审查，它就会被提供给所有者。成功的先决条件这两种文化之间实际上有一些无可争辩的共性：扎实和持续的集成开发：基于每个任务构建流程漂亮的核心开发人员：这些家伙可以帮助提高代码库的质量并改进它的架构。代码质量的重要性：团队以及整个公司都了解维护高质量代码库的价值。持续的自组织：整个团队愿意定期评估并纠正和调整他们的开发过程。结对编程的乐趣接下来说说结对编程。这真的是一次很棒的体验，每个人都应该体验一下。您可以找到其他赞扬结对编程实践有效性的文章，但让我在这里简要总结一下。合作伙伴之间似乎有一个高速的沟通渠道，我们可以利用它作为一个团队受益匪浅。您可以将菜鸟开发人员与高手配对来训练他。因为核心开发人员可以在团队中快速传播最好的实践经验和技术知识。这样，新工具和技术自然会在整个团队中共享，并且每个人都会有所改进。两人结对编程可以分担日常工作的压力和精力。有时这些状态的起伏是相互的。当一个人在努力工作而另一个人分心时，保持健康可以帮助另一个人集中注意力。而当两个人同时高度专注的时候，那么工作效率一定是逆天的。他们可以相互依赖和信任。一个永远在一起工作的伙伴促进自我提升；每个人都想在他们尊重的人面前表现出色。而这个时候，我们往往更容易做出一些战略决策，也会带来更好的工作氛围：我们双方都不会轻易选择捷径，经常会在某个问题上进行取舍讨论。集体代码所有权的概念更容易被接受，因为代码至少由两个人完成。这些使整个团队能够以更积极的态度面对失败。结对编程是团队平衡的指标结对编程在一切顺利的时候看起来很美好，但它也是一头难以驾驭的野兽，需要被掌握。结对编程的效率能充分体现团队的均衡性。结对编程是培养新人的好方法，但过度稀释核心人才并将其分配给所有初级开发人员会破坏团队的生产力和氛围。当一个团队有太多初级开发人员时，这种情况会发生得更快，结对编程就变成了俄罗斯方块游戏。同样的平衡问题也会影响知识库。结对编程对于改进和重构以前的知识库非常有效。一旦建立新的图书馆或分馆，将增加配对和轮换的难度。团队需要不断发现类似的问题，并尽快改正。知识和人才的不平衡导致团队效率低下，更有可能破坏项目进度。结对编程文化滋生单一文化结对编程是一种比每个开发人员都更密集的实践。这意味着一个团队要采用结对编程，就必须招募喜欢在项目上与他人交流的开发人员。为了获得结对编程的好处，团队必须权衡利弊。招募球员的评价标准也是层出不穷。每个开发人员都应该问问自己，“我愿意每天坐在某人旁边和他一起编程和工作吗？”。这些问题对于构建和谐团队非常重要，但同时，这些问题也会在团队成员中造成表面的恐惧和偏见。永远不要聘请一个性格和背景与团队成员完全不同的开发人员，他很可能会破坏团队氛围。结对编程会帮助团队根据自己的兴趣构建统一的开发环境（包括开发工具、实践和开发技术），但也会让团队在开发的道路上走自己的路。促进科技行业的多样性一直是一项艰巨的任务，结对编程文化可以更容易地融入整个团队。结对编程不适合解决Hammock问题。结对编程有利于项目的持续发展和某些技术知识的共享，但不利于审慎决策和发挥创造力。只有在处理更大的系统架构设计问题时，我们才能做出这些谨慎的决定。尤其是当高手和菜鸟配对时，高手会在编程之前先做编程，而不是“浪费”时间和菜鸟交流。这会导致编程中的1+1<2。有时您需要代码审查。当使用结对编程的团队遇到上述问题时，核心开发人员开始怀疑他们合作伙伴的业务能力。也许在某个结对组中，两个开发人员都是菜鸟。渐渐地，团队之间就会出现信任危机，这意味着核心开发人员会觉得应该进行代码审查。因此，这种团队间的信任危机会严重影响结对编程的效果。代码审查的乐趣起初，我以为我会对代码审查文化感到非常不舒服，因为我已经习惯了结对编程文化。但事实恰恰相反，最初的经历让我如鱼得水。在代码审查中，没有人会看到您不完全满意的代码。保持良好编程风格的压力会激励开发人员，因为他们知道自己编写的代码最终会被其他人阅读。与结对编程相比，代码审查可以让开发人员深入思考问题。你可以花一个小时在你的房间里独自思考，出去寻找灵感，谷歌相关问题的背景信息，阅读相关的学术论文，或者做其他事情。这种自由度让开发者可以找到更多解决问题的方法，有利于代码构建的整个过程。在使用代码审查的团队中，您编写的代码不言而喻，因为您与同事沟通的主要渠道是您编写的代码。这使团队能够容纳更多个性迥异的开发人员，并提高招聘效率。你会喜欢和一个写出非常好的代码的困难的开发人员一起工作。代码审查是异步的，这带来了很多好处。首先，球队更容易灵活调整球员的工作时间表。如果开瓶器从早上5点到中午都能正常工作，那就太好了。如果另一个开发人员正在上夜校并且更倾向于加班，那很好。您还可以战略性地分配代码审查任务，以确保更多有经验的开发人员参与代码审查过程。这无形中提高了代码的质量，避免了项目出现漏洞。我还发现使用代码审查会让你更多地考虑你输入的价值。在结对编程的过程中，由于个人喜好或者强迫症，你会忽略很多代码细节。但是在codereview的过程中，你要判断你推荐给别人修改代码的意见是否合理可靠。我自己也有过一些坚持（放弃）建议的经历。希望以后能在这个版块记录更多我的感受。代码审查让你孤独结对编程文化和代码审查文化之间最明显的区别是你每天总是独自构建代码。对于某些人来说，这一切都很好。但对我来说，这是一个艰难的转变。当然，有很多方法可以避免孤独带给你的苦恼。比如和其他岗位的同事住在一起。经历过两种截然不同的社交方式，想看懂《remote work》这本书的论文《37种信号》，或许能对如何应对不同的社交方式给出一个答案。隐私与自我控制虽然你有动力在同事面前表现出色，但你是唯一知道自己每天在做什么的人。你可以出去四处游荡寻找问题的最佳解决方案，但你也可以闲逛和与人聊天而不做任何严肃的事情。与结对编程相反，代码审查不会对项目进度施加严格的规则。开发人员没有在固定时间范围内完成任务的压力。任务的进度完全在你的掌控之中。这可能会产生严重的后果。堆叠的codereview任务虽然由于codereview的异步性，有更灵活的项目调度时间表，但在某些情况下也会遇到执行瓶颈，比如每个任务都需要review，或者Coredevelopers做不来由于繁重的代码审查任务，他们自己进行了编程开发。在代码审查中，开发人员之间的交流缓慢且有限-在其他人编程时提出建议比审查完整代码要快得多。可以通过立即检查完成的代码来缩小这种速度差距。而缺乏经验的开发人员往往会陷入一些代码审查陷阱。“嗯，这似乎对我有用”总而言之，结对编程有助于开发人员在构建过程中进行沟通，而代码审查通常发生在任务构建之后，这有助于项目集成。代码审查需要审查者付出相当大的努力，这使得审查者对代码质量的要求相对宽松。哪个更好？我希望我已经介绍了结对编程和代码审查的优缺点，作为保持代码质量的一种做法。***最重要的是，团队对他们所做的选择采取务实的态度，因为这使团队能够诚实地了解执行的效果。一旦你意识到你的方法的缺点，你就可以改进它。如果你还没有解决以上问题，那就加入一个注重代码质量和项目进度的团队，在团队中尝试寻找解决这些问题的方法。原文：http://phinze.github.io/2013/12/08/pairing-vs-code-review.html作者：PaulHinze翻译：http://blog.jobbole.com/61349/译者：shao
