代码审查应礼貌还是直率？一劳永逸地解决这个问题

如今，我靠创作内容（或者说，越来越多地，运营内容运营）谋生。因此，社交媒体和博客对我来说更像是一种广播，而不是信息来源。不过，最近我还是有机会走出自己的圈子 ，去观察一场关于代码审查礼仪的辩论。

代码审查礼仪难题

以下是这场辩论的双方观点，我尽力避免带入主观偏见。

• 代码审查可能会让被审查者感到沮丧和士气低落，因此一定要包含一些积极的反馈。
• 制造赞美是居高临下的，所以只需坚持事实和行动即可。

在本文的剩余部分，我将使用“微妙与直接”这种相对中性的框架来指代这些相对位置，并认为它们之间存在着某种连续性。

这只是最近的一次。这些年来，我经常看到这样的争论，而且我之前也讨论过代码审查：

• 摆脱令人厌烦的评论者。
• 尽可能实现自动化，以最大限度地减少人为主观因素。
• 代码审查文化如何变得有害。

所以，正如你可能推断的那样，我更有可能在辩论中支持第一点：要有礼貌。这不仅是我的自然偏好（要么礼貌，要么干脆不礼貌），也是我个人背景和文化的产物。这是一个强有力的论断，所以让我们先简单概括一下，然后再详细阐述。

我们假设微妙与直接的问题是一种有意识的个人风格选择

读到这篇文章的前提，你可能立刻就会开始在心里默念：“就为了友善 一次，真的会要了你的命吗 ？”或者，“我们为什么要浪费时间在那些不真诚的游戏上拐弯抹角呢？”

这段独白随后变成了正确的行事方式。“持续的负面情绪会导致公司人员流失，让我们的行业变得有害，所以我们应该停止。”或者，“所有这些游戏都浪费时间，削弱了审核流程，损害了我们的生产代码。”所以，关于这个话题的文章变成了像“别再给我恭维三明治了”这样的文章。你自然而然地认为你的风格是正确的，然后试图争辩说其他人也应该采用你的正确方法。

代码审查变得微不足道：飞机失事的种族理论

这看起来很像我们讨论和争论代码风格的方式。但微妙与直接的对立根本不是那样。这很大程度上取决于文化。

几年前，我听过马尔科姆·格拉德威尔（Malcom Gladwell）的有声书《异类》（Outliers）。这本书引人入胜，但真正让我感兴趣的是它的第七章（详细内容请见此处）。现在，每当我听到类似关于代码审查的争论时，我都会想起格拉德威尔的这本书，以及哥伦比亚飞行员的故事。

哥伦比亚飞行员在谨慎的阵营中降落时表现得非常糟糕。纽约肯尼迪机场的空中交通管制员则非常直接。由于这些互动模型之间所谓的阻抗不匹配，一场完全可以避免的悲剧随之而来。

哥伦比亚飞行员告诉空中交通管制员，他们的燃油不足，需要降落。但他们没有说（或喊）出他们遇到了紧急情况，而事实上他们确实遇到了。因此，空中交通管制员推断实际上没有紧急情况，并继续推迟降落。飞机耗尽燃油坠毁。

如果这种方法在生死攸关的情况下都无法找到简单的解决方案 ，那么我们对 Github 拉取请求或会议室平板屏幕上投影的 IDE 又有什么希望呢？

不同文化在微妙与直接性方面有着非常非常不同的定位

当我思考代码审查是否直率的争论以及这篇文章的开头时，我开始漫不经心地谷歌搜索。我似乎记得（虽然我面前没有这本书）格拉德威尔经常谈到不同的国家出现在这个连续体的不同位置。果然，一些轶事谷歌搜索似乎也表明了这一点。

对于那些感兴趣的人来说，这里有一些有趣的读物：

