Google 的经验

看了一篇讲谷歌公司内部的软件管理的论文,虽然对很多东西已经很熟悉了,但还是觉得有了一些新的启发。

业内对 Google 其实大多数都是一种追随者的态度。单说最近这些年的几大热门产业,大数据由 Google 的三篇论文起始,云计算由 Kubernetes 引领热潮,
Alphago 在 AI 领域让人震撼。Google 比其他公司更早面临了很多技术发展的瓶颈之处,解决之后在某个时机将部分成果开源出来共享给业内。技术问题大家很容易采纳学习,但能解决这些问题的软件工程模式,
则不是那么容易学习的。

Single Repo#

Google 在公开这种模式之后,大部分人的态度是震惊的。因为这跟大部分人的使用模式差别很大。不管是大公司小公司,不同功能的 Repo 对应不同的功能,非常便于维护,便于划清职责。Google 的单一 Repo 模式,尤其在其规模之上,初看起来是非常难以理解的。上 Tb 的仓库数据,每天上万次的 Commit,它是如何管理的呢?

问题的答案自然是一套更为复杂的 CI/CD 系统,每一次的提交,自动化的构建、自动化的测试、自动化的 Review Check 等等,有了这些之后,代码的基本质量就有了保证,其他的就靠更为严格,精确的 Code Review 流程了。之所以大部分公司无法这样做,因为基础的 CI/CD 系统从来都不是一个公司在成长过程中优先考虑的问题,功能 -> 性能 -> Bug, 这些问题解决的差不多了,才有考虑其他的空闲。而往往此时,开发模式已经固定下来,没有了往 Single Repo 迁移的动力。

另一方面,Single Repo 带来的优势初看起来也是比较模糊的。它更多的不是一个技术上的问题,而是一个管理模式,或者企业文化上的问题。

  1. 是否能允许员工查看几乎所有的源码 Repo
  2. 如何在 Single Repo 中划分各个项目的职责边界

对 Google 来讲,去掉这个边界是必须的。他希望员工能够熟悉整个系统,不受限于自己所主要维护的组件的束缚,保持一个开放的心态。每个人都有创造的天性,当他发现有一个其他项目的问题或者优化他很想修复,或者有更好的解决方式,没有了项目的边界,他很自然地认为可以这样做也应该这样做。这种开放的模式保证了 Google 的所有项目能受惠于公司所有人的才智,也造就了 Google 在技术和商业上的成功。

Personal Time#

这也是人人熟知,但几乎没有任何经常自称有 Google 背景的管理人员愿意尝试的模式。给员工留一些时间,让他做自己想做他任何想做的事。对于 Google 来说,有很多项目和改善都是来自于员工在这个时间的 Side Project。

联想起最近比较火的996,更是一种莫大的讽刺。在资本家眼里,开发人员不是一个个有创造性地个体,而是一个个贡献时间的螺丝钉。

软件行业的特殊性在于,技术本身迭代的速度太快,开发人员必须每天有专门的时间来 Catch Up。但这个 Catch Up 的效率和稳定性,每个开发人员都不一样。对于国内的资本家来说,他选择放弃信任自己的开发人员,让他们把这块时间共享给公司,虽然效率极低,但是对老板有安慰剂效应。而经历了资本主义黑暗时代的资本家和工人,达成了一种更为合理的制衡模式:互相有一定的信任基础,让人能均衡工作和生活的时间。

人性自有其很暗之处,心存侥幸,只会反噬于自身。


  转载请注明: Hang Google 的经验

 上一篇
视频测试 视频测试
2019-04-15 Hang Yan
下一篇 
Github 与编程语言 Github 与编程语言
一个语言的流行程度与多种因素相关,语法的简易性,package 的数量,性能,适用的场景等等。Perl 因为语法的怪异而逐渐无人问津,ROR因性能等问题也用的人越来越少。一向处于主流地位的 C/CPP 在这几年也比不上 JavaScript
2019-04-12
  目录