技术评审之我见：讲逻辑还是讲和气

工作中经常参与对各种交付件的技术评审，交付件有代码，有设计文档，有培训材料，有试题。有时候自己的交付件也会拿去给别人评审。评审工作做多了后累积了一些个人看法，在本文做点总结。

首先插个小故事：去年冬天，我去北京出差。下高铁后，不知道是什么原因，北京站不允许出租车进入。于是我只好出车站去叫网约车。叫到的网约车司机和我约上车点，这个时候我的手机定位出故障了，司机在APP中看不到我的准确位置。于是我们使用“传统方式”电话交流见面地点。我向司机描述我看到的周围路牌、地标、景色。每次我描述完，司机只是回答：“好，好，你继续往北走”。于是我就这么走一段和他交流一次，打了好几次电话后我觉得不对劲了：这似乎也走得太远了，司机真的清楚我在哪儿吗？我再问司机究竟有没有搞清楚我的位置，司机还是说：“好，好，你继续走”。于是，我在零下15度的低温中一直走了几公里，直到走到一个地铁站，再和司机打电话说我走到地铁站了。司机很惊讶：“什么？你怎么跑那儿去了？”。然后他把网约车订单取消了。

那个网约车司机应该是属于性格随和的，当他没有搞清楚别人说的内容时，他不喜欢明确表达出来，也不愿意主动澄清，而是随意的附和“好，好”，寄希望于事情自然发展下去就能搞明白。然而不幸的是事情没有朝着他预期的方向发展，在这种情况下他放弃与对方沟通理解的努力，每次只想讲“和气”，导致最终“见面接人”的目标失败了。

我遇到过的人中，这个司机不是个例。在很多社交场合，“不懂装懂”、“不要追问”甚至可能是礼节或者手段。我承认从社交价值的角度讲，这些手段在某些场合是有用的。但如果大家是为了明确的工作目标进行沟通，这种“讲和气”只是短期掩盖问题让团队看起来更和谐，但长期能使整个目标失败。

因此，我一直很讨厌没有听懂却装作附和的做法。当我讲出我的观点后，如果对方表示质疑，或者提出不理解的地方，在我看来远比只点两下头更有价值。因为前者至少表示他认真听了，而且有在理解我讲的逻辑。

对于技术交流，情况就更加复杂了。由于“面子”的存在，如果一个某领域的专家听到了自己不了解的内容，他可能不愿意承认“我不知道”或者“我没听说过”——因为这样似乎有损个人威信。但事实上，只要认真从事过技术工作的就知道，不管多高级别的专家，在某个细分技术点上出现知识盲区是非常正常的事情，而且承认这种盲区并虚心学习一点都不丢脸——即使这个盲区看起来似乎是个很基本的常识。C++之父Bjarne Stroustrup在一次大会上说了句话让我印象很深，他说：“专家之所以能被称为专家，很重要的一点是他承认自己不知道什么。”

对于技术评审人来说，这种态度尤其重要。因为评审的交付件有可能评审人没法一下子完全理解，这个时候如果评审人“讲和气”，沉默一把，大家就会以为交付件没任何问题，这个评审就这么通过了。但是真正负责任的评审人勇于表达“这个地方我没理解，我不确定它对不对”。

总的来说，我认为要做好技术评审，有几个重点要注意：

1. 确定交付件的目标；确定交付件没有偏离目标。

这是最重要的一点，但是在评审中往往最容易被忽视。因为主讲人（一般是交付件作者）可能强调的是交付件内容全面、新颖、有价值等等，但是没注意到自己偏离了设定的目标。如果目标错了，内容再好也是白干。

2. 确定交付件的技术要点和逻辑没有明显的错误。

这往往是评审的难点，因为评审人不见得对相关技术全部精通。这种情况下，评审人必须找到通向目标的重点逻辑，并校验交付件在这些重点逻辑上没有明显错误。至于剩下的细节，评审时不见得需要面面俱到，可以通过其他流程来保证。

所以，如果是评审代码，最先应该校验的是代码的架构设计是否合理。一旦架构设计得不合理，后续补救的代价巨大。至于命名风格好不好，格式排版对不对等等，不应该是评审的重点。一些小的格式问题甚至没有必要在评审会议上看，会下分散检视更有效率。

3. 注重评审效率，做好充分的准备。

有一些技术材料理解起来是相当烧脑的，要校验正确性的话，可能需要多方寻找证据，仔细推理。在有很多人的会议上，现场花大量时间校验某个技术点，对于其他参会人的时间是一种浪费。因此这些耗时的检查工作应当尽可能在会下分散进行，并在下次会上呈现证据。此外，如果评审人自己把一些技术事实搞错了，也可能在会上产生不必要的争辩。

另一方面，当有人对交付件提出问题时，主讲人（交付件作者）的反应也很重要。主讲人对提出的问题可以有以下几种回应：

1. 证明问题不存在。这需要拿出合理的证据和逻辑。
2. 承认问题存在，承诺当场或者会后解决问题。
3. 承认问题存在，但是因为某些原因不解决这个问题。这需要讲出明确的原因。

这里又涉及到“讲和气”的问题，我见过的大多数主讲人在评审时倾向第2种反应，即承诺解决问题。但是经常后来发现他们并没有真正解决问题，于是下次评审我只能把问题再提一次。有时候反复提了几次，作者始终不解决问题，最后才承认是不打算解决。

