对于很多公司来说，代码审查是开发人员日常工作的重要组成部分。通过codereview可以及早发现项目中的问题，促进同事间的沟通交流，在讨论中迸发出智慧的火花。但要成功实施代码审查并不是一件容易的事。为什么要进行codereview，什么时候做，怎么做，是摆在我们面前的三个重要问题。针对这三个问题，开发者LisaTjapkes写下了自己的经验和教训。在我最近的项目经验中，我们进行了广泛而正式的代码审查。这个过程大大提高了项目的代码质量，减少了项目中新特性开发的等待时间，也促进了整个团队之间知识的传播和共享。我还发现代码审查不会减慢项目开发速度，反而会提高开发人员的工作效率。CodeReview的好处我们发现CodeReview给项目的各个阶段带来了很多好处：如果您有代码，您可以获得当前开发人员的反馈。随着项目的推进，我们会不时地在团队中加入新的开发人员，代码审查可以大大减少这些新人的熟悉时间。特别是，我们允许新来的开发人员充满信心地开发新功能，因为我们可以在合并之前审查代码，并对他们编写的任何代码提供有价值的反馈。对于我们的分布式团队来说，codereview比较实用。团队协作将对构建协作环境有很大帮助。我们可以立即提出想法，讨论它们，然后发展它们。虽然我们因为不在同一个地方而失去了一些东西，但我们通过在代码审查过程中进行深入讨论而有所收获。高效代码审查的技巧如果处理不当，代码审查可能会导致项目延迟。使用正确的工具和技术可以避免在审查上浪费大量时间并提高代码质量。使用功能分支实践的好处是不言自明的，但它为代码审查提供了更具体的好处。功能分支意味着您可以隔离需要审查的代码，使其仅与特定功能相关。当代码准备好接受审查时，功能分支还允许快速上下文切换。您可以在审查当前代码时切换到新功能，如果您需要讨论对已审查功能的反馈，则可以快速切换回来。将审查分成小的修订比大的修订花费更少的时间来审查。在review一个大的change的时候，不仅要看很多行代码，还要看很多依赖的代码才能真正理解。结果是审查代码所花费的时间与更改的代码量之间没有线性关系。将要审查的代码隔离成小的修改可以减轻审查者的精神负担，并使审查过程更加顺畅。使用专为代码审查而设计的工具似乎很简单，但它非常重要。一些重要的特性包括差异、逐行注释更改的能力，以及在对审查的代码进行更改时通知人们。我的团队使用GitHub来管理项目代码，并使用GitHub的拉取请求功能来管理代码审查。使用非常复杂或过于结构化的东西可能不需要清单，如果突然出现什么东西，使用清单可能是个好主意。诸如“添加更多评论”之类的建设性输入似乎毫无意义，也不是很有帮助。如果某个接口没有注释，可能会有专门的文档来解释。如果发现不合理之处，必须明确指出，以确定设计是否可以改进或是否存在逻辑错误。专注于实际理解代码的行为，并确保其他人在需要维护代码时能够快速理解代码。每个人都参与即使是最有经验的架构师或明星开发人员也会犯错误。因此，***每个人都可以参与代码审查过程。尤其是对于很多初级开发人员或者刚接触项目的开发人员来说，这也是一个非常好的学习机会。有一个审查过程一开始，我们的项目没有正式的审查过程。我们只是打开一个pullrequest，等待有人审查它，最后有人会合并更改。这种工作方式非常低效，有时几天都没有人审查一个pullrequest，有时其他人在一个人提供反馈之前就合并了请求。此外，一些开发人员审查的代码明显多于其他人。总而言之，没有流程使我们效率极低。***我们认识到这一点，并创建了一个正式的结构来指导如何进行代码审查，从而加快了审查过程。一个审查过程至少应该包括以下几点：如何将审查任务分配给不同的人期望审查者给出反馈的最晚时间如何确定审查已经完成谁负责合并审查过的代码进行代码审查？我认为代码审查对很多项目来说是一件好事，但它不是一个通用的解决方案。代码审查适用于以下项目：至少有5名开发人员在团队分布的团队中添加新开发人员时当团队中的某些成员在代码库设置约定和最佳实践阶段不熟悉当前技术堆栈时，相反，在以下情况下，codereview不会为项目带来更多的附加值：处理维护代码而不是添加新功能团队小而紧密
