节选自 VM (Vicky) Brasseur 的 《Forge Your Future with Open Source》，版权 © 2018 The Pragmatic Programmers LLC。经出版商许可转载。

即使是新的程序员也可以通过代码审查提供很多价值。您不必是一位拥有多年经验的摇滚明星忍者 10 倍独角兽女神程序员才能拥有有价值的见解。事实上，您甚至不必是程序员。您只需要有足够的知识来发现模式。虽然没有编程知识您将无法进行完整的审查，但您仍然可以发现一些可能需要改进或澄清的地方。

如果您不是摇滚明星忍者 10 倍独角兽女神程序员，那么您的代码审查反馈不仅仍然有价值，而且您还可以在此过程中学到很多东西：代码布局、编程风格、领域知识、最佳实践、您原本看不到的巧妙的小编程技巧，有时甚至是反模式（或“如何不做事”）。因此，不要因为您不熟悉代码、项目或语言而阻止您审查代码贡献。尝试一下，看看有什么可以学习和发现的。

“但是，”您可能会哀嚎，“这怎么可能？！我不太会编程！我怎么可能在代码审查中做任何有价值的事情？”冷静点，朋友。您在这里有很多可以提供的。早些时候我提到了模式识别，这是一个很好的起点。如果您正在审查的贡献看起来比周围的一切都复杂得多，那么您就发现了一个潜在的问题。代码是否使用了与文件中其他地方不同的缩进或变量命名？那是另一个潜在的问题。代码贡献是否真的很长，而文件中其他所有内容都短得多？这可能表明有问题。您不必成为摇滚明星忍者 10 倍独角兽女神程序员才能发现这些东西；您只需要熟悉编程，最重要的是——您只需要查看代码。

当您开始对您不太熟悉的项目进行代码审查时，请务必小心。有些项目宁愿不接受来自那些尚未熟练掌握问题代码的人的审查，因为这些审查通常可能包含错误或与项目通常的运作方式不一致的地方。经验不足的审查人员也可能会使经验不足的贡献者感到困惑，他们可能不知道向他们提供反馈的人并不十分熟悉代码或项目。在开始审查代码贡献之前，请务必查看 CONTRIBUTING 文件或询问核心贡献者，而不是冒着冒犯他人或在不需要反馈时提供反馈的风险。

代码审查中要查找的内容

如果您决定审查代码贡献，您应该查找哪些类型的东西？正如您可能预期的那样，答案是“这取决于项目”。也就是说，无论项目、代码或使用的编程语言如何，您都可以牢记几件事。虽然这些技巧似乎只适用于编程生涯早期的人，但事实并非如此。以下是任何经验水平的人进行代码审查的最佳实践。无论您是新手还是大师，这些技巧都可以帮助您发现任何代码审查中的潜在问题。

• 代码甚至能通过构建吗？ 项目是否使用持续集成/持续部署 (CI/CD) 或以其他方式自动运行其测试套件？如果代码贡献后测试套件未通过……您是一个聪明人。我不需要告诉您这是一个很大的危险信号，表明代码可能存在问题。礼貌地要求贡献者研究构建/测试错误并在您继续投入时间审查贡献之前纠正它们。
• 代码甚至可读吗？ 您不必成为编程语言专家就能判断代码是否可读。奇怪的循环、简短而含糊的变量和函数名称、不一致的空格或括号使用、大块注释掉的代码……许多事情都可能使一段代码难以阅读，但最终结果是相同的：不可读的代码是不可维护的代码。
• 做一件事并做好它。 最佳实践是程序中的每个类、方法或函数都做一件事并做好它。这降低了任何一段代码的复杂性，使其更短且更容易理解、维护和测试。注意任何过载并试图做太多事情的代码片段。这方面的一个很好的线索可能是代码具有复杂或长的条件语句。
• DRY 原则：不要重复自己。 是否有任何代码出现不止一次，即使它在做类似但不完全相同的事情？如果是这样，则应将其重构为一个单独的类、方法或函数。重复的代码意味着必须在多个地方应用更改，从而导致更高的出错机会。此外，重构它可以使其更容易测试。
• 错误处理如何？ 错误是否被显式处理？它们甚至被处理了吗？错误是否包含描述性消息，还是它们是模糊的、“发生错误”类型的东西？正确的错误处理不仅使调试变得更容易，而且还改善了每个使用程序的人的体验。
• 代码是否高效？ 更高级的程序员将更容易确定新代码的效率，但即使是新的程序员也可以感受到代码是否显得笨拙，或者它看起来是否比它应该完成的工作更努力。如果您的直觉告诉您代码可能效率不高，则可能值得标记以进行更多解释。
• 测试覆盖率如何？ 代码是否附带任何测试？单元测试和集成测试都有吗？如果代码被现有测试覆盖，它们是否已更新以确保它们仍然有效？如果是新代码或之前没有测试，作者是否添加了任何测试？如果存在测试，请不要忘记审查这些测试以及其余代码。
• 代码实际上是否完成了它应该做的事情？ 如果代码旨在添加功能或修复错误，请将代码与它应该关闭的问题进行比较，以确保代码 выполняет 预期的功能。很容易误解预期的功能，忘记包含一部分，或包含超出预期的内容（更多并不总是更好）。
• 代码是否已文档化？ 代码注释、安装说明、用户文档、API 文档、故障排除文档……一段代码可以或应该以多种不同的方式进行文档化。由于文档非常困难，但又非常重要，因此通常更容易在每次向存储库添加新功能或错误修复时逐步完成。如果您正在审查的代码没有附带文档更改，您可能需要建议作者添加一些文档，以帮助避免因跳过文档而可能产生的技术和可用性债务。

正如您所看到的，虽然了解代码在进行代码审查时非常有帮助，但即使您刚开始学习编程，您也可以看到很多东西并提供反馈。如果项目支持，即使是经验不足的程序员也可以提供许多有价值的见解，同时还可以更多地了解项目代码以及所有内容如何组合在一起。