BOB体育类似网络研讨会录制：“代码审查最佳实践”
我们的网络研讨会“代码审查最佳实践”的录制现已在Jetbrains YouTube频道上使用。
在过去，我们已经了解了代码审查中要查找的内容和外包中的代码评审最佳实践在本网络研讨会记录中BOB体育类似，我们暂停回到我们试图通过我们的代码审核来实现什么，因此我们可以最大限度地提高代码审查的价值并最大限度地减少疼痛。
https://youtu.be/a9_0UUUNt-Y
关于演示者：
特里沙为各种行业开发了Java应用程序，包括所有尺寸的公司的财务，制造，软件和非营利性。她在Java高性能系统中拥有专业知识，是关于使开发人员的生产力和开放源开发的开发服务的高度热情。Trisha是一个Java冠军，是一个开发商倡导Upsource和Intellij Idea。
问答
正如所承诺的，以下是Trisha对网络研讨会期间未回答的问题的回答。
问：如何让开发人员看到代码审查是有用的？
如果你已经在做审查，而开发人员认为他们没有帮助，那么你需要了解审查的价值，并确保团队也理解审查。您可能需要调整审查流程，以便它提供该价值。还有一种可能性是，如果你在做评论，而开发人员不认为它们有用，那么它们实际上可能没有用处——退一步，找出哪里出了问题。
如果您还没有进行代码评审，那么说服开发人员代码评审是件好事的最好方法就是确保他们从中得到一些东西。例如，你可以专注于学习方面。评审的目的是“分享知识，相互学习”。通过这种方式，评论者从代码中获得了一些东西（他们学到了一些东西），而作者从代码中获得了一些东西（他们教了一些人）。一旦代码评审成为流程的一部分，并且开发人员从中获得了价值，您应该开始看到质量/可读性的改进。在这一点上，如果需要，您可以调整流程目标。
问：在代码审查工具中是否有助于输出Sonar？或者它只是添加噪音吗？
是的，我认为作为审查流程的一部分，可以从自动化工具输出有用。例如，Upsource显示了Teamcity构建的结果- 以这种方式，审阅者不会浪费时间审阅不编译或失败测试的代码。
与静态分析工具类似，它可以避免手动检查这些内容，或者如果某些结果是意见问题，则审阅者可以对修复问题是否有价值或是否没有那么重要发表评论。
问：我听到关于注释的不同观点，为什么有人说注释应该是无限制的？
我相信您应该在代码审查评论的背景下将您的代码作为作者注释，而不是代码评论，例如代码评论。评论upsource.不是Java中的注释。您可以解释在选择特定设计/方法时考虑了哪些方面，以及您意识到的权衡。这可以减少审阅者可能对代码提出的问题的数量，因为他们不需要对您所考虑的内容进行假设。
有些人不喜欢注释，因为代码应该是“自我记录”，应该从代码中清楚的是它在做什么。我同意，但代码应该说什么它正在做，而注释可以说为什么？你选择了那样做。
问：我们如何防止明显的规则突破？
这就是自动化的用武之地。有很多静态分析工具可以检查诸如格式、常见错误、使用错误的习惯用法、在错误的地方使用错误的语言（例如，您可能用于测试的语言，使其成为生产代码）。
问：初级开发人员在进行审查时是否也应该把关？他们可能缺乏经验。
当然，“这取决于”。如果传递审查的标准是“甚至是小辈可以了解代码”，那么，当然，她/他可以成为守门人。但通常情况下，正式的网关审查是准确的，因为它需要成为代码的高级人员。
可能是可能的 - 如果小辈或整个团队或某些子集进行了研究代码，提出建议和改进，那么看门人（大概是一个繁忙的高级人员）需要更少的工作they only need to make suggestions based on things others haven’t thought of yet.
问：网关审查模式中是否存在潜在的权力不平衡（例如，间接歧视）？如果这是使用的审查模式，你对如何解决这个问题有什么想法吗？
是的，肯定存在功率不平衡的可能性。这就是一些反模式出现的原因，如果把关人总是在寻找问题，希望说不。解决这个问题的一种方法是让多个评论员彼此诚实，或者你可以轮换评论员，这样负担就不仅仅是一个把关人。同样重要的是，守门人也要审查他们的代码，以帮助他们理解被审查的感觉。
我们经常认为，守门人责任通过精心完成所有代码，找到每个潜在的错误，并确保在批准之前修复所有内容。但是，我相信，守门人应该检查代码已被检查（由自动化工具，由作者的同行），这没有任何明显的错误。他们的工作应该要批准它，而不是阻止它。
问：您如何处理激进/无益的代码审查？
有明确的审查目标和审查过程应该a）预防无益的准则审查和b）当审查员正在激进或不公平而非遵循目标时突出显示。还有一个以上的审稿人可能会有所帮助（请参阅最后一个问题）。
如果制定所有规则的人同时也是进行所有审查的人，那么就会出现问题。在这种情况下，您可能需要与此人坐下来，让他们了解您的担忧，并对审核目标有一些明确的认识，或者您甚至可能需要外部帮助或与此人的经理交谈。请记住，代码审查应该帮助代码进入生产，而不是阻止用户使用代码，您可能需要提醒没有帮助的审查者的经理这一事实。
问：谁应该解释/展示代码？写这篇文章的人还是做评论的人？
我原以为代码作者会浏览代码并将其展示给审阅者，但实际上，您提出了一个很好的观点。肯定有一个用例供评审员在作者面前浏览代码，看看他们是否正确理解了代码。我想我会建议，如果审查人员的经验较少，让他们向作者介绍代码可能会很有趣，这样他们就可以检查自己是否正确理解了代码。对于代码作者来说，这可能是了解他们的代码是如何被读取和理解的一个好方法。
问：代码审查的消息是否有特定的格式/语气？有什么需要避免的吗？
是的，你应该很好！我认为一个很好的基本指南并没有说出你不会对一个人的脸说的话。When writing comments, try to think about the person who’s going to read them (and how they might “hear” it) and when reading comments try to bear in mind that the commenter is (probably) trying to help and may have been short on time when they wrote it.
是建设性的，具体。清楚你的问题/问题是什么，清楚你想要读者做的事情 - 回答这个问题;做出改变;不要改变，但学习未来等
如何在没有自动测试的情况下对大型项目进行代码审查？
如果您没有自动测试，那么您真的需要代码审查！事实上，像这样的项目可以使用代码审查过程来关注您想要更改的内容，并在修复每个bug和每个新特性后进行更改。例如，每个代码审查都应该有一套自动化测试套件，并解决一些技术债务（例如，可能分离业务逻辑和基础架构代码）。
在这一点上推销业务可能会很困难，因为您可能会发现这些代码审查开始减慢流程。如果你可以试着做一段时间的代码审查（也许3个月？），你应该开始看到质量的提高（例如减少bug），这将有助于人们继续进行代码审查。
问：您如何在一对成对的经验中包含偏远工人？
我认为你必须满足于一些非常优秀的屏幕共享工具，特别是任何一个用户都可以控制光标。如果不能共享控制权，你基本上就有了一个司机和一个无聊的领航员。
您也可以尝试一个非常轻量级的代码审查过程，类似于配对，如可能每半天审查。当然，这与在桌子上进行对话是不一样的。如果有人对这个问题有替代答案，我很想在评论中听到他们