谈谈现实中的代码评审

曾经写过一点关于代码评审（code review）的文章，比如 这篇 和 这篇 ，现在觉得关于它的认识又有了不少更新。软件工程的技术和实践分成两部分，一部分是和书本知识一致的，大约占一半，这部分基本上在大学里就可以学，自学只要方法得当、刻苦努力也可是途径；但是第二部分来自于实际团队、经验，内容通常无法从书本当中获得，而且难说对错，不同的人和不同的经历造就了不同的认识。代码评审就是第二部分颇具槽点，可以大加讨论的典型。

代码评审是展现个性和性格的途径

我本人特别反对一种颇为常见的观点，就是“一个良好运作的项目，不同的人，应该写出一样的代码”。我非常理解这种观点的初衷，一个良好规范约束的团队中，不同的人写出来的代码应当一致。但实际上，能真正这样做的团队，我还根本没有见到过。所谓的一致代码，仔细品味，发现不同的工程师写出来就是不一致。因此“一致”这个词一定是在一定程度内的大体描述而已，并非越一致约好。 其实，代码的创造本就是具备个性的。毫无疑问我们应当遵从规约，应当符合习惯，但是一旦试图过度使用它们去约束代码，不但难以落实，而且容易产生无趣、低效和矛盾的氛围。

再回到代码评审上。代码评审本身，以及基于评审意见的来回沟通，和代码本身比起来，要更难以，也更不应该要求一致。我见过许多代码评审的风格，有人喜欢挑小毛病，有人喜欢展开观点夸夸其谈，有人喜欢给实际例子来证明自己的看法……无论哪一种风格，我都不觉得有什么大的问题。但是，就我个人而言，我可以谈谈我自己的代码评审风格：

我会关注三种问题，需求和业务上的问题、代码结构的问题、代码风格格式的问题。

前两种可能存在阻碍我 ship 代码的“严重”问题（说“ship”就意味着认可代码具备了 push 到主线分支的条件了）。我已经记不清多少次和代码作者因为这样的问题争论了。争论是个艺术，有时候并不一定能够达成一致，有的人比较容易被说服，有的人则更坚持己见。 我不想说哪一种更好，但是确实这是代码评审中展现风格的事实——都是就事论事，但有人害怕或者不喜欢得罪人，就会显得 push over 一点；有人则不在乎那么多，坚信自己的想法更合适，就会显得 defensive 一点。 我可能属于后者，似乎在职业生涯的各种阶段都会有和我出现代码评审冲突的事例，但是在某些情况下我也会选择 disagree and commit（不同意但是执行团队达成的意见）。我相信有些团队会喜欢我的 backbone，也会有团队讨厌我的这种风格。下面的内容，也多为基于自己风格的表述。

坚定自己的意见，但是委婉地表达

关于这一点，我也在努力地改进。可以提及的点很多，技巧也很多，但是老实说，冲突还是不可避免。在我经历的几乎所有的团队中，有时候会有老好人，但是基本上所有的老好人都缺少对于原则的坚持。沟通是门艺术，在代码评审中也一样体现。

最重要的一条，只针对代码，不针对人。这条很简单，都知道对事不对人的重要性，但是要非常小心不能违背。

对于大多数代码风格格式上的问题，我都会标注这个问题是一个 picky 或者 nit 的问题（“挑剔的问题”，这是我在 Amazon 的时候学到的方式）。这样的好处在于，明确告知对方，我虽然提出了这个问题，但是它没有什么大不了的，如果你坚持不改，我也不打算说服你。或者说，我对这个问题持有不同的看法，但是我也并不坚信我的提议更好。

使用也许、或许、可能、似乎这样表示不确定的语气词（包括使用虚拟语气）。这样的好处是，缓和自己观点表达的语气。比如：“这个地方重构一下，去掉这个循环，也许会更好”。

间接地表达质疑。比如说，看到对方用了一个参数 3，但是你觉得不对，但又不很确定，可以这样说：“我有一个疑问，为什么这里要使用 3 而不是其他值？”对方可能会反应过来这个值选取得不够恰当。

放上例子、讨论的链接，以及其它一些辅助材料证明自己的观点，但是不要直接表述观点，让对方来确认这个观点。比如：“下面的讨论是关于这个逻辑的另一种实现方式，不知你觉得是否会稍简洁一些？”