InfoQ|个实用的 Code Review 实践技巧，6 作者|AlejandroLujan本文最初发布于Sho

作者|AlejandroLujan
本文最初发布于Shopify博客，
经原作者授权由InfoQ中文站翻译并分享。
Codereviews是打造高效团队的重要方面，这已经成为共识。关于这个主题，有许多文章曾经讨论过，比如这篇论文——《AnEmpiricalStudyoftheImpactofModernCodeReviewPracticesonSoftwareQuality》。现实中，许多企业的无数团队都进行过某种形式的codereviews 。
而实际情况是， codereviews刚开始时，人们的激情高涨，之后， codereviews则流于形式，或者要么反馈不清晰、要么让人难以执行。长久以往，这让团队错失了加快学习、分享知识的机会，最终难以提高代码的质量。
在Shopify ，我们不仅立足长远，而且希望追求发展更快。以我们的经验来看，优秀的codereviews实践对工程师的成长和我们所打造的产品质量有着巨大影响。
噩梦般的编码经历这样一个场景相信很多人都很熟悉：
你刚刚加入一个新团队，领导很快给你分配了一个编码任务。作为新人，你特别想表现自己，因为你想秀一下自己的编码水平。于是，你接下来做了这些事：
你为了完成任务疯狂地敲了三周代码；
你将一个包含大约1000行新代码的PullRequest提交评审；
你收到两条关于codestyle的评论，以及一个关于评审人表示他看不懂这些代码用途的问题；
你修复codestyle并回答评审人的问题，然后评审人通过你写的代码；
【InfoQ|个实用的 Code Review 实践技巧，6】你把代码分支合并到Master ，双眼紧闭，紧握着拳头，紧咬牙关等待着结果。几分钟后， CI完成。幸好， Master没有崩溃。然而…
此后6个月，你一直战战兢兢，不知道代码何时会崩溃，以及以什么方式崩溃。
你可能经历过上述噩梦般的经历，那我们谈谈怎样改进这个流程吧！
实用的CodeReview实践在Shopify ，我们看重交付速度、学习以及长期发展。这些价值观虽然有时会产生冲突，但却引导我们不断尝试许多新技术，并推动团队变革。
我在本文总结了一系列Shopify内部使用的实用技巧。借助这些技巧，我们能交付经得起时间考验的有价值的代码。
术语说明：我们将PullRequests（PR）定义为合并到基础分支前进行codereviews的一个工作单元。 Github和Bitbucket的用户对这个术语很熟悉。
将PullRequest拆分为较小的代码段这个方法很简单，可以成为提高codereviews工作流程最有用的技术。它之所以有效，主要有两个原因：
评审人心理上更容易接受开始和完成一小块代码的评审工作。更大的PR自然会让评审人推迟和拖延评审，并且在评审过程中被打断的可能性更大。
作为一名评审人，如果PR太长，就很难深入进去。要检查的代码越多，我们越需要耗费更多脑力来理解整个代码块。
将PR拆分为更小的代码段，让你有更多机会在更短时间内得到更深入的评审。
目前，我们无法设置一个适用于所有编程语言和所有类型工作的通用标准。对于内部的数据工程项目，我们原则上是要将PR控制在200-300行代码。如果超过这个阈值，我们一般会将它拆分成更小的块。
当然，我们也要注意不要将PR拆分得过小，因为这意味着评审人可能需要检查好几个PR才能理解整体逻辑。
使用DraftPRs你听过造一辆汽车与画一辆汽车的比喻吗？这个比喻是这么说的：
用户要你造一辆车；
6个月后，你造了一辆漂亮的保时捷；
你向用户展示这辆车后，他们问你这辆车能不能放得下他们的5个孩子和冲浪板。
显然，这里的问题在于目标不清晰，团队没有收集到足够的反馈就直接构建解决方案。如果在第一步后，我们先画一幅汽车的草图，并将其展示给用户，他们会问相同的问题，这样就可以进一步了解客户需求。如此，就为我们节省了6个月的工作量。软件也不例外，我们可能会犯同样的错误，在用户不需要的特性或模块上投入大量工作。