LGTM

Google 是一家工程师文化浓郁的公司，而其中让我感触最深的环节有两点，代码审核 (Code Review) 以及设计文档审核 (Design Doc Review)。今天先说说 Code Review，简称 CR。

在 CR 流程里有两个最常用的术语，1个是文章标题里的 LGTM (Looks good to me)，1个是 PTAL (Please take another look)，前者对应的是评审人 (reviewer) 通过了评审，后者对应的则是作者 (author) 根据 reviewer 的意见进行完修改后，请求 reviewer 再进行评审。评审的过程就像一个踢皮球的过程，你来我往，直到最后迎来一句 LGTM。

Google 的 CR 是比较严格的，尤其是对于刚加入 Google 的新人来说（不管对方之前有多少年的工作经验），一开始的几个 CR 评审往往是个很漫长的过程。自己当初加入 Google 时已经有了 5 年的工作经验，而且那时自认为代码水平也还可以，毕竟数据库引擎，UI 框架，网络库都写过而且用在了工业级产品中，结果在 Google 的第一个正式 CR 大概来回了有 1 个月 😅

虽然 Google 的 CR 有时是吹毛求疵，但确实能让人在这个过程中逐渐锻炼出扎实的工程能力，越来越能自然写出简洁，可读的代码（相比于 Google 在面试时考算法题，在实际工作中，写出可读的代码才是最重要的)。无论对于 Author 还是 Reviewer，每一次 CR 认真对待的话，都是很好的锻炼机会，这其中当然对于 Reviewer 会有更高的要求。

因为 Google 的代码大多数是开放的，所以有时一个 CR 里参与的同事可能来自于完全不同的部门，而能在同一个 CR 里与素不相识的高手过招也是一件有意思的事情。我自己就有一次和 Sanjay Ghemawat 一起 review 了另一个同事的基础 API (我是作为 API 的使用方，而 Sanjay 则作为整个基础设施的总体负责人)。那次先由我来 review，几个来回等我 LGTM 后，再由 Sanjay 出马。后来看到 Sanjay 在我 review 的基础上又挑出 10+ 个问题，这个过程也让我学到了不少东西。

当然有人会觉得这样的 CR 流程会影响产品的迭代速度。这个判断是没有错的，Google 的产品迭代速度确实很糟糕，内部吐槽很多，许多时候我自己也觉得冗长的 CR 拉锯在大大地耽误产品的迭代节奏。不过这个问题也还要分开来看。

1. 一些格式，风格的问题，在 CR 里来回纠结确实没有必要。我猜 Rob Pike 他们就是看到了内部大家在这些问题上的磨叽，才一开始就在 Go 里引入了唯一的 gofmt。
2. 应用层的代码，我也确实觉得许多时候也未必需要那么严格，大致行就可以了。毕竟逻辑会变，连整个产品可能都会推翻，速度和迭代才是更重要的。
3. 基础层的代码，我觉得绝对是需要经过严苛的 CR，尤其是数据库 Schema 的设计，API 的设计。这也是为什么 Sanjay 作为整个 Google 基础设施的总架构师也会去仔细 review 一个基础 API 的设计。

而在国内，整体对于 CR 还不够重视，即使在大厂里，也只有极少的团队会认真地做 CR，也有能力做 CR (前面也提了，CR 对于 reviewer 的要求其实是更高的)。toC 业务基本都是 APP 工厂式应用层研发，快上快下，所以没有严谨的 CR 问题也不大（可能还是好事情）。而换 toB 的应用就完全不一样，因为 toB 都是持久战，顶层设计，建模设计，API 设计基本决定了产品能到达的高度，没有好的架构，缺乏工程纪律性，产品做个 2 年可能就会遇到瓶颈，各种模块盘根错节，很难再加新的功能。因为国内还是缺乏好的工程和架构人才，所以国内的 toB 产品普遍在经过一段时间的成长后，会面临架构设计缺陷导致的瓶颈，许多也无法突破，导致无法在产品上继续演进，最后只能是靠销售驱动的方式进行竞争。这两年国内很火的的低代码马上也会面临这样的局面。低代码是一个看上去起步简单 (CRUD 拼装) ，但其实对于技术架构要求很高的赛道，因为做的是 app builder 或者说是元应用 (meta-app)，这就需要比做一般 App 高的多的架构能力（和生产好的芯片需要更尖端的光刻机是一个道理）。

最后还是扯回 CR 的主题来，CR 如果真能在公司里推广开来的话，有时候也会催化出意想不到的场景。有次 Google 的一个实习生就用发 CR 的方式给一位他实习期间有好感的同伴发了约会邀请。而面对这样脑洞的套路，对方的回答也只能是这样了吧 ⬇️⬇️⬇️