共计 6560 个字符，预计需要花费 17 分钟才能阅读完成。
原文由知無涯发表于 TesterHome 社区，点击原文链接可与作者间接交换。
1. 编写良好的 CL 形容
CL 形容是一项公开的记录，其内容蕴含批改了 什么 与 为什么 这么批改。尽管你的 CL 只是在你与审核者之间产生，但它是版本控制历史的一部分，若干年之后，很有可能会有成千盈百的人浏览。
当前的开发者可能会依据形容搜到你以前写的 CL。在没有准确数据的状况下，他可能依据本人的含糊记忆搜索 CL。如果所有的信息都只蕴含在代码外面，形容中简直没有相干内容，那么定位到你的 CL 将会破费太多的工夫。
第一行
● 简短形容做了什么。
● 残缺的句子，祈使句。
● 前面空一行。
CL 形容的 第一行 应该是一句简短的形容，用以阐明 CL 做了什么。在第一行前面留一空行。当前有开发者搜寻版本控制历史的代码时，这是他们看到的第一行，所以第一行应该提供足够的信息，他们不用浏览代码，也不用浏览整个形容，只需扫一眼便晓得 CL 做什么，他们节省时间。
一般而言，CL 形容的第一行是以命令口气（祈使句）写的一句话。举例说明，咱们应该写“删除 FizzBuzz RPC，并用写的零碎 替换 它。”，而不是写成“删除了 FizzBuzz RPC，并 曾经 用写的零碎 替换 它。”当然，第一行写成祈使句就能够了，其余内容不用如此。(译者注：原文中的背面例子是当初进行时。但在中文中当初进行时与祈使句基本一致，不好翻译。此处改成了当初实现时。)
形容内容要提供充沛的信息
形容内容应该提供足够的信息。它可能蕴含一段对于问题的简短形容，为什么这是最好的解决方案。如果有更好的解决方案，也应该提及。如果有的话，相干的背景信息，如 bug 编号、基准后果和相干的设计文档也应蕴含在内。
即便是小的 CL，也应该蕴含这些信息。
蹩脚的 CL 形容
“修复 bug”是一个很不失当的形容。哪个 bug？你做了哪些事件来修复它？统统都没有。相似蹩脚的形容还包含：
●“修复编译。”
●“减少补丁。”
●“把代码从 A 移到 B。”
●“第一阶段。”
●“减少不便的性能。”
●“革除死链。”
以上这些都是咱们在实在案例中见过的 CL 形容。作者可能认为他们提供了足够的信息，其实它们不合乎 CL 的目标形容。
良好的 CL 形容
这是几个良好形容的样例。
1. 性能批改
RPC：移除 RPC 服务器的音讯闲暇列表的大小限度。
服务器（如 FizzBuzz）有大量的音讯，能够从重用中受害。使闲暇列表更大，并增加一个 goroutine，随着工夫的推移迟缓开释闲暇列表，以便闲暇 服务器最终开释所有闲暇列表。
后面几句话形容了 CL 做什么的，接下来形容解决了什么问题，为什么这是一个好的解决方案，最初波及到了一些实现细节。
2. 重构
构建一个带 TimeKeeper 的 Task，以便应用它的 TimeStr 和 Now 办法。在 Task 中减少一个 Now 办法，而后删掉 borglet() 办法（这个办法仅仅被 OOMCandidate 应用，它调用了 borglet 的 Now 办法）。这样就替换掉 Borglet 的办法，把它委托给 TimeKeeper。
让 Tasks 提供 Now 是缩小对 Borglet 的依赖所做的一小步。最终，从 Task 上调用 Now 的形式会代替成间接调用 TimeKeeper，咱们会逐渐实现。
持续重构 Borglet 档次的长期指标。
第一行形容了 CL 做什么的，以及过来它是怎么扭转的。形容的其余局部谈到了具体实现、CL 的上下文，这种办法并不完满，但在朝着完满的方向后退。而且也解释了 为什么 应该这么改。
3. 须要一些上下文的小 CL
为 status.py 创立一个 Python3 的编译。
在原始的编译（Python2）旁创立一个 Python3 的编译，让曾经应用过 Python3 编译的用户依据某些规定抉择 Python3 还是 Python2，而不是依赖于某个门路。它激励新用户尽可能应用 Python3 而不是 Python2，并大大简化了以后正在应用的某些主动编译文件重构工具。
第一句话形容做了什么，其余局部解释 为什么 要这么批改，并向审核者提供了不少额定的上下文信息。
提交 CL 之前审核形容
在审核过程中，CL 可能会产生重大扭转（与最后提交审核的 CL 相比）。在提交 CL 之前有必要再扫视一遍 CL 形容，确保形容可能正确地反映 CL 做了什么。
2. 小 CL
为什么应该写小 CL？
小 CL 有如下长处：
● 绝对让审核者独自拿出 30 分钟审核大 CL，不如让他破费几个 5 分钟审核代码。对审核者而言，后者更容易。
● 审核更彻底。产生较大批改时，往往会重复审核、批改，审核者与开发者常常会因为过多的重复而在情绪上受到影响，以致于把精力放在批改上了，却疏忽了 CL 中更重要的局部。
● 引入新缺点的可能性更小。如果批改的内容比拟少，天然审核人的效率会更高，开发者与审核者都更容易判断是否引入了新的缺点。
● 如果被回绝，节约的工夫更少。如果开发者破费了很大的精力开发了一个大 CL，直到审核的时候才晓得整个开发的方向错了，那么之前的所有工夫就全节约了。
● 更容易合并代码。大 CL 在合并代码时会破费很长的工夫，在合并时须要破费大量工夫，而且在写 CL 期间可能不得不频繁地合并。
● 更易于设计。欠缺小 CL 的设计和批改要容易得多，屡次渺小的代码品质进步比一次大的设计扭转更容易。
● 缩小阻塞审核的可能性。小 CL 通常是性能独立的局部，你可能正在批改很多代码（多个小 CL），在发送一个 CL 审核时，同时能够持续批改其余的代码，并不会因为以后 CL 的审核没有实现而阻塞。
● 更容易回退。一个大 CL 开发的工夫比拟长，这象征从开发到代码提交这段期间，代码文件的变更会比拟多。当回退代码时，状况会变得很简单，因为所有两头的 CL 很有可能也须要回退。
请留神：审核者有权因为你的 CL 太大而回绝它。通常，他们会感激你为代码做出的奉献，然而会要求你把它拆分多个小 CL。一旦写好了代码之后，要把它拆分成小 CL 通常须要花很多工夫，当然，你也可能会破费大量工夫与审核者争执为什么他应该承受这个大 CL。与其如此，不如设计之初就保障 CL 尽量小。
如何定义“小”？
一般而言，一个 CL 的大小就应该是 独立性能的批改。
这意味着：
● 一个 CL 尽量最小化，它只 做一件事。通常它只是一个性能的一部分，而不是整个性能。总体而言，CL 太小或太大都不好，二者取其轻的话，太小略微好点。能够与审核者一起探讨，找出大多比拟适合。
● 审核者须要了解 CL 中蕴含的所有（除了当前可能要开发的性能之外），包含 CL 代码、形容、已存在的代码（或之前曾经审核过的相干 CL）。
● 在 CL 代码提交之后，无论是针对用户，还是针对开发人员，零碎应该仍旧运行良好。
● 如果代码难以了解，通常是因为 CL 还不够小。如果新增一个 API，同时应该同一个 CL 中附上这个 API 的应用办法，便于审核者了解如何应用，也不便当前的开发者了解。同时也可能无效避免提交的 API 无人应用。
没有直观的规范判断 CL“太大”应该合乎哪些条件。100 行代码通常是一个正当的大小。1000 行代码通常太大了，但也不能一概而论，这取决于审核者的判断。批改文件的个数也影响它的“大小”。在一个文件中批改 200 行可能没问题，如果这 200 行代码横跨 50 个文件，通常而言太大了。
记住，当你开始编写代码时，只有你最理解代码，而审核者通常不理解上下文。在你看起来很是一个适合大小的 CL，审核者可能会很困惑。毫无疑问，在写 CL 时，CL 的大小最好比自认为的还要小。审核者通常不会埋怨你的 CL 太小了。
什么时候能够有大 CL？
当然，也有一些例外情景，容许 CL 比拟大：
● 删除一个文件与批改一行没有太大区别，因为它不会破费审核者太多工夫。
● 有时候，一个大 CL 可能是由牢靠的主动代码重构工具生成的，审核者的工作次要是查看它是否做了它应该做的工作。尽管合乎以上提到的注意事项（例如合并和测试），这类 CL 也可能比拟大。
以文件来拆分
另外一种拆分大 CL 的办法是：对 CL 中波及的文件进行分组，这就要求不同独立性能的批改须要相应的审核者。
例如：你提交了一个 CL，这个 CL 批改了协定缓冲区，而且另外一个 CL 用到它。因而咱们先提交第一个 CL，再提交第二个 CL，并让两个 CL 同时审核。此时，你应别离向两个 CL 的审核者告知另外一个 CL 的内容，以便他们晓得上下文。
以代码和配置文件进行拆分。例如，你提交了 2 个 CL：其中一个 CL 批改了一段代码，另外一个 CL 调用了这段代码或代码的相干配置；当须要代码回滚时，这也比拟容易，因为配置或调用文件有时候推送到产品比代码批改绝对容易。
独自重构
在批改性能或修复缺点的 CL 中，不倡议把重构也加进来，而是倡议把它放到独自的 CL 中。例如，批改类名或把某个类移到其余包内是一个 CL，修复这个类中的某个缺点是一个 CL，不要把它们合并到一个 CL 中。把它们拆分进去更有利于审核者了解代码的变动。
有些代码清理工作，如批改某个类中的一个变量的名称，能够把它蕴含在一个性能批改或缺点修复的 CL 中。那规范是什么呢？这取决开发者与审核者的判断，这种重构是否大到让审核工作变得很艰难。
把测试代码蕴含到对应性能的 CL 中
防止独自提交测试代码。测试代码用以验证代码性能，应该把它与代码提交到雷同的 CL 中，尽管它会增大 CL 的代码行数。
然而，独立的测试批改能够放到独自的 CL 中，这与独自重构中的观点比拟相似。它蕴含如下内容：
● 为过来提交的已存在代码创立新的测试代码。
● 重构测试代码（例如，引入 helper 函数）。
● 引入测试框架代码（如，集成测试）。
不要毁坏编译
如果同时在审核的有多个 CL，并且这些 CL 之间存在依赖关系，你须要找到一种形式，确保顺次提交 CL 时，保障整个零碎仍旧运行良好。否则，可能在提交某个 CL 之后，让零碎编译谬误。此时，你的共事在更新代码后，不得不花工夫查看你的 CL 历史并回退代码以确保本地编译没有问题（如果你之后的 CL 提交出了问题，可能会破费更多工夫）。
无奈将其变小
在某些情景下，如同你没法然 CL 变得更小，这种状况很少产生。如果开发者常常写小 CL，那么他往往都能找到一种把 CL 拆得更小的办法。
如果在写代码之前就预计这个 CL 比拟大，此时应该思考是否先提交一个代码重构的 CL，让已有的代码实现更清晰。或者，与团队其余成员探讨下，看是否有人能帮你指出，怎么在提交小 CL 的前提下实现以后性能。
如果以上所有办法都试过，还是不可行（当然，这种状况比拟常见），那就先与所有的审核者沟通一下，告知他们你将会提交一个大 CL，让他们先有心理准备。呈现这种状况时，审核过程往往会比拟长，共事须要写大量的测试用例。须要警觉，不要引入新的 bug。
3. 如何解决审核者的评论
在收回 CL 之后，审核者个别会给出反馈（评论），让你批改代码。上面咱们就来详细描述如何解决这些评论。
不要情绪化
代码审核的指标是保障提交到的代码库中代码的品质，进而保障产品的品质。当审核者提出一些批判性的评论时，开发者应该通知本人，对方在尝试帮忙你，保障代码库的品质，帮忙 Google，而不是针对你的人身攻击或集体能力的狐疑。
有时候，审核者感到很丧气，并在评论中表白了这种情绪。其实，这不是一种正确的形式，但作为开发者，你应该有足够的心理准备来面对这种状况。问一下本人，“我能从审核者的评论中读出哪些建设性的意见？”假想他们就是以这种建设性的语气对你说的，而后依照这种倡议去做。
不要在代码审核中带着情绪回复评论。在审核代码过程中，违反业余礼仪是件很重大的事件，但咱们永远没法确保他人不违反业余礼仪。咱们能够保障本人不要违反它。如果你很怄气或恼火，以致于无奈敌对地回复，那就来到电脑一会儿，或者先换一件事件做直到心态平静下来，再礼貌地回复。
个别状况下，如果审核者没有以建设性地口气提供反馈，反馈的形式不够礼貌，能够私下与他沟通。如果不不便与他私下沟通，也不不便通过是视频电话近程沟通，能够给他独自发一封邮件。在邮件中，以敌对的态度向他解释，你很难承受这种反馈形式，期待他能换一种沟通形式。如果他仍旧以一种非建设性的形式回复你，或没有达到预期成果，那就降级到他的主管吧。
修复代码
如果审核者说，他对你的代码中有些内容不了解，你的第一反馈是廓清代码自身。如果代码无奈廓清，加一段正文用以解释为什么这段代码这样写。如果这段正文放到代码里毫无意义，那就应该放到代码评审工作的评论中作为反馈的解释。
如果审核者无奈了解某段代码，很有可能其余的代码阅读者也不懂。在代码审核工具中回复它对将来的代码阅读者没有任何益处。这种状况应该尝试清理代码，或减少一些必要的正文，以帮忙他们浏览。
先思考本人是否有改良的空间
写一个 CL 会消耗大量精力。在提交一个 CL 审核时，开发者会往往会产生简直快要实现的幻觉，自认为无需进一步批改。当审核者回复须要批改某些代码时，开发者容易条件反射地认为反馈不正确，审核者没必要妨碍本人的开发，他应该让这个 CL 审核通过。然而，无论你有多确定 这点，最好还是先退一步，认真思考审核者是否在反馈中提供了有价值的内容，能够帮忙进步代码库的品质。你的第一个问题应该永远都是，“审核者说得对吗？”
如果无法回答这个问题，很有可能审核者须要进一步廓清评论。
如果你 曾经 思考过，并确认你是对的，那就在回复中解释为什么你的办法比拟好（绝对已有的代码、用户）。通常，审核者也会提供倡议，他们心愿你比拟一下哪个更好。你可能晓得一些对于用户、代码库或 CL 的内容，而这些正是审核者不理解的，那么就把这些写进去，提供更多的上下文。通常，你在技术上能够与审核者达成统一。
抵触解决
在解决抵触的第一步永远都是应该先尝试与审核者达成共识。如果无奈达成共识，能够参考审核代码规范，当面临这种情景时，它为咱们提供了一些准则。
4. 紧急情况
有时候会有紧急的 CL。紧急情况产生时，必须尽快实现审核流程并提交。
哪些是紧急情况？
紧急 CL 应该是一个 小 批改：一个重要的公布版本须要蕴含某个性能（无奈回滚），修复产品中重大影响用户的缺点，解决紧迫的法律问题，敞开一个重要的安全漏洞，等等。
处于紧急情况时，咱们应该关怀整个代码审核流程的速度，而不仅仅是响应的速度。更精确地说，在这种状况下，审核者应该把审核速度与代码的正确性（代码是否解决了紧急问题？）放在首位。并且，当紧急情况产生时，它的审核优先级必须高于其余所有的代码审核。
当紧急情况处理完毕之后，应该回过头来再持续做一次更全面的审核。
哪些不是紧急情况？
须要明确的是，如下情景 不是 紧急情况：
● 心愿本周实现，而不是下周（除非有一些无奈防止的硬期限，如合作伙伴之间的契约）。
● 开发者为这个性能曾经开发了很长一段时间，他们心愿尽快提交代码。
● 所有的审核者都不在雷同的时区，他们当初是中午或下班时间。
● 当初是周五快下班的工夫，如果开发者能在周末来到公司之前提交代码那就太棒了。
● 经理说这个审核必须实现，CL 在明天必须提交因明天是截止日期(软期限，而非硬期限)。
● 回滚一个造成测试失败或编译谬误的 CL。等等。
什么是硬期限？
所谓硬期限（hard deadline），就是错过了就会有灾难性的事件产生。例如：
● 合同规定，你必须在某个特定日期之前提交 CL。
● 如果产品没有在某个特定日期之前公布，很有可能会影响销量，甚至在产品市场导致失败。
● 有些硬件制造商每年只会公布一次产品。如果在截止日期之前没有提交代码给他们，而这些代码又十分重要，很有可能会造成灾难性的结果。
推延一周公布不是灾难性的。错过某次重要的会议可能是灾难性的，也可能不是。
大多数截止日期都是软期限（soft deadline），并非是不可扭转的。这些软期限冀望在某个工夫节点失去须要的性能。它们很重要，但不应该为了达到目标而毁坏代码的健康状况。
如果公布周期较长（好几个月），则很有可能会就义代码品质，以期在下一个周期之前实现某个性能。如果这种模式重复呈现，那就为我的项目筑起了难以承受的技术债，这是我的项目开发中常见的问题。如果开发者常常在邻近开发周期完结的时候提交代码，那么团队“必然”只能做外表上的代码审核。此时，团队应该批改开发流程，大型的性能批改应该在周期的晚期进行，以确保有足够的工夫做好代码审核。
原文由知無涯发表于 TesterHome 社区，点击原文链接可与作者间接交换。
今日份的常识已摄入~
想理解更多前沿测试开发技术：欢送关注「第十届 MTSC 大会·上海」>>>
1 个主会场 +12 大专场，大咖星散精英齐聚
