“惠普之道”和Monorepo

如今听说过“惠普之道”的人,估计都是至少四十岁以上的了。我刚毕业那几年,大家都在说“惠普之道”。《惠普之道》是一本九十年代的书,英文书名叫”The HP Way“(我估计 “Aliway” 也是从 “The HP Way” 来的)。那时候惠普在大家眼里是一个成功的公司,Carly Fiorina是那时候最火的CEO,江湖地位堪比今天的Elon Musk。

二十年过去了,现在很少听到有人讲“惠普之道”了,我甚至怀疑如今刚毕业的大学生可能连惠普这个公司都没听到过。现在大家都在学谷歌,因为谷歌是一家成功的公司。其实,谷歌成功已经有很多年了,只不过出圈需要一个过程。以前谷歌还只在圈内红火的时候,大家已经在学了,大家都在说 20% time 怎么怎么好,怎么怎么培育创新。

这两年好像不太听到有人讲 20% time 了,这几年大家都在学谷歌的 OKR。满眼都是各种文章阐述 OKR 的精髓是什么、OKR 和 KPI 的本质差别是什么、为什么 OKR 比 KPI 好。甚至连有些政府部门都在搞 OKR。虽然有很多人 clarify 说我们搞 OKR 并不是跟风、并不是因为谷歌搞了 OKR 所以我们也要搞,但夜深人静的时候扪心自问,如果谷歌没有那么成功,OKR 还会有那么多人学吗。

这样的例子还有很多。二三十年前,通用电气如日中天的时候,大家都学通用电气的末位淘汰,感觉末位淘汰是保持大公司企业活力的关键。后来通用电气走下坡路了,大家就开始反思,反思末位淘汰是不是导致微软的企业文化问题的原因,一家接着一家的公司都把末位淘汰和 curve 给取消掉了。

图片

谷歌之后最红的科技公司是 Facebook。Facebook 声名鹊起的那段时间,大家都学 Facebook 搞 Hackathon ,但这两年大家讲 Hackathon 渐渐讲的少了。真正被 Facebook 带红的是 Monorepo(大库)。或者说,Monorepo 是被谷歌和脸书两家一起带红的:谷歌和脸书都是用大库的,那肯定不是巧合吧,而且谷歌和脸书的研发效能的口碑都是顶流的,让人不得不相信大库一定在里面起到了很大的作用。

大库其实也有大库的痛苦。上周我做了一个 diff,把六十几个 Dockerfile 里面 pip install 的 “-vv” 参数给去掉了(that’s a story for another day)。这个 diff 到现在还在等 code review,因为这个 diff 动了十几个微服务的 Dockerfile,要那十几个团队的人都 code review 通过了才能 land。除非我一个个 team 一遍遍的催,否则估计这个 diff 永远没法合并了。

大家都说大库的好处是做这种大面积 horizontal 的改动比较容易。我看也不见得有多容易。看样子,到头来我可能还是会把这个大 diff 拆成十几个小 diff,每个微服务一个 diff,单独做 code review。但这样搞一堆小 diff,那和每个微服务单独一个 repo 有啥差别呢。

2 Comments

  1. 那除了这种“见好就学”的方式外,还有什么更好的进步方式呢?

    Reply

  2. 如果是小库,感觉你可能都找不全这60几个dockerfile :)

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s