Code Review，也被称为“代码评审”，或者“CR”，一般是发生在我们需求开发的尾声，或者某个阶段的尾声，为了保证代码一定的质量，以及开发人员对需求理解无偏倚，而开启的“批斗大会”。

（偷个懒，下面都用C.R 代替 Code Review，来进行一些叙述）

做C.R可不是一件简单的事情，完成一次好的C.R更是一件复杂困难的工作。大多数开发者会认为C.R是一次技术沟通的过程，但在我看来，它同时也是一个社会过程。

要知道，C.R实际上其背后的想法是非常合理的：

作为被评审者，你会因为多了一双眼睛，多了另一个人的思维而享受到一定的好处。

作为团队之中的其他人员，对于整个项目代码库新的那部分代码有了一些新的认识。

通过这种认识，产生出来的异议、争论，在理想的情况下，可以保证项目在代码的模式上、技术的选择上，拥有一致性，从而完美落地，实现最终的需求和效果。

但是，不乏有一些糟糕的的C.R，比起带来代码上的进步，更多的却是带来恶心人的体验。

回想一下是否有这样的经历，在完成一次C.R后，反而是感到士气上低落、情绪上烦躁或气恼。

可以肯定是，没有人希望C.R给自己的团队成员或小伙伴带来这种体验，所以我们来想想，有哪些事情，我们可以使一次C.R变得更完美。

Code Review不是为了证明你有多聪明

C.R的意义和目标完全是提高开发人员的水平和技能，从而让项目代码库变得更加健壮。

更多的应该针对项目出现的问题、新代码实现上的不足进行讨论，从而解决面对的问题，或者保证代码的质量和一致性。

我们最应该避免的，也最应该认识到这件事：代码评审不是让你进行自我夸赞、贬低他人、从而炫耀自己的知识量，而体现出自己聪明的一面。

想像一次，当你作为被评审者，讲解自己的“优美”的实现时，突然跳过一位小可爱，大肆批评，跳过建设性意见，进入自我夸赞的过程，最后留下一句：所以我觉得你从思维上就错了。

在认识到这一点的前提下，我们来对代码进行评审，才能使C.R具有评审的意义，也就是使被评审人员认识到不足，了解到新的思路，从而实现更优质的代码。

那么具体我们应该怎么做呢？

Code Review是一种双向的对话

作为一名评审者，你可能是职位更高，或者代码能力更强，或者对于项目有更多的经验。但作为被评审的那一员，他可能对于自己的代码实现有更多的理解和考量。

所以作为评论的人，要知道自己提出来的建议并不一定是最好的，我们有可能错过开发人员的一些考虑，或者是误解了其中一些意图。

所以鉴于此，在提出建议时，同时也应该提出问题。

比起说：你用xxxxx的方式做更好点。

不如说：这里选择xxxxx的方式是有什么原因吗，我个人更偏向于使用yyyyyy的方式，可以带来blablabla。

最终这个建议能带来的结果是一样的，但对于参与评审的当事人或者其他人员而言，我们这次对话可以带来更深的协作性。

不要忘记C.R的意义，要为参与者提供从代码上学习的机会。

Code Review不只是一次“批斗”

C.R的过程是一次思维碰撞的过程，它可以为所有参与的人提供反馈，但这种反馈不应该只是批评性建议，或者说负面评论。

对于自己高度认可的，甚至是自己都没有想到的，不要自己在内心中夸赞，表达是重要的。

我们可以对这类实现表达我们的夸赞：这个实现我倒是没有想到，很赞。

表达出自己内心的赞同，

对于整场评审而言，是一种总体基调上的平衡。

对于被评审者而言，他们会对这段代码进行更深的解释，进行更多的思考，从而达到优者更优的结果。

对于参与者而言，则获得到了更有意义的代码思维。

Code Review不是简单的读注释

作为一名被评审的人员，在Code Review中的角色，实际上是最重的。

通过你的阐述，其他参与的人员，能快速理解实现的需求，逻辑上的顺序，所以作为被评审者，要避免自己的描述，只是对注释的输出，我们可以从几个方面来进行：

• 简单讲解下实现的需求内容，使参与人快速进入场景。
• 是否和第三方系统进行了对接，讲解下对接的方案，使参与人可以评审对接合理性问题。
• 是否包含新的依赖、新的数据库等，使参与人评审是否有必要，是否存在重复实现。
• 是否选择了一些短期解决方案，使参与人评审是否存在问题，进行边界问题的讨论。
• ....

除此之外最重要的，便是对需求实现方案的说明，对代码上技术选择的说明。

基于此，C.R对于你而言，意义才能有体现：确保需求无偏差、实现上避免漏洞等。

不要拒绝Code Review

实际上有不少人对于Code Review是抱着一种“浪费时间”的态度的，不知道看完这篇小短文后是否还是保持这种想法？

但一次完整的Code Review，实际上为我们带来的好处是非常明显的。

作为一名开发人员，即使再怎么满意自己编写的代码，但在多一双眼睛的情况下，总能暴露出一些自身发现不了的问题。

作为团队而言，它达到了帮助提升团队的水平并改善代码库的长期健康状况的一个目标。

因此，将其看做是为团队成员和自己提供的学习机会，将代码检查看作是一项技能，不断地提高自己，大牛的道路总是充满了“干劲”呢。

谢谢大佬们的评论、点赞和转发[击掌]

关注居家程序员，时不时更新技术“硬”文和代码生活小乐趣