• Quora 上有人问以色列人为什么这么直率。回复的人（估计是以色列人）辩解说，这在某种程度上是正确的处事方式。“你干嘛拐弯抹角？”
• 这个故事讲述了相对直率的美国人与较为委婉的墨西哥文化之间某种文化冲突。与其要求别人抽烟，“恰当”的做法应该是说“吸烟有害健康”，并相信对方会理解这种社交暗示。
• 这里有一篇关于德国人为何如此直率的文章。它详细讨论了德语在表达思想方面如何更加直白/精确，更少模棱两可。
• 本文解释了为什么美国文化（在直率方面比较中庸）会让来自非常含蓄的文化的日本人感到震惊。日本人显然不会因为向主人表达饥饿而显得粗鲁，而美国人则认为，如果他们饿了，就会直接说出来。
• 本文探讨了如何理解印度企业文化，并指出并非所有“是”的答案都意味着“是”。毫不犹豫地回答“是”就意味着“是”。犹豫再三后说“是”则表明不情愿。这是因为对某人（尤其是对上级）说“不”是一种不尊重。

异构的微妙-直接环境是现实政治的地雷

我列举所有这些是为了提醒大家，这并非像制表符或空格那样由你自行决定。你的成长环境浸润着自己的文化，这很大程度上决定了你的沟通方式是委婉还是直接。而接触截然不同的文化方式会产生文化冲击。

含蓄的人可能会觉得直接的人粗鲁无礼。在直接的人看来，一些看似正常的互动方式，在含蓄的人看来，就如同问“我能看着你上厕所吗？”一样。于是，他会想：“你怎么了，你这个野蛮人？！ ”同样，如果一个直接的人问：“我们讨论的时候，你介意我吃点东西吗？”，他很可能会把对方的同意理解成字面意思。所以，当会议的另一方到处宣扬自己是个没有文化的穴居人时，他很可能会觉得“真是个毒蛇”。

这不是正确或错误方法的结果，也不是人性善恶的结果。这是不同文化潜意识中互动的规律和规则造成的。当你身处陌生的领域时，你自然会感到沮丧，觉得周围的人都疯了。

代码审查礼仪与微妙-直接连续体息息相关

很早以前，我就提到过我的文化经历影响了我的代码审查观点。我天生是一个避免冲突的人，曾经把自己形容为一个“流氓安抚者”。我还是个内向的人。虽然这或许部分是遗传因素，但我认为很大程度上是文化背景的影响。

小时候，在我家，你不会在别人面前跟其他家人争吵。“如果你没什么好话可说，就什么也别说”这句至理名言绝对是家喻户晓的指导方针。你不会主动给别人提意见，尤其是那些直接批评别人的意见。我的成长环境告诉我，要始终保持礼貌，避免紧张和争吵，保持平和的生活。当我去朋友家，看到家人之间互相叫喊时，我会感到既尴尬又惊讶。

这确实影响了我对代码审查的方法和偏好。

我自己的代码审查方法作为中等微妙性的示例

如果你不问我的意见，我就不会提供。如果你确实要我提交代码审查，我会非常明确地表达。也就是说，我不会对你发号施令，也不会把我的意见当成事实。我会说“我不会那样做”，而不是“改掉它，那样做不对”。我更喜欢通过提问而不是挑毛病来引导别人发现可能的错误。而且我肯定会尽可能多地赞美别人，以缓和批评的气氛。这并不是因为我希望别人也这样对我（我不在乎），而是因为我觉得 开始用毫无节制的消极态度来埋头苦干是不对的。

但我也承认这只是我的偏好。

过去有人要求我更直接一些，或者“坦诚相待”。我试过，但那不是我的风格。说实话，我宁愿把不重要的缺陷留在代码库里，也不愿冒着与敏感人士关系受损的风险，也不愿觉得自己粗鲁无礼。我们以后总能修复代码的。

你在异构微妙-直接团队代码评审中的行为对你的职业生涯意味着什么

如果你来自一个比我更微妙的文化，我可能会偶尔感到恼火。如果你对我直言不讳，我可能会开始把你视为敌人和障碍，我会采取一些措施来应对，比如调离你，或者写一个关于你的热门文章系列或一本书 （假设你的能力和直率程度一样有限）。

