作为一名初级软件工程师，我总是仔细阅读我收到的代码审查意见，以了解如何成为更好的编码人员。 但是当我开始尝试我的第一次代码审查时，我意识到我的经历并没有让我准备好在另一边。
我发展了一个严重的冒名顶替综合症病例，问题如下： 我应该评论这行代码还是不值得？ 我应该找到支持每条评论的文章吗？ 我是否会通过批准此网站来破坏网站？ 他们会恨我吗？ 好吧，我承认我的速度非常快。 但在与一些同事交谈后，我知道在我的担忧中并不孤单。
初级软件工程师可能会被抛入代码审查中，其假设类似于“你知道如何阅读一本书以便你知道如何写一本书，这是不正确的，”GitHub的经验工程师Jessica Rudder说。
代码审查会产生预期，而且这个过程可能会让人头疼。 因此，我采访了其他七位软件工程师，以收集有关如何构建审核思路的技巧。
1.考虑整体影响
通常，良好的拉取请求（PR）应该只影响代码库的受限部分。 但是，有限的范围不应该阻止您在更大的代码库的上下文中考虑代码更改。
Nigel Munoz是The Muse的前全栈工程师，也是现任自由软件工程师，他鼓励评论家思考“这种变化如何影响越来越大的图片。”考虑到更大的图景包括寻找任何技术债务 - 寻找代码这是重复的，非模块化的，或者不符合最新的标准约定 - 以及分析对代码库体系结构的修改。
哈德逊河贸易公司（Hudson River Trading）的核心开发人员萨姆·多诺（Sam Donow）认为，“没有太大或太小的评论。 对小改进的建议可能会导致代码库的多个部分得到更大的改进。“
您可以在GitHub上使用PR注释来提供正反馈，并指出代码可能与框架React的标准约定不同。
例如，在我自己的一个代码审查期间，我收到一条评论，即React组件上的某些属性令人困惑，这引发了有关如何使用该组件的更广泛的问题。 最后，我从原始组件中删除了属性，并创建了一个单独的组件来阐明每个组件的行为，并确保两者都可以在更多地方使用。
2.考虑安全性
不要忘记，某些更改可能会影响代码库。 Rudder建议评估用户是否“可以使用此功能来骚扰某人或可能滥用系统。”例如，如果pull请求中的新功能包括用户输入，请查找SQL注入，数据访问，跨站点脚本和其他安全漏洞。
3.专注于Bug
你的代码贡献者 - 无论他们看起来多么机器人 - 都是人类，人类可能会破坏或忘记功能。 因此，请确保“检查与其他代码具有相同重要性的测试”，教师薪酬教师的技术负责人Abhishek Pillai建议道。 “他们将防止新的错误，并作为一种文件形式提供给将来为此工作的其他人。”
阅读测试可以帮助您了解新功能的功能并查看它将引入的不同情况，而分析测试可以帮助您指出丢失的案例并找到此PR中未包含的功能。 如果代码更改中没有包含测试且它们看似相关，则在审核中请求它们是合适的。
但测试不是一切。 “不要过分相信系统，”Donow警告说。 “仅仅因为测试运行并不意味着没有错误。”
您可能还想“在本地运行应用程序以对其进行功能测试并确保其正常运行。 如果它不起作用，那么进一步审查是没有意义的，“8th Light的软件开发人员Ryan Verner说。 虽然一些评论者认为手动测试不应该成为代码审查过程的一部分 - 部分原因在于它花费的时间--Verner认为这是一种快速的方法来确定是否应该投入更多时间进行审核以及帮助缩减的策略bug积压的增长。
4.成为团队合作者
在审查代码时，陈词滥调具有新的含义。 “花点时间进行审核，因为它是每个人的代码库，”Verner说，他提倡“集体所有权”。作为审稿人，你应该努力保护积压的臭虫不再变大，目标是给予你团队减少了工作量。
Pillai使用GIF来庆祝他的队友批准和准备合并的PR。
与此同时，The Muse的技术负责人Charles Luxton鼓励审稿人理解并记住团队的优先事项。 随着快速接近的截止日期和分歧很多，有时会为积压创建一个待办事项，以确保将来会有所改进，同时对相关代码发表评论就是你需要的创可贴保持团队快乐。
最后，问问自己代码是否对刚刚加入团队并在最初几周内阅读的人有意义将有助于保持代码的可读性和可理解性。
5.使用学习和知识共享过程
审核流程让每个人都有机会更深入地了解代码库，语言，框架和最佳实践。
The Muse的技术主管Matt Jeffery建议审阅者“在架构上理解变化。一种方法是读取文件名，因为它们有助于提供上下文。例如，如果您正在查看数据访问层的更改你知道你没有处理业务逻辑或用户界面。“
您可以在GitHub上使用PR评论来共享文档。
当您从代码更改中学习时，您还有机会分享知识。 “最好解释一下你的观点并用文档来支持它，”Luxton说。 您提供的支持证据和值得信赖的文章的链接不仅有助于审稿人和代码编写者在做出最终决策时探索不同的方法，而且还可以增强他们对编程的了解。
虽然您记住了这些提示，但请记住，审核是锻炼员工技能的时候。 “让人们怀疑他们是否考虑过他们的方法，并指出不同的可能性，同时试图消除防御性，”鲁德说。 “我总是留下评论和总结评论 - 这里有什么是好的，这里有什么可以改进，这里是合并之前需要改变的东西。”
使用这种方法，您不仅可以保护您的代码库免受技术债务，安全威胁和错误的影响，而且您还将构建您的团队。