其实不解决问题是个很正常的选择，在一开始就应该予以考虑。毕竟公司里做任何交付都是有成本的，面对各种各样的问题，解决时需要予以取舍。只要把解决问题的成本和收益亮出来，大家评价一下，一般也不难达成共识。但是这里经常碰到的一个难题又是“面子”问题：有的主讲人总是闪烁其词，编一些不存在的理由说这个问题无法解决，或者解决方案有其他副作用，在借口都被戳穿后才不得不承认是因为时间不够来不及解决了。这种反应也会降低评审的效率。

上面的3种回应是合理的讨论逻辑。但是，我还经常碰到很多不合理的逻辑，这些回应就值得拿出来说说了：

“保持XXXX（不解决问题）这样是不是也可以。”

这是不想解决问题，但是又不说原因。这个时候我会追问为什么不解决，接下来，主讲人就开始跳到问题逻辑的外面去了：“因为这块内容很重要”；“因为这里用的是xxx方法/模式”；“因为这题来自实际业务”；“因为这个材料对员工帮助很大”……说一大堆交付件的优点。但问题是我提出的是个具体的问题，又没有否认交付件的其他优点，现在我们讨论这个问题要不要解决，你跳去讲别的优点干嘛？难道有了某种优点，所有问题都不用管了？

评审是为了达成目标而提前发现问题的，不是给交付件评出三六九等的。这种人可能是把评审当成考试了，觉得多让评委看看优点，可以给自己打个高分。但是工作不是考试啊，评审人给你打个高分，目标就能自动达成了吗？

“这个结论没问题。”

这是当评审人质疑交付件中的某个结论时，常见的一种回应。但问题是评审要看的是证据和逻辑，主讲人什么证据逻辑都没有，却一个劲的强调没问题。这样的讨论是无效的。

有时候，主讲人会拿出一些看似证据的东西，但实际上都证明不了结论。比如：“我周围的人都是这么干的”；“我们这样做了好多年了”；“这是那个XX级专家说的”；“这个已经在XX组织评过很多次了，不用质疑了”……所有这些说法都是在回避提供证据。一般我只要碰到这么说的，会更警觉的坚持要求看证据，因为这里很可能掩盖着更大问题。

还有的时候，双方在一些关键证据和逻辑上存在分歧，始终无法达成一致。碰到这种情况，我的建议是每一方都把自己的证据和完整逻辑写出来。写作是对逻辑链的一个很好梳理。对于不涉及机密信息的纯技术问题，最好发表到内部或者外部技术社区上进行公开讨论。技术圈里的高手很多，旁观者的观点很可能会产生启发。

“你这是在抬杠。”

这句话听起来似乎有点冒犯评审人，在给人扣帽子。但如果细想一下，它隐含的意思很可能是说评审人的逻辑存在谬误。我如果听到这话我会反思下自己讲的逻辑，同时追问是哪个地方逻辑不对。即便如此，也建议主讲人直接讲明白具体的逻辑错误，不要用这种结论式的语句，因为它对讨论没有帮助。

从工作的角度，评审人的工作职责是发现和指出交付件中的问题。你说指出问题是不是“抬杠”呢？如果是，那我作为评审人，我的工作就是来跟你“抬杠”的。

“我做了XX年的XX业务了，你做过没？你学过XXX没？”

这同样是不承认问题，但是又不愿意给证据。同样的，这种回应对讨论没任何帮助。而且，看了本文前面关于专家的论述就知道，拿资历来压别人，只能说明自己连技术工作的基本特点都没搞明白。评审人如果确实有知识盲点，即使看起来是个基础常识，承认自己不懂并请教别人也不应该是丢脸的事。拿这种事来羞辱别人的才是真丢脸。

所以，对这种回应，我的回答一般是：“我做没做过XX业务跟这个问题一点关系都没有。你既然这么熟练，证据应该很容易就能找到，赶快拿出证据来吧。”

“你这样搞，我们工作的指标就达不成了。”

说出这种话的人一般默认评审人应该“讲和气”，碰到问题睁一只眼闭一只眼，最后大家默契的“快速高效”完成表面指标。碰到我这种不讲和气的，就用各种方式暗示我不要较真。我倒觉得与其这样暗示，不如直接“明示”：“XX领导说这个问题不用管”。听到这句话后，如果我确认这事在那个领导权力范围内，而且领导确实有这个要求，那我也会听从。但是大多数时候主讲人其实是不想让领导知道有问题。

“你们说怎么改就怎么改，我都行。”

对于关键逻辑点上的问题，主讲人如果说这种话，表示他把交付件的逻辑放弃了。这是极其让人担心的一种情况。交付件的作者是建立逻辑的第一责任人，他都放弃对逻辑的看护了，那么交付件大概率陷入“无逻辑”的状态，目标也大概率达不成。事实上，即使评审人给出了具体的修改方案，主讲人也必须要审视该方案和自己交付件的逻辑是否一致，如果不一致应当给出原因并拒绝修改方案。逻辑是对目标的保证，放弃逻辑就是放弃目标。

总之，高效评审的关键是讲逻辑和证据。如果每个参与评审的人都积极的理解别人的逻辑，同时清晰明了的讲自己的逻辑，相信高效且有效的评审不是件难事。