进行公关审查

原则

总之

你正在使用 Git？太棒了！但接下来就是你的第一个拉取请求（PR）了。你应该做好哪些准备呢？或者，也许是时候对别人的代码进行第一次 PR 审查了。这同样会让人感到畏惧。没有人喜欢被批评，但当代码中存在问题时，就必须指出来。

在我近20年的编程生涯中，我一直都在与这个问题作斗争，最初是代码审查，现在是提交pull request。我做过谷歌搜索，读过相关的领导力文章，但最重要的是，我亲身实践过。令人惊讶的是，这似乎是高等计算机科学类课程中普遍缺乏的技能（至少就我的经验而言）。总之，或许我的痛苦经历能对你有所帮助。

原则

我喜欢带着一些原则来进行代码审查。我发现，无论你是审查者还是被审查者，这些原则都能让审查过程更加顺畅。

原则一：保持灵活

以开放的心态参与 PR 评审。编程既是科学也是艺术。多年来我学到的一点是，技术上的正确性和吹毛求疵并不一定等同于优秀的代码。例如，如果代码运行缓慢，令用户感到沮丧，那么变量名是否完全符合某种模式真的重要吗？此外，我记得曾经有一位开发人员过于专注于使用 ORM 编写优秀的代码，以至于他觉得这很棒。问题在于，这是一个需要将几 GB 的数据从一个数据库复制到另一个数据库的批处理流程。使用事务性 ORM 实际上是一个问题重重的方法，因为它需要将每条记录加载到一个对象中才能进行传输。另一种方法是使用批量传输工具在数据库之间流式传输数据，从而最大限度地减少内存开销。然而，这位开发人员坚信他优雅的代码就是完美的，以至于当问题被提出时，他只关注代码的技术正确性，而忽略了真正的问题所在，最终导致代码被部署到生产环境。不久后，随着数据集的增长，我们开始遇到内存问题，进程也开始崩溃……

说到这里，还要记住，我们每个人解决问题的方式和编码风格都不同。最终，如果代码库中存在多种风格，维护者是否能理解代码真的重要吗？例如，如果实例变量名的其他部分对团队来说都很直观，那么你漏掉了一个前导下划线真的重要吗？或者，你的大括号（也就是花括号或{）是在方法声明的同一行还是在下一行真的重要吗？无论如何，代码都能编译和执行……

原则二：保持好奇心

在进行 PR 审核时，将其视为学习机会。PR 的双方都有机会学习。与其批评说“这是错误的，因为 X”，不如提出问题，例如“这是一个很有趣的方法，是什么促使你选择这条路？”。如果你确实认为某些地方存在问题，还可以更进一步，提出建议。例如，“你处理这个集合的逻辑简洁明了，也很可靠。不过，我想问一下，我们能否通过使用新的.ForEach()集合方法来改进它，以便运行时引擎可以优化并以并行或多线程的方式处理集合？” 这样做既肯定了对方的工作，又提出了开放式的问题，从而开启了关于如何改进的对话。

原则三：这并非针对个人。

在团队合作中，每个人都必须意识到代码仅仅是代码。尽量不要把它当作作者（无论是你自己还是其他人）的延伸。虽然有这种想法很正常（毕竟代码是别人用自己的智慧和想法编写的，其中难免包含一些自我表达），但这种想法必须让位于团队目标和代码的用途。例如，我可能对自己代码中的某个巧妙技巧或我认为特别优雅的写法感到自豪。但是，如果这段代码难以维护，或者对最终用户来说运行速度极慢，那么它很可能需要修改。我经常遇到一些开发者，他们以别人对自己代码的评价来衡量自身价值（我坦白承认，在职业生涯中期，我也曾是这样的人，但我现在基本已经克服了这一点）。这种想法对所有相关人员都可能造成毁灭性的打击。为了你自己好，请努力摆脱“代码是你的”这种想法。自从我明白这一点后，我的工作生活变得快乐多了。而且，我发现现在人们更容易、更自在地接近我了。

原则四：不要忘记人的因素

我发现，在当今时代，我们常常让科技成为我们与他人之间的屏障。用短信代替面对面交谈或打电话就是一个例子。别误会，短信和像Slack这样的聊天系统确实很棒，也带来了巨大的好处，但我们常常忽略了它们的局限性和缺点。人天生是社会性动物，在面对面交流的情况下，他们的行为方式自然会有所不同。

另一个很好的例子，在 PR 和代码审查的背景下，许多 Git 系统（GitHub、BitBucket、GitLab）允许在 PR 中添加评论。然而，这可能会引发问题，因为这些系统消除了面对面的交流，而 PR 审查的本质就是“检查他人的工作”。如果只使用这些系统，就会丢失大量的非语言沟通和其他社交信号。别误会，这类系统本身是有用的，也有其存在的意义，我们不能忘记我们是社会性动物。我建议了解你的受众并做出相应的调整（参见原则 1：保持灵活）。我曾与一些人共事，他们很乐意只使用这种沟通系统，因为即使某些内容可能被误解，他们也不会感到冒犯。然而，在同一个团队中，我也遇到过一些人，他们觉得这种方式不太适用（他们总是感觉受到了攻击）。我发现，了解哪些方法对不同的团队成员有效并做出相应的调整至关重要。当我不确定队友在审核 PR 时可能会作何反应时，我通常会这样做：

1. 我使用评论系统来标记问题，并附上问题的简要描述（我在撰写这些描述时严格遵循原则二）。这样做仅仅是为了避免遗漏，也方便我们双方快速找到受影响的代码。仅此而已。

2. 完成审阅后，我会和当事人坐下来，无论是当面还是电话沟通，详细解释公关稿中我存在的问题（我也会注意不直接念稿给当事人听……因为当面听我解释，我的文字里任何可能冒犯到对方的地方都会自动纠正）。再次证明，第二原则在这里非常有效。

总之

以上就是我作为被评论者和评论者对待公关稿件的态度。总而言之，就是保持谦逊，把它当作一次学习的机会。

用威尔·惠顿的名言来说就是：“别做混蛋。”