而且我并非孤单一人。你也会有这种冲动，你身边的每个人都会有，无论他们有着怎样微妙或直接的背景。

所以，作为一个人，我建议你首先要理解这一点。是的，其他人在这方面的倾向和你不同。是的，这些倾向会让人觉得奇怪，甚至有些不妥。但要理解这一点，并努力达成共识。要坦率地告诉你那些直率的同事，他们的直率让你感到不舒服。在鼓励他们直言不讳的同时，也要委婉地给予他们委婉的反馈，并请求他们保持耐心，不要冒犯你。

但撇开这一点不谈，这里还有另一个因素在起作用——现实政治因素。

处理好这些文化差异和偏好，不仅能让像代码审查这样普通的 IC 工作顺利进行，还会对你的职业生涯产生重要影响。如果你要求每个人都顺从你的文化习惯，那后果自负。

代码审查是一场权力剧场

读过我的书以及研究金字塔型公司的读者们 ，可能都期待着我会用这样的话来总结。当你把代码审查看作一项活动时，它运作在两个层面上：

1. 别想太多。这只是提高代码质量的一个相对常用的策略。
2. 从组织层面来说，这就像一场小山丘之王的游戏。没有赌桌筹码，只为赢得胜利而战。（热尔韦原则称之为“游戏谈话”中的失败者语言）。

用我的话说，代码审查就像一个理想主义者的 熔炉，用来建立一种除了开发组之外无人关心的等级制度。但在开发组内部，它决定了你是受欢迎的运动员，还是，呃，书呆子，我猜……？（我不知道该如何让这个比喻不那么讽刺）

在团队代码审查这种封闭的文化中，权力动态自然形成。从最基本的层面来说，这默认遵循资历排序。在公司工作时间较长的人比新手更有影响力（虽然定义有些可疑），这意味着通常由资深人员“负责”新手的代码审查。

喜欢直率是夺权，喜欢含蓄是放弃权

当你将微妙与直接的文化考量融入其中时，就会触及一个被称为“权力距离”的概念。你可以在这里阅读更多相关信息，但为了我们的目的，请理解这些不同的文化对组织结构、权力和行为有着不同的看法。“直接”文化倾向于假设从CEO到IC的每个人都会畅所欲言。“微妙”文化则坚信角色决定行为、尊重和社交互动。

所以，当你在一个异质群体中“直言不讳”时，你不仅仅是在“说出你的想法，伙计”。你是在表明你是主导者。而微妙之处，让顺从成为一个自我实现的预言。

换句话说，“友善还是直率”的选择不仅仅 关乎 你喜欢什么样的反馈，也关乎你对自身权力的主张或缺乏权力。

即使代码审查本身没有影响，你的代码审查方法也可能对组织产生影响

现在，正如我所说，这只是小规模的权力。它相当于你组织里的 Stack Overflow 徽章。请注意，不会有副总裁因为你在代码审查时模仿得像 Linus Torvalds 一样优秀而给你一间办公室。

直白地说，就是默认自称“高级”，委婉地说，就是默认自称“初级”（我讨厌这个词）。组织甚至可能在某个时候让这个预言自我实现。但要知道，从任何规模适中的组织的角度来看，高级开发人员和初级开发人员是同一回事。

经过多年的代码审查和充满争议的讨论，你或许能在开发者之路上赚到更多钱，也更有炫耀的资本。但是，如果你是一个机会主义者，或者有抱负的机会主义者，那并非你所追求的。这没关系。你对待代码审查的行为和方法仍然很重要——只是不像对那些理想主义者那样重要。

你不想成为格雷格·豪斯，也不想成为他的好友威尔逊

