这是一篇关于代码审查中不良模式（antipatterns）的文章，主要内容如下：

• 引言（Introduction）：代码审查看似是个好主意，能发现问题、传播项目理解等，但也可能被用于阻碍代码改进等不良目的。这里列出了代码审查的不良模式，供那些没思路的“暗面”代码审查者参考。

• 不良模式（The antipatterns）：

  • 千次往返之死（The Death of a Thousand Round Trips）：审查者看到小问题就添加评论指出，开发者修改后再指出另一个问题，如此反复，导致补丁进展缓慢，直至开发者失去希望。若与开发者时区不同，自然有 24 小时往返时间；若时区相近，则需安排其他事情来拖延。
  • 勒索便条（The Ransom Note）：开发者特别重视某个补丁，但审查者认为不重要，就以此为要挟，要求开发者做额外相关工作。
  • 双重团队（The Double Team）：两个审查者对同一个补丁提出相互矛盾的要求，让开发者左右为难，不断修改，直到放弃。
  • 猜谜游戏（The Guessing Game）：针对开发者解决问题的特定方案进行模糊、无关的批评，使开发者不得不重新选择解决方案，然后再否定新的方案。
  • 优先级反转（The Priority Inversion）：在审查初期挑一些小问题让开发者修改，然后突然提出一个更根本的问题，需要重新改写大部分内容，浪费开发者的时间和精力。
  • 后期突发设计审查（The Late-Breaking Design Review）：在一个复杂的工作已经进行了数周或数月，部分工作已提交的情况下，审查者要求对整个工作的设计进行 justification，若开发者不知道答案，就不批准。
  • 第 22 条军规（The Catch-22）：对于一个大的补丁，要么要求拆分成小的子补丁，要么要求合并成一个大补丁，以此来刁难开发者。
  • 反复无常（The Flip Flop）：对于常见的代码修改类型，突然反对之前从未有问题的方面，让开发者难以捉摸。

• 严肃来说，伙计们……（But seriously, folks …）：

  • 权威（Authority）：代码审查中会产生临时权威，审查者有权阻止补丁提交，但应仅用于使补丁尽可能好的目的，上述不良模式大多是对权威的滥用。
  • 把关代码审查（Gatekeeping code review）：在同行代码审查中，审查者和提交者目标基本相同，但对于外部发送的未经请求的补丁，审查者作为项目负责人，有权拒绝，此时可以基于现有设计原则批评补丁，但应解释原因，不应有消极抵抗行为。
• 免责声明（Disclaimer）：文章中的内容是多年来从参与的和观察到的代码审查中收集的笔记，并非针对最近审查其代码的特定人员。