代码审查是一门艺术。尽管大多数公司都会进行代码审查，但只有少数公司充分利用代码审查带来的潜在好处。在本文中，我们将了解您和您的团队可以采取哪些措施来充分利用他们提供的潜力。
代码审查是一项团队活动
代码审查的第一条规则是，代码审查涉及整个团队。每个人都是不同的，开发人员对代码有不同的看法，对代码审查的期望也不同。每个人受到的批评也不同，有些人比其他人更敏感。
为了确保整个团队都同意如何处理代码审查，您可以执行以下两项操作之一。要么召开一次会议来讨论期望，要么降低正式程度，并在第一次进行代码审查时与团队开始讨论。如果您在第一次代码审查时提出它，您可以对您的评论非常严格，并且仍然看起来像一个有爱心的人。
当您讨论代码审查时，尝试解决您认为重要的问题。代码审查应该是为了发现错误，还是应该评论改进和意见？如果你鼓励提出意见，这些意见是否应该被强制修正还是可以被忽略？
讨论并达成每个开发人员都同意的协议，但尽量避免创建明确的检查清单。使用清单，可以很容易地让开发人员检查每个项目，然后认为他们已经完成了代码审查，而根本没有真正反思解决方案。
为什么要进行代码审查？
从经理的角度来看，代码审查通常都是为了发现错误并确保提交的代码在测试人员测试时不会受到影响。对于我来说，作为一名开发人员，代码审查的主要目标不是阻止错误，而是让更多的人参与解决方案，并发起对替代解决方案和知识共享的讨论。从长远来看，这才是真正提高产品质量并使开发人员编写更少的错误修剪代码的原因。
如果您正确进行代码审查，它们可以在许多方面为您的团队提供帮助。这些只是代码审查可以帮助您获得的一些好处。
- 在提交之前反思你的代码
- 了解并反思其他开发人员的代码和意见
- 教导和帮助其他开发人员
- 协调团队对产品及其代码以及新添加的代码的看法
- 更好地了解完整的代码库
- 阻止错误的出现
- 提高代码质量
- 提高测试质量
- 减少技术债务
- 增强的文档，具有更清晰的提交和更好的注释
- 识别安全问题
- 在代码审查期间（而不是两周后）修复问题可以节省时间
- 建立团队
列表中的最后一点是很多人忘记的，但仍然是最重要的一点之一。良好的团队沟通对于各种业务和发展都至关重要。代码审查是让团队共同成长的绝佳方式，因为它可能会引起冲突，任何了解团队建设或冲突管理的人都知道冲突对于团队的卓越是必要的。
为什么你不应该进行代码审查
不诚实地进行代码审查的原因并不多。是的，这确实需要时间，但从长远来看，你肯定会得到那段时间的回报，并享受它带来的所有好处。
想一想。如果您创办了一家科技公司并聘请了开发人员。您是否希望任何人推送任何代码而没有人查看他们推送的内容？您是否会依赖一个任何人都可以做出贡献但没有人审查所提交内容的开源项目？
如果您对这些问题中的任何一个的答案是否定的，或者如果您想建立一个更好的团队并提高代码质量，那么代码审查适合您。
代码审查之前应该做什么
代码审查并不是从拉取请求开始的，在此之前，无论是提交代码的开发人员还是要审查代码的人都需要完成某些事情。
作为一名编码员
在一个不同的团队中，总是有架构师检查整个团队的代码，但也有一些快节奏的开发人员，他们从不仔细检查代码，并盲目地使用他们的两个字符别名“git add . && git commit -”来推送他们的代码。 m“保存”&& git 推送”。
当提交代码进行代码审查（甚至没有代码审查）时，那些仓促的开发人员应该尝试更像架构师。在提交代码之前始终应该完成的一些事情是：
- 保持提交较小，在提交中只应实现一个故事/任务。这样，团队成员可以更轻松地进行审查，并且在有疑问时更容易跟踪进行更改的原因。
- 不要在提交中包含与您正在处理的任务无关的代码。如果您修复了与您的任务无关的内容，请在任务之前或之后的另一个提交中提交它。
- 您的提交是否包含临时代码？在提交之前尝试修复它。如果不可能，请用 TODO 注释进行标记，并计划何时跟进。
- 您的提交是否包含复杂的解决方案？为需要的部分写下注释。
- 在推送之前先检查一下你的代码。即使您已执行上述所有步骤且没有遗漏任何内容，您也可能会发现代码的改进或实现解决方案的其他方法。
- 手动测试您的代码。如果您还没有编写任何测试，请编写这些测试。
首先，完成上述所有操作后，您就可以提交代码并请求代码审查。完成后，就该喝另一杯咖啡了！
作为审稿人
作为审查者，代码审查的主要工作显然是审查代码，但在这样做之前，请确保做一些事情。
首先，确保开发人员已完成开发并且已编写所有测试。不要审查部分完成的工作，除非它不是为了帮助另一双眼睛。部分完成的代码可能会发生变化，特别是在尚未编写测试并且可能会发现错误的情况下。
其次，与开发该功能的开发人员交谈以了解提交的内容。最好将拉取请求和功能摆在您面前。这样做将使代码和开发人员的推理更容易理解。
最后，在查看拉取请求之前，您可以考虑如何实现该功能。这是练习解决问题的一个很好的做法，因为你们都会自己想出一个解决方案，并且可能会看到同一问题的替代解决方案。如果幸运的话，拉取请求的开发人员以另一种方式实现了该功能，这将使代码审查变得更加有趣。
代码审查期间应该做什么
提出拉取请求后，就该对其进行审查了。这项工作主要取决于审阅者，但即使是代码贡献者也需要考虑一些事情。
作为一名编码员
作为拉取请求的开发人员，您通常可以坐下来放松，而审阅者则焦急万分。为了让审稿人的工作更轻松，请确保可以回答问题。如果审阅者和您不太了解，请务必提及您可以回答问题，以便对方敢于提问。
作为审稿人
审查大型拉取请求需要时间。作为审阅者，重要的是要记住，花时间而不是强调它是值得的，花一点时间回顾一下本文开头关于为什么进行代码审阅的部分。然后抓住作为开发人员成长的机会。
对于大于单行提交的任何内容，请务必在 IDE 中检查拉取请求的代码。这使得跟踪代码中的链接以及搜索函数和变量的用法变得更加容易。它还允许您发现开发人员应该完成但错过的更改，例如，如果在多个位置调用一个函数，但开发人员仅在一个位置更新了它。
在写评论时，要清楚你的意思。如果这是一个意见问题，请确保你的回答有动机。除了当你办公室的咖啡机决定煮一杯“无效咖啡”时，没有什么比固执己见的评论评论更烦人的了，而且没有以自信的“我是建筑师”的态度发送解释。
谈意见。不要成为那个专横的架构师，除非您的团队还没有讨论代码审查的期望并要求进行非常严格的审查。如果您有意见，我个人的意见是，如果不重要，他们不应该阻止合并。
不断地中断工作来修复可以说是不重要的东西，比如“本来可以更好”的函数名称或“本来可以使用 if else”的 if 语句，这确实很烦人，而且把时间花在相当无价值的事情上。并不是每个人都关心属性是否按字母顺序排序。如果你对此有强烈的感受，请让 linter 抱怨它。
最后，由您的团队决定线路的走向。有哪些意见以及何时需要修正这些意见？它们是否应该阻止合并，还是只有在需要进行更严重的更改时才需要修复它们？
代码审查后该怎么做
当审阅者审阅了拉取请求并且需要将评论移交给贡献者时，这是讨论的好时机。通过一起查看评论，两位开发人员可以一起分享知识，整理任何不清楚的评论并避免误解。
作为提交的作者，这是表达任何反对意见的最佳机会。如果您认为这些评论有道理，请确保下次推送拉取请求时不要犯同样的错误。
如果一切看起来都不错并且你们都对解决方案感到满意，那就一起去喝杯咖啡吧！