代码审查
代码审查
这是我的 初级开发者日记 博客系列的第五篇文章。我每周都在写更多，你可以在我的网站 上注册收听更多并阅读以前的帖子。
参与代码评审是我职业生涯中最有趣的学习经历之一。我做了一些非常愚蠢的事情，在过去的两年里，我参与了 400 多条评论，从中我学到了很多。他们可以教你很多关于你自己和你的代码的东西，今天我很高兴告诉你更多关于他们的事情。
那么什么是代码审查，真的是？代码评审是讨论和辩论代码的时间，这些代码将由团队继续前进。团队的一个或多个成员将编写代码，团队的其他成员或子集将确定代码是否符合标准，从而为代码库增加价值。
从更微观的角度来看，代码评审是一个抽象的概念，指的是当你完成一项任务时，对方法和代码进行评审的过程。在我看来，代码审查有两个不同的阶段。
所以，你已经花了几个小时或几天阅读现有的代码，了解那里有什么，数据如何流动，以及你需要做什么改变。在这一点上，你大概有 20%的投入。从这里开始，你向上级提出你的改变。首先，他们会尊重你在打扰他们之前所做的工作(他们的时间有时有点宝贵)，其次，凭借你的知识，以及他们也可能拥有的知识，他们将能够与你就方法进行讨论，可能会建议一些小的调整，甚至要求你重新开始(抱歉，但这发生在我们所有人身上)。
一旦决定了，就该写代码了。这将把您带到主要的代码审查，此时您大约完成了 90%,这实际上只是就代码设计和其他一些事情达成一致的问题。
作为提交者
因此，让我们来谈谈创建伟大的拉式请求(PR)的关键技巧，这是审查代码的现代机制。
首先是用你的 PR 讲一个故事。你已经花了所有的时间去思考它，但是评论者没有。所以告诉他们你的思考过程，然后描述你实现它的一系列逻辑步骤。作为评论者，我关注两件事:你的提交日志和你的公关描述。
您的提交应该是采取的一系列步骤。所有代码都应与其各自的单元测试配对，并且每次提交都应遵循以下规则:
- 用一个空行将主题和正文分开
- 将主题行限制在 50 个字符以内
- 大写主题行
- 不要以句号结束主题行
- 在主题行中使用祈使语气
- 在 72 个字符处换行
- 用身体来解释什么和为什么以及如何
更多细节可以在 Chris Beams 的博客上找到。你应该读一读。
因此，一旦您有了逻辑提交，没有“从主服务器合并”或“修复”或“尝试一些 fbdifha ahhh”提交，我们就可以开始审查了。PS，一旦你准备好开始准备提交，使用交互式 git 重置和软 git 重置可能会对你有所帮助。
现在，公关描述。在我看来，这应该包含几样东西
- 你正在解决的原始问题的链接(如 GitHub 问题或 JIRA 门票或其他)
- 思维过程概述
- 你如何在本地进行测试(例如“我运行了这个服务和 X 服务，并使用 cURL 来确认新的请求行为是否如预期的那样工作”)
- 你认为你可能会打破这个公关(但你已经检查了它没有)
- 你想让评论者具体评论什么(比如类名，代码的时间复杂度，等等)
一旦你这样做了，评审者就能够快速地跟上代码的速度，并关注代码的质量和影响。接近团队中的一个成员，也许是两个，要求进行代码评审。尽量确保是在整个编码过程中没有给你太多帮助的人，这样你对代码就有了一个新的视角。
最后，在你提交你的评论之前，做你自己的。检查，我的提交看起来对吗？我有没有留下调试代码？我有没有在任何测试关键词中离开(我总是在 rspec 的焦点中离开)。代码是否与我预期的有所不同？这 90 秒的检查可以让审查者避免一大堆混乱。
作为评审者
我必须向代码审查者指出的最重要的一点是审查代码是工作。这是给公司增加价值，虽然这可能不是你的任务，但也同样重要。团队已经决定由提交者完成的工作足够重要，应该马上完成，所以你应该这样对待它，并真正拥有它。
所以，花点时间进行代码评审。花很多时间审查代码是可以的，把它作为你正在做的事情说出来也是可以的。仓促的代码评审将来只会反过来咬你一口。你可能是下一个在那个领域工作的人！
在开始阅读代码之前，请确保点击提交和 PR 描述以获得更多的上下文信息。如果评论者有问题，也要回答，慢慢来。如果您不确定代码是否真的能工作，那么检查一下分支，并尝试按照步骤来重现测试。记住；如果有疑问，请查看。
现在，如果你发现自己对款式吹毛求疵，请扪心自问，为什么验绒员没有发现这一点？这是一个可以添加的新规则，还是我可以教给编码人员的东西？请记住，代码审查并不是真的可以由工具自动检查的东西，例如 SwiftClean 、 Credo 、 FindBugs 、 Rubocop 或 StyleCop ，所以请确保您的代码拥有这些，并且它在您的 CI 上运行，如果发现任何违规行为，则编译失败。
现在，这个代码评审阶段可能有一些迭代。新的变更需要在现有变更的背景下重新审核，这可能会促使更多的必要变更。保持耐心，也鼓励提交者保持耐心。代码审查也是一个“离线”的好时机，鼓励白板或结对编程会话来讨论他们代码中的任何主要缺陷，或者做一些指导/辅导。理想情况下，来自同一个人的代码评审不应该包含相同的缺陷。
这就是代码审查。总之，作为一个提交者，计划，讲述故事，并把审查作为一个学习经验。作为评审者，放慢速度，仔细检查，尽可能自动化，并抓住机会改进你的团队。
祝你好运！有什么问题吗？我很想听听！
这是我的 初级开发者日记 博客系列的第 5 篇帖子。我每周都在写更多，你可以在我的网站 上注册收听更多，阅读以前的帖子。
