我们应得的代码审查

代码审查是评估团队成员代码的过程，通常在代码合并到主项目分支之前以拉取请求的形式进行，或者直接进入代码库。这是一项需要软技能和编程技能之间取得平衡的任务。代码审查能给我们带来很多好处，最终产品也会更好。在进行代码审查时，我们通常的目标是：

• 确保可读性

我如何知道我的代码是否可读？答案显而易见：把你的代码拿给别人看，问问对方是否理解代码的含义，以及代码是否清晰易懂。重要的是要记住，我们编写代码是为了让别人阅读、维护和使用。

• 确保良好的架构

项目应该有关于代码样式、格式、命名约定和各种模式的标准。在进行代码审查时，一个关键点是确保这些模式得到遵循，并且代码与应用程序保持一致。

• 分享知识

这是代码审查最重要的优势之一。在代码审查期间，人们有绝佳的机会学习和分享他们所知道的知识。这是一个绝佳的时机，可以就代码中你不太理解的地方展开讨论。无论你是在进行代码审查，还是你的代码正在等待审查，这都是一个绝佳的学习时机。

• 避免错误

通常，代码审查的主要目标是确保开发的应用程序没有 Bug。这里唯一需要注意的是，不要将其作为审查清单中唯一的内容。

代码审查对代码质量和团队成长都有显著的提升。然而，事情并不总是那么简单，讨论有时非常激烈，甚至像是漫画里的内战。

我们如何才能使代码审查变得更有趣，创造利用它的心态并避免团队中出现戏剧性事件？

开发人员希望为自己的代码感到自豪；毕竟，代码是一项创造性的工作，是我们的艺术。接受批评，并认为我们可能需要重写十行代码，因为其他人找到了更好的方法，或者它在应用程序架构中更合理，这可能会伤害我们的自尊。这就是为什么我们努力掌握“无私编程”这项技能至关重要。能够抛开自私去编写代码，是你能做到的最重要的事情之一。

Jerry Weinberg 在他的著作《计算机编程心理学》中提出了“无私编程的十诫”。虽然这本书比较老，但它与任何新兴的 JS 库一样，都具有当代性。

无私编程的十条戒律：

1. 要明白你会犯错。目标是在潜在问题有可能破坏你的生产应用程序之前就发现它。除了那些为火箭或汽车编写代码的人之外，编程中的错误很少是致命的，所以我们可以而且应该在解决问题后不断学习、开怀大笑，然后继续前进。
2. 你不是你的代码。提醒自己，代码审查的目标之一是识别错误或陷阱，它们一定会被发现。如果有人指出你的逻辑错误，不要针对你个人。
3. 不管你懂多少“空手道”，总有人懂得更多。所以，如果你足够谦虚地向别人请教，这个人就能教你一些很棒的技巧。试着理解你的同事，并从他们那里获取新的想法，尤其是在你不知道如何解决问题的时候。
4. 未经事先沟通，请勿重写他人的代码。修复问题和重写整个代码之间只有一线之隔。了解两者的区别，并尝试理解对方在编写代码时的想法，不要扮演孤军奋战、试图从远处拯救所有人的狙击手。
5. 对待那些知识不如你的人，要耐心且尊重。众所周知，开发人员通常以自我为中心；如果过于苛刻，人们会认为我们自认为是某种优等民族，对一切都有更深入的理解。不要用愤怒的行为和缺乏耐心来加剧这种刻板印象。
6. 变化是唯一不变的。带着笑容接受变化。将需求变更或设计挑战视为改进和做得更好的机会，并享受这个过程。
7. 知识才是权威，而不是某个人的头衔。知识赋予一个人权威，并赢得尊重。如果你想获得尊重，就用你的知识来论证，而不是你的高级头衔。
8. 为你认为正确的事情奋斗，但也要接受偶尔的失败。要明白，即使你的想法是最好的，有时也可能会被拒绝。当这种情况发生时，以及团队意识到这一点时，不要说：“啊哈，我从一开始就告诉过你了。”
9. 不要成为“房间里的人”。不要成为暗室里那个孤立的人，只出去喝杯咖啡——那个不可触碰的人，戴着耳机像间谍一样来来去去。
10. 批评代码，而不是批评人——温柔待人，而不是温柔待代码。尽力提供有价值且有用的评论，帮助他人改进，并致力于共同打造更好的产品。请将您的评论与一些模式不匹配、错误的需求或性能问题联系起来。

了解了这十条戒律后，我想补充一些我过去几年与国际团队合作并负责代码审查时学到的个人技巧。

• 从您进行代码审查的那一刻起，您也成为了该代码的所有者。

您将永远对您审查的代码负责，就像对您自己编写的代码负责一样。

• 如果您没有注意到一个错误，您就不能指责说：“那个人搞砸了。” 这也是您的错误。
• 在发表评论时，请尝试替换：

在这种情况下你不应该使用 X 函数吗？

为了：

在这种情况下我们不应该使用 X 函数吗？

• 当请求某人修改代码时，询问对方对修改提议的想法。让代码作者解释他们编写该代码背后的原因。
• 不要妄下结论，不符合标准的缩进很可能是无意的错误。所以，请善意地提醒对方，不要指责对方试图采用不同的方法。
• 利用示例。你可以在注释中写代码，你知道吗？:)。
• 代码示例使其更容易理解，而不是争论为什么它应该是 array.map 而不是 array.forEach。
• 当请求某人审查您的 Pull 请求时，请确保它不是您过去 2 周一直在使用的整个功能，并且现在已有 129308 个文件发生更改。
• 当某件事有所改进时，要说“谢谢”，认可它，并在有人做得出色时给予鼓励。（如果可能的话，使用 GIF :D）

我相信这些想法有助于打造更优秀的团队，对整个公司都有益。我们的目标是打造一个团结协作的团队，并建立一个能够让员工在公司中自然成长的流程。最后，我想指出一些实用的想法，它们可以帮助你提高整个开发流程的效率：

• 自动化一切！例如 lint、格式化或代码风格检查等任务。我使用 TSLint 和 Prettier 的 pre-push hook 来处理 TypeScript，检查所有更改的代码，确保一切正常。
• 团队中的每个人都应该参与代码审查。记住，目标是促进团队发展。不要提名两三个资深人员作为“审查之王”。
• 如果对某个功能的实现没有达成一致，可以请一位新人以“法官”的身份参与讨论。接受这位新人的决定，然后继续下一步。
• 不要只看拉取请求！签出到分支，使用它，测试它，看看代码是否能正常工作。确保没有运行时错误，并且所有行为都按预期工作。你或许能理解新代码，但只有测试它才能确保它没有错误。提醒自己：代码也是你的责任。

各位，这就是我过去几年学到的一小部分知识。