代码审查的艺术及其必要性
代码审查是一门艺术。虽然大多数公司都会进行代码审查，但只有少数公司能够充分利用代码审查的潜在优势。在本文中，我们将探讨您和您的团队可以采取哪些措施来最大限度地发挥代码审查的潜力。
在本文中
代码审查是一项团队活动
代码审查的第一条原则是：代码审查关乎整个团队。每个人都不同，开发人员对代码有不同的看法，对代码审查的期望也各不相同。此外，每个人对批评的接受程度也不同，有些人比其他人更敏感。
为了确保整个团队对代码审查流程达成共识，你可以采取以下两种方法之一：要么召开一次会议讨论相关事宜，明确彼此的期望；要么采用更轻松的方式，在第一次代码审查时就与团队展开讨论。如果你在第一次代码审查时就提出这个问题，即使你的评论比较严格，也能展现出你关心团队成员的一面。
在讨论代码审查时，尽量明确你认为重要的是什么。代码审查的目的是查找错误，还是应该提出改进意见和建议？如果鼓励提出意见，这些意见是必须修复的，还是可以忽略的？
讨论并达成所有开发人员都认可的协议，但尽量避免创建明确的检查清单。使用清单很容易导致开发人员勾选每一项就以为代码审查完成了，而没有真正反思解决方案。
为什么要进行代码审查？
从管理者的角度来看，代码审查通常是为了发现 bug，确保提交的代码在测试人员测试时不会出现问题。但对我这个开发者来说，代码审查的主要目标并非消除 bug，而是让更多人参与到解决方案的讨论中，并促进替代方案的探索和知识共享。从长远来看，这才是真正能够提升产品质量，并促使开发者减少错误剪枝代码的途径。
如果代码审查做得好，它可以从很多方面帮助你的团队。以下只是代码审查能带来的一些好处。
- 提交代码前仔细检查一遍。
- 学习并思考其他开发者的代码和观点
- 教导和帮助其他开发人员
- 统一团队对产品及其代码和新增代码的看法
- 更好地了解完整的代码库
- 阻止虫子入侵
- 提高代码质量
- 提高测试质量
- 减少技术债务
- 改进的文档，包含更清晰的提交记录和更完善的注释。
- 识别安全问题
- 在代码审查期间而不是两周后修复问题，可以节省时间。
- 组建团队
列表中的最后一点容易被人忽略，但却是最重要的一点。良好的团队沟通对于各种业务和发展都至关重要。代码审查是促进团队共同成长的绝佳方式，因为它很可能会引发冲突，而任何了解团队建设或冲突管理的人都知道，冲突对于团队的卓越发展是必不可少的。
爱喝茶的人会觉得这是种赞美。
为什么你不应该进行代码审查
说实话，没有太多理由不做代码审查。没错，这确实需要时间，但从长远来看，这些时间绝对会得到回报，因为它会带来诸多好处。
仔细想想。如果你创办了一家科技公司并雇佣了开发人员，你会希望任何人未经审核就提交代码吗？你会依赖一个任何人都可以贡献代码但无人审查的开源项目吗？
如果你对以上任何问题的回答是否定的，或者如果你想组建一支更好的团队并提高代码质量，那么代码审查就适合你。
代码审查前需要做什么
代码审查并非从提交拉取请求开始，在此之前，无论是提交代码的开发者还是审查代码的人，都需要完成一些特定的事情。
作为一名程序员
在一个多元化的团队中，总会有一个架构师负责检查整个团队的代码，但也有几个节奏更快的开发人员，他们从不仔细检查代码，而是盲目地使用两个字符的别名来执行“git add . && git commit -m "save" && git push”命令来推送代码。
提交代码进行代码审查时（甚至在没有代码审查的情况下），那些草率的开发者应该尽量向架构师学习。以下是一些在提交代码之前必须完成的事情：
- 每次提交的内容要尽量少，一次只实现一个用户故事/任务。这样便于代码审查，也方便团队成员在对变更原因有疑问时快速找到原因。
- 不要在提交中包含与当前任务无关的代码。如果您修复了与当前任务无关的问题，请在任务之前或之后另行提交。
- 你的提交中是否包含临时代码？请尝试在提交前修复它。如果无法修复，请用 TODO 注释标记它，并计划何时跟进处理。
- 你的提交是否包含复杂的解决方案？请为需要注释的部分添加注释。
- 提交代码前请仔细检查一遍。即使您已经按照上述所有步骤操作且没有遗漏任何步骤，您仍然可能会发现代码的改进空间或其他实现解决方案的方法。
- 手动测试你的代码。如果你还没有编写任何测试，请编写测试。
首先，当以上所有步骤都完成后，你就可以提交代码并请求代码审查了。审查结束后，就该去喝杯咖啡了！
你知道吗，我见过更优秀的开发者。他们第一次喝咖啡……
作为一名审稿人
作为代码审查员，代码审查的主要工作显然是审查代码，但在审查代码之前，请务必做好以下几件事。
首先，务必确保开发人员已完成开发工作，并且所有测试用例都已编写完毕。除非是为了提供额外的审核，否则不要审查尚未完成的代码。未完成的代码很可能会发生变化，尤其是在测试用例尚未编写的情况下，因此可能会发现错误。
其次，与开发该功能的开发者沟通，了解提交的内容。最好能同时查看相关的拉取请求和功能文件。这样做有助于理解代码和开发者的思路。
最后，在查看 pull request 之前，你可以先思考一下自己会如何实现这个功能。这是一种很好的问题解决练习，因为你既可以自己想出解决方案，也有可能看到针对同一问题的其他解决方案。如果你运气好，pull request 的开发者可能用另一种方式实现了这个功能，这将使代码审查变得更有意思。
代码审查期间应该做什么
当提交了拉取请求后，就该进行代码审查了。这项工作主要由审查者负责，但代码贡献者也需要考虑一些事项。
作为一名程序员
作为拉取请求的开发者，你通常可以悠闲地坐着，看着审核者抓耳挠腮。为了减轻审核者的负担，请确保随时可以回答问题。如果你和审核者不太熟悉，一定要主动提及你可以解答问题，这样他们才敢于提问。
作为一名审稿人
审查大型拉取请求需要时间。作为审查者，重要的是要记住，这绝对值得，无需为此感到压力。花点时间回顾一下本文开头关于为什么要进行代码审查的部分。然后，欣然接受这个提升自身开发能力的机会。
对于任何大于一行代码的提交，请务必在 IDE 中查看 pull request 的代码。这样可以更轻松地跟踪代码中的链接，并搜索函数和变量的使用情况。此外，它还能帮助您发现开发者应该做但却遗漏的更改，例如，如果某个函数在多个地方被调用，但开发者只在一个地方进行了更新。
在评论区留言时，请务必清晰表达你的意思。如果是个人观点，请务必说明理由。除了办公室的咖啡机煮出“不合格”的咖啡之外，没有什么比带着“我是建筑师”的自信态度，发表没有解释的主观评论更令人恼火的了。
再多一点似乎就足够了。
说到意见，除非你的团队没有讨论过代码审查的预期，并且要求进行非常严格的审查，否则别做那种爱发号施令的架构师。如果你有意见，我的个人意见是，如果这些意见并不重要，就不应该阻碍代码合并。
不断打断工作去修正一些无关紧要的小事，比如函数名“本可以更好”或者if语句“本可以用if else”，这真的很烦人，而且浪费时间在毫无价值的事情上。并非所有人都在意属性是否按字母顺序排序。如果你对此非常在意，那就让代码检查工具发出警告。
最终，界限在哪里，由你的团队来决定。哪些是意见，哪些需要修正？这些意见应该阻止合并，还是只有在需要进行更重大的更改时才需要修正？
代码审查之后该做什么
当审阅者审阅完拉取请求，准备将评论交给贡献者时，正是进行交流的好时机。通过共同探讨评论，两位开发者可以借此机会分享知识，澄清任何不清楚的地方，避免误解。
作为提交者，这是表达任何异议的最佳时机。如果您认为这些评论有道理，请确保下次提交拉取请求时不要犯同样的错误。
如果一切顺利，你们俩都对解决方案感到满意，那就一起去喝杯咖啡吧！
文章来源：https://dev.to/perssondennis/the-art-of-code-review-and-why-you-need-it-4b9m