全文共字，预计学习时长7分钟
图源：unsplash想要提高团队绩效，找到瓶颈是第一步。现实中，最大的限制因素不是编码速度，而是代码审查。因此，为了加快审查速度，笔者对比了两种pullrequest：
·注释很少并且快速合并的pullrequest
·有很多注释，需要多轮审查的pullrequest
我的结论是，有九种方式能让审查pullrequest更轻松。
1.添加关于“为什么”的代码注释
在写一个新功能的时候，会有很多与之相关的信息。写代码时要全盘考虑需求，第三方系统的局限性，以及和遗留代码库的交互。但是别人不了解其上下文来源，所以看到这个代码时会问“它为什么在这？”或是“为什么要选择这种方法？”
因此要通过添加解释性的注释，让阅读代码的人提前知晓“为什么”。笔者不认同一些人宣扬的观点：注释有害，应当忽略。
注释有很多种类。那些描述代码用途的确实是累赘。提取一个方法，采用一个精心挑选的命名，就能消除这种麻烦。另一方面，当解释为什么这样写代码时，也增加了代码阅读者的信息量。这些注释将阅读者的认知水平理想化地提高到了与编码人员相同的层级，这有助于增进对代码的理解。
图源：unsplash笔者的注释通常会给出类存在的原因、相关资源的链接以及代码的前因后果：
#FirstCrewDragonlaunchwaspostponedduetobadweather,
#andnowweneedaneventforthesecondfirstlaunch.
#Hencethestupidname.
classSecondFirstCrewDragonLaunch
...
End
2.描述清晰
有关pullrequest的描述为审查者提供任务最初的上下文，包括：
·标签的链接。
·对已完成事件的总结（如果不能从pullrequest的标题中看出）。
·相关pullrequest的链接（例如在另一服务中的相关变化）。
不要把自认为理解代码需要的信息放在对pullrequest的描述里，应当进行代码注释：它们的效果更加显著，有助于未来代码阅读者的阅读。
3.精简pullrequest
这是一项强大的技术，谷歌甚至就小型pullrequest的益处单独写了一篇文章（