如何提供优秀的代码审查
这篇文章最初发表在我的博客上。
要提供出色的代码审查，您需要知道为什么要进行代码审查。
我们为什么要审核代码？
我们都知道代码审查很重要，但为什么呢？他们可以捕捉到一些错误并防止可怕的设计决策投入生产，但这是他们唯一的功能吗？
根据我的经验，一个伟大的代码审查有三个重要目标：
- 通过不断变化的代码库使团队保持最新状态。
- 提高项目质量。
- 为开发人员提供反馈。
及时了解不断变化的代码库
提供代码审查会迫使开发人员阅读他们自己无法处理的代码部分。这提高了团队对代码库的整体了解。结果，任务规划变得更加顺利，并且时间/复杂度估计的准确性增加。
I.首先找出原因
为了能够理解代码更改，您必须首先了解它的原因。
我们大多数人都使用某种问题跟踪系统。确定与此代码更改相关的问题/故障单，并仔细阅读，包括注释。如果有，请阅读拉取请求的描述。这将为您提供必要的上下文，不仅要了解更改本身，还要判断更改是否符合要求。
例如，没有上下文，硬编码点作为数字的小数分隔符对于您的仅限美国的应用程序来说似乎是合理的，但是如果您阅读该票证，您就会知道您的公司正在扩展到其他国家/地区，现在用户的区域设置需要是参与选择小数分隔符。
如果没有问题/票证，也没有PR描述，请记下您自己的描述并将其作为审核的一部分包含在内。如果你误解了目的，那么评测者可能会指出这一点。
II。读，不要撇去
不要满足于简单的“看起来对我好”。当你浏览它时，所有格式良好的代码看起来都很好您想要阅读更改并真正理解它们。是的，这很难。是的，这需要更多时间。是的，这是值得的。它还将增加您捕获不那么明显的项目质量问题的机会。
提高项目质量
在生成代码之前，让第二副眼睛查看代码是捕获一些错误并确保代码可维护的好方法。
III。始终运行代码
一线改变？运行代码。只是CSS改变？运行代码。翻译？跑。 THE。码。
不要自欺欺人地认为每个人在做出每一次改变后都会编译并运行项目。我们应该……但我们不应该……你知道，那些你离开办公室之前只剩下5分钟的时间，而你只有一个微不足道的变化要做，但你没有时间来验证它。
确保项目仍然可以编译和运行而不会抛出异常，这是您作为审阅者所能做的最少的事情。这是一个简单的健全检查。所以你应该这样做。
如果引入了任何用户可见的更改，请确保您亲眼看到它们。单击新的UI组件。
运行测试。是的，我知道CI应该这样做。但也许有一些片状测试会偶然传递CI？或者也许只有一个bug出现在你的macOS上，但是CI正在运行Linux？也许有人没有按照测试文件的正确命名模式，测试运行器完全忽略了该文件？
这些更改是否包括数据库迁移？通过回滚结束您的审核流程，结账 主 并检查项目是否仍然运行。
IV。不要挑剔
有人插入两条空行，他们只应插入一行？别提它。审核员耐心解决您的代码所遇到的问题是有限的，您不希望将其浪费在琐碎的问题上。
相反，尝试找到一个自动解决方案，确保自动检测所有这些微不足道的细节，并建议您的团队开始使用它。
V.关注无法自动检测的可读性问题
一旦您的自动化工具验证了函数名称长度和正确的缩进，您就可以专注于只有人类可以捕获的重要内容。
这些函数/变量名称对你有意义吗？他们是否一直使用项目的词汇？他们会混淆吗？有没有含糊不清的缩写？
有趣的故事：我曾经花了10分钟时间相信我正在处理的应用程序有一个功能，其中允许访客用户（付费用户邀请的非付费用户）邀请更多访客用户，因为有人将变量命名为变量 sub_guest 代替 subscription_guest。
为开发人员提供反馈
良好的反馈是反馈，强化了某人的良好习惯，并有助于注意和消除不良习惯。为了让您的反馈产生任何影响，您需要确保收听您的意见。
VI。总是说点好话
我不在乎代码更改有多么微不足道。你总能说些积极的话。正反馈越具体，越好。
如果你之前从未这样做过，可能很难想出一些东西，所以这里有一些通用的灵感示例：
做得好我尽力在您的代码中找到错误，但不能。
感谢您解决这个错字，我不知道这是该单词的正确拼写。
我喜欢你如何命名这个功能。它立即显而易见。
哇，那很整洁。我不知道我们的编程语言/这个框架/这个库的这个特性。
我喜欢你在新文件中添加了所有这些新代码。将它放在现有文件中很诱人，但这会使现有文件太大。
如果你因为欣赏琐碎的事情而害怕愚蠢，那么问问自己在接受代码审查时的感受。你兴奋吗？或者你害怕它，因为你知道在最好的情况下，它将是中立的无声批准，但在最坏的情况下，它将充满严厉的批评？你真的希望你的同事害怕接受你的评测，因为你害怕听起来很傻吗？
积极反馈的另一个重要作用是，它使审核员对您的负面反馈更加开放。
你是否有一个家庭成员利用他们看到你抱怨你的每一个机会？你再次增加体重，你的兄弟姐妹赚的钱比你多，你应该多笑一点……你有多大可能真正认为他们的抱怨是有效的点，这会激励你自己提高？一点也不？好吧，几个月来只收到来自同一个同事的负面反馈，感觉是一样的。
七。避免使用判断力和专横的语言
停止听到判断和专横的最简单的方法是假设你错了，而且审稿人是对的。然后提出问题，帮助您了解自己错误的原因。毕竟，他们可能花费了更多的时间来处理这些代码，而不是花在审查它上面。他们更有可能了解细节。
不要说“不要这样做，那样做”。你不希望在你的同事中培养遵守命令的能力。你希望他们创造性地和批判性地思考。此外，没有人喜欢被抛弃。
相反，说“你会怎么想……”。表示您对对话开放。如果参与决策，人们就会更有动力做某事。
不要说“你为什么不……”。这句话表明你的解决方案是显而易见的选择，而且审核人员因不使用它而愚蠢。它可能引发一种防御反应，这将使聪明而合理的人热情地捍卫一个有缺陷的立场。
相反，说“你考虑过……？”，解释为什么你的解决方案在这种情况下会有利，并采取友好的邀请来证明你的错误，例如： “……或者我错过了什么？”
现在，我并不是说你实际上总是错的。但你绝对不是总是对的。这种方法可以让你和评测者更容易承认，当你们两个人都错了而不丢脸。
GitHub PR评测
GitHub具有一项功能，允许您将拉取请求审核标记为评测，接受或请求更改。
除非我绝对肯定某些事情需要改变，否则我倾向于避免要求更改。要求改变是专横的语言，并没有留下太多的辩论空间。在我的所有问题都得到解决之前，我会做评测评测，然后接受。
摘要
伟大的代码审查需要时间，但它们不仅会改善您的项目，还会改善您对项目的了解以及您与团队的关系。
记得：
- 及时了解不断变化的代码库
- I.首先找出原因
- II。读，不要撇去
- 提高项目质量
- III。始终运行代码
- IV。不要挑剔
- V.关注无法自动检测的可读性问题
- 为开发人员提供反馈
- VI。总是说点好话
- 七。避免使用判断力和专横的语言