The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
代码审查（又称同行审查）对于每个认真的软件开发团队来说，必须是一种强制性的实践。我希望对此没有争议。有些人进行合并前的代码审查，以防止意外错误影响主分支/开发分支。其他人进行合并后的常规审查，以发现作者引入的错误和不一致之处。有些人甚至两者都做，合并前进行审查，然后定期进行审查。代码审查与白盒测试技术非常相似，测试人员可以完全访问软件源代码以查找缺陷。无论哪种情况，代码审查都是提高质量和增强团队动力的重要工具。
然而，正确进行代码审查并不简单。我甚至会说，错误地进行代码审查非常容易和舒适。我见过的大多数代码审查和审查人员都犯了相似的错误。这就是为什么我决定总结我认为良好的审查人员应具备的四个基本原则。希望你会发现它们有用。
严肃的代码审查者应该摒弃几种不同的恐惧。第一种也是最常见的一种是害怕冒犯代码的作者。”我最好闭上眼睛，假装今天没有看到她的错误，这样明天她就会忽略我的错误” ——这是这种恐惧产生的态度。不用说，这是适得其反的，会降低代码质量和团队士气。我的建议是：直截了当、诚实和坦率。如果你不喜欢这段代码，就是不喜欢。你不应该在意你的意见会被代码的作者如何接受。
如果你对同事有这样的感觉，那么管理模式就有问题。你害怕被团队拒绝，因为”不是团队的一员”这个标签是由团队最弱的成员贴在你身上的，而不是项目赞助商。赞助商支付你来开发高质量的软件。赞助商不在乎你为了提高质量的意图会冒犯到那些不太在意的人。赞助商想要用他的钱生产可卖给客户并带来利润的交付成果。赞助商不支付你来在办公室交朋友。
下一种恐惧的表现是这样的：”如果我拒绝这段代码，会延迟发布” 同样，毫无疑问，这样的态度对整个项目是极大的不利。你会接受这段代码，对其中不喜欢的部分视而不见。代码将进入下一个发布版本，我们会更早地发布出去。你不会成为瓶颈，也不会有人说因为那个教条主义的代码审查者，我们延迟了发布并损失了一些现金。你会成为一个好的团队成员，对吗？错！
如我之前提到的，一个专业的团队成员了解他或她在项目中的个人角色，并不会掩护任何人。如果拒绝糟糕的代码导致发布延迟，那是其作者的责任。你的专业责任是让这个错误变得可见。这就是你帮助团队学习和改进的方式。
我认为显而易见的是，团队的教育和改进首先需要摆脱糟糕的程序员并提拔优秀的程序员。诚实而无畏的代码审查者帮助团队学习和改进。
还有一种恐惧是这样表达的：”我可能是错的，他们会嘲笑我” 更糟糕的是，他们可能会察觉到我的知识缺乏。他们可能会看出我不知道自己在做什么。最好还是保持沉默，假装代码中没有错误。至少那样我就不会因为愚蠢的评论而尴尬自己。你知道，如果你保持嘴闭，显得聪明要容易得多，对吧？错！
项目不是为了让你看起来好而支付你薪水。你得到薪水不是因为团队喜欢你，而是因为你每天交付成果。你的专业责任是为项目做最好的事情，忽略每个人的意见，包括你的上司的意见。就像《一个开心的老板是一个虚假的目标》一文中所说的，我会说团队的尊重是一个虚假的目标。不要试图赢得尊重。相反，创造干净的代码，尊重会自然而然地到来。
让我再重申一遍：不要害怕因为对某人的代码发表不正确和愚蠢的评论而尴尬自己。对项目忠诚，而不是对周围人的期望忠诚。他们期望你聪明和聪颖，但项目期望你说出自己对代码的看法。所以不要理会他们的意见；做正确的事情，说出你真正的想法。
好的，你毫不畏惧地表达了你对代码的看法，并简单地拒绝了它。你正在审查的分支不好，你解释了原因。你要求作者在这里进行重构，那里进行重写。接下来呢？
他或她会试图与你达成协议。这是很自然的，在我们团队中几乎每个分支都会发生这样的情况。代码的作者也是一位专业的开发人员，他也没有畏惧。因此，他坚持认为他的实现方法是正确的，而你的想法是错误的。在这种情况下，一个专业的代码审查者应该做什么？
最糟糕的事情（就像在任何冲突解决中一样）就是妥协。这比糟糕的代码更快地破坏了质量。妥协是一种冲突解决技术，双方同意为了结束冲突而不得到他们想要的东西。换句话说，”为了停止战斗，让我们和平共处”这是最糟糕的方法。
与其妥协，有三种专业的方式可以解决关于一段代码的争论：
“我绝对不会接受这个，无论如何！” 有些代码是值得这样做的，这样解决冲突并没有什么不对。对手也许会接受这种情况并重写一切。并且从中学到一些东西。
“让我们听从架构师的建议！” 在每个项目中，都有一位软件架构师做出最终决策。向他征求意见并获取他的最终决定。邀请他参与讨论，并请他在冲突中站在一方。一旦他告诉你你错了，接受这个决定并试着从中学习。
因此，要么坚定立场并为之奋斗，要么承认自己的错误。两者只能选择其一。但不要妥协！
不要误解我的意思，这并不意味着要固执己见，无论情况多么糟糕，都要坚持自己的立场。要灵活变通，随时学习。在谈判过程中，你的立场可能会发生变化，但不要接受任何你不喜欢的东西。你可以在完全确信对方是对的或者架构师这样说时退出冲突。没有中间地带。
再一次，你毫不畏惧地说出应该以不同的方式设计一个方法。你的对手，代码的作者，回答说他不这么认为。你再次看了一眼，决定坚持你的立场。你仍然认为自己是正确的，不会妥协。现在怎么办？现在找架构师还为时过早，所以试着说服你的对手。
在大多数情况下，说服就是教育。你知道一些他不知道的东西。这就是为什么他以你不喜欢的方式创建了那个方法。你们其中之一需要额外的教育。这是你成为同事的老师的机会。为了成为一个有效的教师，你需要提供证据。你需要以事实为基础，确保他理解并接受。
准备好展示链接、文章、书籍、报告、示例等等。仅仅说“我知道这个，因为我已经写了15年的Java”是不够的。而且，这种类型的论证只会让你更不具说服力。
如果你没有足够的有力证据，再次思考一下，也许你是错的。
另外，请记住，你的工作是证明你正在审查的代码是糟糕的。代码的作者不需要证明任何东西。默认情况下，他的代码是优秀的。审查者的工作是展示为什么以及如何事实并非如此。换句话说，你是原告，他是被告。而不是反过来。
这是最后也是最难遵守的原则。无论代码有多糟糕，对手有多固执，你都必须保持专业。说实话，有时候我也觉得很难做到。在Zerocracy上，我们在分布式团队中工作，并每周雇佣一些新人。其中一些人，尽管符合我们的筛选标准，但似乎难以相处。
大约一年前，我遇到了一个有趣的情况，一个新人应该在现有的Java库中创建一个小的（20到30行代码）新功能。他在提交拉取请求之后（我是代码审查者），放入了几百行代码。那段代码是一团糟，显然不是他自己写的。我立刻明白他是从某处找到并复制了它。但我能怎么办呢？怎么能在不说他的态度对于一个专业开发者来说是不可接受的情况下拒绝它呢？我不得不花时间客观地指责他的代码风格、设计等方面。我不得不发表许多认真的评论，以向他展示要修复所有问题，他应该删除这些垃圾并从头重新编写。在那个任务之后，我再也没有见到他。
我的观点是，当你与专业人士打交道时，保持专业是容易的。不幸的是，情况并不总是如此。但无论你面前的代码有多糟糕，都要耐心和有说服力。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 14:49
