准备好以开发人员的身份进行代码审查了吗？

我在这里寻找一些想法。

我阅读了这篇文章，《如何进行代码审查和代码审查》有什么好处？这些信息非常有用，但是我仍然需要在下面的问题上更加清楚。

我的问题是

1. 作为目标开发人员，您能否建议开发人员在审查其代码之前可以采用的一些最佳做法。

   • 目前，我练习以下方法

     • PPT逻辑流程
     • 详细评论。

问题：即使我已经实施了上述做法，但它们对审核没有帮助。我面临的问题是，当引用某些逻辑时，我一直在寻找实现和流程，并且在过程中浪费了太多时间，并且引起了人们的注意。

我认为很多开发人员也会经历我正在经历的事情。

因此，根据所提供的OP的详细信息，听起来好像是这样的问题：“我如何学习自己的代码，以便在被要求查找X或解释Y时，我能够快速做出响应。”

我能想到的一些建议：

• 编码时，您需要花时间学习和理解自己的代码。这可能就是您的TL试图用很少的几句话传达给您的内容。作为当前项目的TL，在过去的11个月中，我已经进行了很多代码审查，而且我确实注意到一些开发人员在我们自己的代码库或其他地方（例如Google等等）并将其复制/粘贴到其中。就我个人而言，我无法忍受，因为尽管他们的代码通过了简单的单元测试，但他们不了解它的实际作用，因此我们永远无法保证存在某些边界情况或可能发生的预期故障情况。

• 作为先前声明的必然结果，如果您必须复制/粘贴，请尝试仅复制/粘贴您先前编写并理解的代码。借用别人的想法当然是可以的，但是在这种情况下，请逐行重写他们的代码，因为在编写代码时，您将更好地理解它的作用。如果您使用的是外部API，即使您有使用该API的示例，也要花几分钟来查找参考，并了解该API的工作原理。不要仅仅假设如果它曾经起作用过，它也会在您遇到的情况下起作用。

• 阅读并学习热爱DRY原理。很多时候，您试图复制/粘贴的内容可能会放在一个公共位置（单独的函数，单独的类，单独的库...）

• 阅读，学会爱SOLID原则和，而你在它，回顾KISS这是已经被mouviciel提及。这些原则都是针对产生非常简洁，干净和模块化的代码。如果您在其中具有大型类和大型函数，则查找内容显然会变得困难得多，此外，还要尝试解释代码的作用。另一方面，如果您遵循（或至少尝试遵循）SRP，并使每个类/函数仅负责一件事，那么您的代码将很小且可读性强。

• 拿起一份清洁代码。很好的书。它讨论的是编写易于解释，易于阅读，维护和扩展的代码。如果您练习编写易于阅读的代码，那么在代码评审中阅读自己的代码就不会有问题。这是一个有趣的部分，我已经要求人们阅读他们自己的代码，或者只是告诉我变量代表什么，即使他们仅在一周前编写了该代码（全新类，而不是旧版），他们也无法回答。 。良好的命名有很长的路要走。

• 如果经过简化和重构，您仍然有一个必须执行某种不太明显的算法的函数，请花一些时间在该函数中编写注释块以解释该算法。从现在开始两个月后必须修改该功能不仅会有所帮助，而且如果您陷入代码审查中，则可以简单地读回自己编写的内容。

• 如果上述所有内容之后，您是否仍然遇到麻烦？您是团队的新手，并要求使用许多旧代码吗？在这种情况下，可能是您的TL是A $$，并且您可以主动在会议前要求他轻松一点，而不浪费每个参与者的时间。当新人加入团队时，TL需要有足够的耐心，因为在新平台，新产品，新人，新环境中工作需要新人集中精力，而该人一开始会丢失一些细节。按设计工作，您的TL应该接受。

• 如果上述所有内容之后，您仍然觉得自己的代码检查很糟糕。与您的TL交谈。有时，人们由于代码审查会议的性质而感到难过，而实际上TL对您非常满意。当我进行代码审查时，我的目标是突出需要更改的内容，确保您了解所做的更改并继续进行。很多时候，我没有时间有礼貌，有些人变得防御性，试图回答我的每一个评论。在那种情况下，代码审查会议会停顿下来，所以我倾向于打断他们并继续前进。通常，在会议之后，我会与新手交谈，以确保他们了解该过程，而且这不是私人的。经过很少的代码审查后，人们通常会更自在。

做法各不相同，但以我的经验来看：

• 不要对代码做任何特殊的事情。当您了解要审查的代码时，自然会多花一些代码，而且解决诸如拼写错误之类的明显问题也没有害处。但是不要去添加很多详细的注释，也不要仅仅因为代码已计划进行审核而更改代码。

• 编写代码，并在审查之前将其分发给审查者。这通常是由中立的第三方（可能是代码检查协调人）完成的。如果将其打印出来，代码应该足够小，以免行被太多的换行，但又要足够大，以使每个人都可以轻松阅读。如果需要的话，以横向格式打印。

• 代码应打印或显示行号。最好，该编号应从一个文件继续到下一个文件。引用“ 3502行”比“ foo.c的238行”要容易得多，并且有了数字，每个人都可以谈论特定的行，而不会浪费时间查找这些行。

• 绝对应该有一个促进者，顺便说一句。他或她的工作是防止评论陷入细节，防止其变得个性化或激烈，并严格限制评论的时间。

• 作为作者，您应该在审查会议之前亲自审查代码。如果这是别人的代码，请写下您建议的更改。这可以使您记忆几天后可能没有看过的代码，也可以帮助您练习用批判性的眼光看自己的代码。在以审阅者和作者身份进行了几篇评论之后，您会发现自己的笔记与小组其他成员的笔记更加接近。

• 准备在审核期间做笔记。这不应该是您的主要关注点-其他人应该记录小组同意的行动项目，以便您可以专注于解释代码并听取反馈。但是有时候，您会得到一些有价值的反馈，而不是一项行动性的建议，您应该纠正这种情况。

• 请记住，这不是个人的。很难避免在评论过程中感到（和扮演）防御。如果您认为自己的代码被误解了，那么可以对它进行解释，但这比尝试监听的要多。

在其他答案中添加的另一件事是：使正式代码审阅者更轻松，进行很多非正式代码审阅！例如：

“嗨，鲍勃，我能告诉你如何实现foo（）函数吗？” “嗨，史蒂夫，你能看一下这个课程表，让我知道你的想法吗？” “嘿，凯伦，您能帮我解决这个问题吗？我认为我有一个很好的解决方案，但是我可以使用您的帮助...”

养成规律的习惯。在设计过程的早期阶段让同事参与时，您：

• 建立关系
• 获得对该问题的新见解
• 提高您解释当前问题/解决方案的能力
• 节省以后在正式代码审查中的时间