我提到了Linus Torvalds，我把他当成软件界的Gregory House。Gregory House 的设定是，他是一位医生，在诊断方面天赋异禀，以至于他的医院会原谅所有糟糕且需要承担责任的行为。他吸毒成瘾，藐视法律，不听任何人的劝告等等，但他实在太优秀了，以至于这个世界的精英阶层都愿意原谅这一切，以便沐浴在他身上所展现的荣耀。

但世界并非如此，企业界更是如此。格雷格·豪斯在医院里撑不过三天，林纳斯·托瓦兹本人也无需如此，因为他更像是一位行为艺术家，而非企业员工。当这种作弊行为超过其带来的好处时，企业不会容忍这种典型。

现在退一步想想直率的代码审查员。在那些高高在上、地位显赫的机会主义者看来，这种原型就像一个幻想成为 House/Linus 的业余理想主义者。“我没时间礼貌地对待我的反馈”在这种情况下听起来自以为是，滑稽可笑。言下之意是：“你就像 Linus Torvalds，只是没有成就。”

另一方面，豪斯的对手是敏感易受欺负的威尔逊博士。威尔逊绝对是“恭维三明治”的王者，也是那些处于社会底层的、精明的文化人士的化身。你也不想成为那样的人。如果你被豪斯/托瓦兹踩在脚下，你注定不会进入权力的殿堂。机会主义者会操纵（熟练的）理想主义者——他们不会在理想主义者面前畏缩，也不会要求调职。

人性化方法：采用被评估者偏好的方法

让我插播一点小插曲，用马基雅维利式的术语来谈谈这会如何影响你的职业生涯。作为一个正派的合作者和人，你应该做的是了解你的同事，并按照 他们的 喜好去做。

这场辩论总是充斥着“这就是 我 喜欢的，所以我们作为一个群体都应该做我喜欢的事，因为我喜欢的就是最好的”之类的论调。当你理解了文化背景之后，这种做法就显得幼稚得不可原谅了。当你了解了其他人，包括他们的性格和文化倾向之后，你就可以开始用 他们 喜欢的方式给他们反馈，无论是直白的还是赞美的，直接的还是含蓄的。这样做才是得体的做法，也最有可能取得成果。

现实政治方法：解决代码审查争吵，让机会主义者不必关心

现在，让我们从职业角度来看。你认为团队之外的任何人会在意你是否使用组合模式来管理导航菜单吗？让我们更进一步。你认为团队之外的任何人会在意你在讨论这个细节时是否提供三明治吗？

这些东西对企业来说并不重要。仅此而已。

所以，当你争论代码、代码审查，以及是否应该直言不讳时，任何被你纠缠的人都会认为双方都是输家。从机会主义的信誉角度来说，这是一种相互保证毁灭的策略。无论你是去找经理抱怨别人，还是经理抱怨你，或者你们只是在互相较量，最终都是输家。

因此，出于外交考量，你的代码审查方法应该首先以人为本。但同时也应该在你的团队内部建立起人为代码审查的主导地位，并且要公开透明地进行。开发团队之外的其他人并不关心这一点，所以如果你能公开透明地让每个人都不关心这个问题，你就能获得关键的胜利。

从广义上讲，这可能意味着建立共识，也可能意味着简单地自动化整个代码审查流程。但无论它是什么，它最终都会以消除机会主义者的麻烦的形式出现。

最终，正确的答案是一种算法，而不是一种风格

如果你从这篇文章中学到什么，我希望它能让你认识到，代码审查（或一般意义上的协作）反馈风格并没有一个正确答案。即使你的团队奇迹般地找到了一个，也无法完全照搬。团队由不同的人组成，他们来自不同的国家，拥有不同的背景，也有不同的爱好。这并非陈词滥调——我们从小就被灌输了对代码审查应该如何进行的不同看法。

所以，别再纠结于哪种策略才是正确的，而是要认识到，正确的策略是需要根据你的受众进行调整的策略。并且要认识到，正确的策略是能够避免这个问题浪费人们的时间，让他们的日子不再像裁决孩子们如何争抢玩具那样枯燥乏味。这种认识不仅有利于你每天的幸福，也有利于你的事业。