代码review是研发很重要的一环，那么关于review的工作我们需要注意些什么？如何才能把review工作做好呢？
本文提供了10个建议，个人认为很有指导意义，做了下翻译分享下
我们都见过代码被不停来回地review，最终需经过几轮修改才能被合并。
review的同学不认可其编写的代码会让作者感到恼火，同时对于review的同学来说会认为作者没有很好的接收他们的意见。
但有一些好的方法，不仅取决于作者能很好接收review的反馈并及时更改，也有一些好的实践能确保review过程不那么枯燥且更清晰。
高效的代码review工作对每个人都是有好处的，因为：
- 作者能更清晰地接收你的反馈，使得代码的返工修改次数减少
- 你将为作者提供建议和要点，这些帮助能影响对方对整个代码的编写规范，使得对方能在以后的编写过程中少犯错误
- 代码将更快被合并，避免影响到其它相关人的工作
- 至少对每个实现会做出高质量的讨论
请注意，本文不会去说明如何进行代码review工作，或这样做时要注意什么。相反，我们列了一些建议和规则来指导你在代码review过程中涉及的方法和行为。
让我们开始吧。
1. 总是问为什么
让我们看一些review时可能存在的评论：
- 不好的方法命名
- 此处代码放的位置不对
- 我认为这里可能会有问题
这些评论有一些问题，最突出的是没有一个推理的过程。对于这些评论，作者只能假设他的代码出现了问题，但我们知道“假设”是一个糟糕的行为，特别在这些例子中：
- 作者可能会为他们的代码命名错误得出一个错误的结论，然后做了一个错误的修复，这个会导致额外的review工作。
- 在代码命名错误上作者不会得到有价值的反馈，否则，他们将学到新的东西并扩展了个人的视野。
那什么是更好的review评论呢？我们看一个例子：
这个方法命名不理想，它应该是以表示动作的动词开头。在这种情况下有一个后缀的指示，类似于'...ByUserID'，记得去看下我们的代码规范文档了解更多细节。
是的，你只是多写了一些文字，但你现在更清晰的告诉了作者：具体是什么问题且遇到方法命名时该如何处理
你知道你会感到多棒么？当下次作者邀请你代码review时，你看到对方按你的建议实现了方法命名。
2. 做彻底
代码的作者可以是团队中最资深的人（了解所有代码细节），或是一个新员工第一次提交代码进行review。
这些都不应该影响代码review的质量和完成度，也不能因为你信任他们（提交review的作者）的工作而有任何懈怠。
代码review不仅要确保代码质量和结构，也要去找出一些作者可能忽视的边界问题或bug，甚至只是如编写了随机字符的错误。
认识到这些措施对我们有极大的好处，在代码合到生产环境（或暂存）分支前发现bug总是比「找到bug->报告它->找到原因->修复问题并继续发送代码review」显得更加有效。
3. 不要给出完整的结果
作为一个代码的review者，当你发现问题时：修复问题代码或提出解决方案不是你的工作。
是的，你可以（有时应该）帮忙提供建议或讨论你的想法，但并不意味着说你要给出一个完整的解决方案。假设有如下评论：
这个方法对执行不是很好，应该像这样：
````
<代码>
````
当你这样做时，代码的作者只会从你的建议中学到很少的东西，在一些情况下他们甚至会直接拷贝你的方案而没有深入细节去做思考。
尤其是如果你经常这样做，代码的开发者会很容易变得懒惰并且不会做完整地思考写出复杂的程序，他们认为代码review的人会帮忙发现问题并提供修复意见。假如你真的经常这么做，当你经常被邀请到代码review时你不要感动惊讶。
针对这样的情况，正确的做法是：描述对应的方法应该是怎样的形式。你应该说明原来的代码为何不能很好的执行，以及如果是自己将会怎么做，可以一步步写下来。在某些情况下，写一些伪代码也是可以的，只要你让开发人员真正考虑你建议的方法（而不仅仅是拷贝你的方案），那就好多了。
4. 不要推迟review
在任何类型的团队中，尤其是对于工程团队来说，不妨碍彼此的工作是很重要的。
对于开发人员来说来回地进行上下文的切换不是一个容易的事，在等待对其中一个问题进行代码review时，它们将不得不投入到另一个问题背景中处理事情，当上一个review获得评论要去解决时又得来回走动。
即使review发生的比较快也还是会发生，因为开发者会想切换到下一个任务。然而拖的越久开发者就需要应付更多的任务、更多的代码review，将不得不在不同分支间来回切换：重新读他的代码（又一次上下文的切换）、解决冲突等。
另外，想象下实际上你会阻塞到对方的工作，意味着对方（代码提交者）在其代码被合并前将不能继续他的工作。在这种情况下，在你完成最终的review前，他们实际上无法工作。整个事情对双方来说既低效又烦人（因为，代码提交者一旦觉得工作被阻塞就会每隔半小时发信息给review者要求进行review 🙃）
为了确保您不会对这种混乱的情况去妥协，在您的日程安排中优先考虑代码review始终是一个好习惯。当然，您可能有更紧迫的任务要处理，或者可能并不总是能够立即花时间进行review，但您有义务在自己的工作和review之间找到适当的平衡点。
如果你有责任为很多人review代码，那么每天都在个人的日程中安排一个时间段专注于此工作（或是安排两个时间段来更快地进行迭代）
5. 参照指南
如果您的团队足够大或足够结构化，您可能会在知识库中编写一些指南，作为项目/代码库编写代码的指南。
它可以包括代码结构、命名约定和许多通用的设计方法。如果您经常编写代码并review其他人的代码，您可能会习惯这些准则。
但您应该尝试每隔几周或每个月重新打开指南快速阅读一次，你会惊讶地发现代码review中有多少已被你忘记或没有注意到的点。
如果您的团队没有这样的指南，那么在review代码时编写一个会是个好主意。在仅仅几次代码review中，您肯定会想出一长串您在review期间发现的需关注的要点。
更重要的是，这样的指南列表将作为您团队中唯一的标准，确保所有代码作者和review者在编写/更新/阅读代码时都有依据可供参考。
6. 欣赏好的代码
代码review并不总是只有坏消息，有时你看到一些优雅的代码时会让你欣赏其作者： 一段逻辑，一些非常有效的查询优化，或者出色的用户体验。 赞赏他吧。
你可以简单地用 nice 来评论相关代码！ 或者用更长的句子来描述你是如何欣赏的。 无论哪种方式，这个人都会感到被激励，这肯定会对团队合作产生影响。 此外，如果其余的代码不是那么好，他们也不会在review后感觉太糟糕。
最重要的是，作者此时会相信他们写的代码确实是好的，因此他们可以在未来尝试写更多类似的代码，或者针对其他问题采取类似的方法。
7. 谦逊、积极
多年来，我偶然发现很多review的评论是愚蠢的，或是可以没有。在一些糟糕的日子里，我可能也写了其中的一些。
这样的评论简直是冒犯和令人沮丧的，并且不会创造任何价值。如果您想了解更多，Gitlab 在这方面提供了一些很好的示范，这听起来非常符合他们公司“积极意图”的价值观。
长话短说，在评论中表现得友善，尊重他人的时间和工作，并假设他们在编写代码时尽了最大的努力，这些都是值得的。在代码review中吹牛、羞辱或生气绝对没有任何好处。
让我们看看我从之前的代码review中复制的一些真实示例，注意在句子中体现基调的表情：
- 这不应该也是“value”吗？🤔
- 也许你可以使用“find”来代替
- 我想名字可以用“get…”开头
- 恕我直言，“Synchronize”在这里听起来很奇怪。
- 请在此处添加一个空行
相信我，说“恕我直言”或“🤔”的还会有很长的路要走。
8. 指出资源
我都不好意思告诉你，在我第一个负责前端工作的日子里，我们在代码review中不知相互分享了多少次关于css 属性的链接（可能刚刚配置了 stylelint 🙈），我相信它甚至一度出现在我的书签中。
如果您知道有一个资源可以帮助代码作者解决问题，请将链接贴到您的评论中。他们往往会关注评论，甚至可能成为他们在工作中经常使用的资源。如果您的资源很大且难以搜索到信息，也可以贴上您公司指南的特定部分。
也许你可以指出作者所依赖代码库中很重要的资源，过去已有的相关实现和组件对作者来说是一个很好他指南，如果他们以前没有使用过它，他们可能不知道代码库的特定部分。
如果你发现某些代码需被优化并且你知道之前有类似的实现，请不要假设作者会找到它。在您的评论中指出，以便作者可以将他/她的代码与现有代码进行比较，在必要时进行改进或遵循相同的约定。
9. 不只是你，要考虑整体
在阅读代码进行review时，您必须能够轻松理解它。如果有一部分代码对你来说不好理解，这并不意味着你没有仔细阅读代码。相反，这意味着代码写的不够清晰。
如果您无法理解该代码块的作用，那么当其他开发人员需要接触该部分代码时，他们可能难以理解。当您检测到此类代码时，您应该毫不犹豫地说出来。并且不要只要求作者向您解释该代码块，而是要求重写。
如果实在不能写得更清楚，至少请作者在代码中添加一些注释。随意提出问题以了解代码的用途，以便您提出替代方法并讨论解决方案，但您不应只对回复感到满意，您应确保最终合并的代码易于理解。
10. 你的方案并不总是最优的
通常有不止一种方法来完成事情。在阅读一段代码时，您可能会想到其他方法，并且会倾向于在评论中提出建议，因为它是更好的解决方案。有时您需要问自己：这真的是更好的解决方案吗？还是作者的方式也不错，但会建议采用你更常使用的方案？
除非代码复杂性或可读性有明显优势，否则在建议重写之前请三思而后行。重新阅读代码并确保它符合您团队的约定和代码风格，它可以很好地完成工作，并将其与您脑海中的替代方案进行比较，以了解它将如何影响代码质量。如果作者的方式没问题，但您仍然认为自己的方式更好，请将其写为建议而不是强制，并愿意与作者讨论您建议更改的原因和细节。
希望这些技巧能帮助您成为更有效的代码review者，从长远来看，为您、代码作者和整个团队节省时间。如果您对上述内容有任何想法，或者在review代码时有其它能派上用场的建议，请在评论中告诉我。
