代码评审最佳实践
我们已经创建了一个新的屏播，概述了一些适用于执行代码审查的最佳实践，以及Upsource如何帮助应用这些最佳实践。在这篇博客文章中，我们也转录了内容，并提供了进一步信息的链接。
https://youtube.com/watch?v=EjwD7Pi7J_0
1.自动化的一切
首先，尽可能地实现自动化是很重要的。通过使用持续集成服务器之类的工具，最好能节省人工审阅人员的宝贵时间TeamCity以确保构建编译和自动化测试通过。Upsource支持与其他工具的集成，它可以做一些事情，比如显示每次提交的构建结果，因此很容易看出，没有必要在构建失败的地方审查提交。
代码审查人员不应该担心代码是否编译或是否通过了易于自动化的标准。Upsource提供代码智能Java, Kotlin, JavaScript, PHP和Python。这意味着，当审查人员在Upsource中查看代码时，如果自动检查发现了代码中的问题，他们可以看到红色或黄色的警告。Upsource还集成了外部检查工具像SonarQube。
还有与构建服务器集成，Upsource还集成了问题跟踪器，像Jira和YouTrack，所以很容易导航到包含这些改变应该实现的细节的问题。
外包也让我们自动化大量的代码评审工作流程例如，创建评论并为其分配人员。
2.就代码评审目标达成一致
如果我们已经尽可能地自动化来确定代码的质量，那么我们就需要决定什么是有价值的，让我们的人类代码评审员去寻找。即使去掉那些容易自动化的检查，比如编译、格式化、单元和系统测试，仍然存在审查人员可以查看代码的许多不同方面。选择重要的检查将取决于团队和他们如何以及何时审查代码。例如，在功能特性实现的最后审查一个大型功能特性的设计，要么就来不及进行更改，要么就会严重延迟该功能特性的发布。
团队的目标可能是:
- 确保团队中有多个成员理解这段新代码
- 检查设计是否符合应用程序的标准
- 确保代码的质量。这不仅包括检查自动测试的存在，还包括测试是否测试正确的内容
- 识别潜在的安全问题
- 使用代码评审来尽早协作，以找到正确的方法或设计，并在开发过程中进行迭代。
无论目标是什么，团队都需要尽早识别它们，并始终如一地应用它们。请注意，许多目标可能是互斥的，因此不可能在每次代码复查中检查所有内容。
3.提交审查
假设团队有一组代码评审的目标，开发人员将希望提交他们的代码以供评审。
Upsource允许代码作者创建几种类型的评论手动，甚至可以自动化评论的创建。开发人员可以选择向现有评审添加提交，从单个提交创建一个新的审查，或创建一个跟踪整个分支的回顾最后一个选项会自动将这个分支上的所有新提交添加到这个审查中。
我们需要选择审稿人对于这次审查，无论我们的团队指导方针是什么。这将取决于审查的目标-如果审查的目标是通过某种门户或质量检查，可能会有个人或集团检查代码的专家。如果目标是与团队共享实现的细节，那么评审员可能是团队中的任何人，甚至可能是每个人。您还可以选择观察者，这表明这些人应该知道这些代码更改，但不需要对它们进行评论。
Upsource可以使审查人员的选择更容易。可以将Upsource配置为自动添加评审员或评审员组基于某些标准，比如审查的类型和代码的作者。Upsource还可以根据过去的评审历史自动推荐评审人员。
代码作者可以通过注释代码来帮助审查人员理解代码和编写时所做的决定评论。请注意，通过在Upsource中而不是在代码中留下注释，注释可能是短暂的。其目的是它们只存在于评审期间，并且它们的目的是专门帮助评审人员理解。虽然我们稍后会看到Upsource中的注释可以存在于评审的上下文之外作为一名代码作者，我们通常会使用它们与审稿人交流我们的想法。
这也是很好的练习标签注释，以便更清楚注释的目的。我们稍后会看到更多。
4.审查代码
现在，让我们看看检查代码的最佳实践。对于审查人员来说，最重要的事情是尽可能快地审查代码。代码作者很可能在等待评审的结果，而接收反馈的时间越长，就越难记住变更的上下文。
Upsource向审查人员显示这些修订是否通过了自动构建，所以如果这是绿色的，就可以合理地假设我们可以继续检查代码。
这里的问题跟踪器集成让我们一目了然地看到这些代码更改所解决的错误或特性的摘要。这可以帮助我们作为审查人员看到代码试图修复什么问题，并提醒我们检查最终结果是否是实际需要的。
Upsource还会告诉我们代码作者现在是否在线，如果他们在线，那么可能是一个检查代码的好时机，因为作者更有可能对任何问题或评论做出快速回应。
我们可以用反应回复别人的评论，作为一种快捷方式，表明我们已经阅读了他们，理解或同意(或不同意)。
我们应该在代码的相关部分附近编写自己的注释。反馈应该是建设性的，评论应该是关于代码的，而不是关于作者个人的。
审稿人用相关的标签标记他们的每条评论是很重要的，这样代码作者就可以很容易地看到这条评论是一个令人讨厌的问题，是一个需要回答的问题，还是一个不错的问题，否则作者可能不清楚该如何处理这条评论，或者它是否需要处理。
代码评审对于代码作者来说可能很困难，因为我们开发人员可能依附于我们的代码。在评论中留下积极的反馈，并指出需要做出的改变，这是一个好主意。从评审中获得优秀代码的角度来看，这似乎不是一个重要的步骤，但它是激励开发人员的重要步骤，也许还可以克服一些人对代码评审的恐惧或不喜欢。
我们也可能出于某种原因决定稍后返回一些更改，帮助我们记住我们在哪里并最好地表示我们的进展的一个好方法是，如果我们打算返回一个文件，那么将它标记为未读。
5.迭代
代码审查自然是迭代的，即使是最好的代码也应该引起注释以供阅读。Upsource向我们展示了我们的审查处于什么状态，在这种情况下，它是“开放”，这意味着审查人员仍在检查代码的过程中。
作为代码作者，可能需要使用Upsource的进程视图查看审核人员检查了多少代码。我们还可以看到审稿人当前是否在线，如果是的话，这可能是一个很好的时机，直接通过审查级别的评论联系他们，礼貌地询问他们是否可以完成审查，以便我们可以做出任何必要的更改。
作为审核人员，当我们完成了对所有更改的检查后，这是一个很好的实践表明我们已经做了所有我们要做的评论。在Upsource中，我们通过接受评审来做到这一点，如果我们对代码满意并且不需要更多的更改，或者提出关注，这意味着作为评审人员，我们期望作者回答我们的评论并可能对代码进行更改。
Upsource显示每个审阅者的结果，那些提出质疑的人会被刷成紫色，而那些接受评论的人会被刷成绿色。
作为代码作者，如果有需要解决的问题，我们应该尽快解决这些问题，就像审查人员应该尽快审查代码一样。虽然在一个人可能正在执行的任务和另一个任务(如代码评审)之间进行上下文切换可能会很痛苦，但如果评审迭代之间的时间较短，那么就不那么痛苦了，如果在编写代码和进行更改之间没有几天甚至几周的间隔，则更容易记住上下文。
如果评审是基于分支的，那么一旦我们向分支提交了新的变更，它就会自动添加到评审中，当然，一旦签入，我们的构建服务器就会编译和测试代码。
为了更容易地看到哪些评论仍然是相关的或突出的，一个好主意是让发起讨论的人解决它当没有进一步行动的时候。在这个例子中，由于我们是代码作者，我们可以看到审稿人已经阅读了我们的解释注释，我们现在可以将这些注释标记为已解决。我们可以只展示突出的讨论隐藏已解决的讨论从审查，甚至过滤标签。
当我们在评审中更改代码时，我们应该对评审人员所做的注释做出响应。我们既可以写出完整的回答，也可以用一个反应来承认这个观点。我们还应该解决已经开始的、不需要采取进一步行动的讨论。
同样，用注释、问题或想法来注释代码是一个很好的想法，这样审查人员就能理解代码中的想法，或者可能会询问建议。
当在评审中对代码进行更改时，我们可以作为评审人员再次查看它。向评审中添加新代码将重置评审人员的状态，因此他们必须再次选择代码是被接受的还是他们提出了关注。Upsource还会将任何已更改为未读状态的文件重置为未读状态，因此作为审核人员，我们知道只需要查看未读的文件，所有其他文件与上次查看时相同。
当我们解决了不需要进一步行动的讨论，并且我们没有任何其他关于代码的突出问题时，我们就可以接受评审了。
6.结束评审
评审中最重要的部分可能是理解代码何时可以运行并关闭它。如果没有这一步，作者呕心沥血编写的代码就会陷入僵局，无法为任何人提供任何价值。再次强调，团队提前决定所有评审都被认为是封闭的标准是很重要的——应该是当所有评审都接受了它，还是某个子集?如果是评审员的一个子集，哪些人接受是否重要，或者仅仅是一个数字，例如至少3个评审员中有2个?如果一个或多个审稿人提出了问题，您该怎么办?这些问题都需要解决吗?或者一些审稿人可以被专家或大多数人所推翻吗?
无论您的团队决定什么，这些标准都应该在所有评审中一致地应用。Upsource足够灵活，允许任何审稿人或作者在他们想要的时候关闭审稿，这意味着由他们来应用团队决定的规则。
一旦评审结束，这可能是合并或发布我们的更改的时候了——再次由团队决定何时完成以及由谁完成。如果项目使用Upsource与GitHub的集成，代码可以通过Upsource本身合并。
结束评审并不一定意味着所有的讨论都结束了。尚未解决的讨论继续存在于代码中，因此如果我们稍后遇到这段代码，我们可以看到这些未解决的注释，并且可能在那时我们对它们做一些事情。例如，我们可以使用它们来跟踪可能的技术债务或潜在的重构。
总之
我们已经了解了一些用于代码审查的最佳实践，以及如何在Upsource中应用它们。
尽可能地实现自动化是很重要的。理想情况下，您的代码审查工具将向您显示使用其他工具(如构建服务器)执行的自动化结果。Upsource还提供了自动化大量代码审查工作流程的能力，并且还为Java、Kotlin、JavaScript、PHP和Python提供了代码智能，因此代码审查人员可以专注于只有人工审查人员才能做的事情。
团队需要理解他们的代码评审的目的是什么，并在所有评审中一致地应用标准。这可能意味着有一个在评论中寻找的东西的清单，或者可能是一套粗略的指导方针。这还意味着知道谁负责审查应用程序的哪些部分中的代码，并说明如何决定代码审查是否完成，代码是否可以合并或发布。
在评审过程中，作为评审人员和作者，及时做出回应是很重要的，这样可以最大限度地减少他们正在处理的内容和正在评审的代码之间切换的成本。
同样重要的是，作为审查人员，要清楚您期望代码作者在响应注释时做些什么——代码是否应该更改，或者它仅仅是一个供将来学习和应用的注释?
最重要的是，代码评审的目标是让代码通过评审，并将其投入生产。审查中的代码通常是未被使用的代码，而未被使用的代码不会给应用程序或用户增加任何价值。
