jason思想学习笔记

2020/02/18 13:02

jason推荐了一篇介绍facebook集体ownership工程文化的一篇文章 https://engineering.fb.com/culture/engineering-culture-code-ownership/ 看完非常有启发,感觉对工程和产品都有帮助,提炼了一些核心观点也加了一点自己的理解分享给大家

所谓集体ownership就是代码不属于任何个人,大家都可以修改,相对比如即刻现在的情况,有需求提给repo的owner非常不同,文章里讲了individual ownership的一些好处和坏处

直接的好处:
模块有具体明确的负责人,有需求/出了问题知道改找谁
模块专人维护有一致的代码质量保证,更好的支持和文档

而facebook不采取individual ownership是因为他们的核心价值是产生impact和关注个人和公司的成长,这些是和individual ownership违背的

对公司来说:
专家(也就是某个代码的owner)很难被challenge,因为他专注在一个领域,和其他人的knowledge gap会越来越大,他积累的地位使得在争论中获得有利地位,而争论能带来的创新也就减少了
这种情况下对模块的创新只能来自专家(因为只有他主导),但是专家对现存的设计细节已经非常习惯了,也产生了一些固化思维和偏见,也会有意无意的排斥外部的颠覆性创新想法
新的工程师也会跟随专家的意见,不敢发表和实现自己的想法,也会把责任都等待专家来解决,不敢或不愿自己动手
在这种情况下公司对变化的适应能力也会变弱,如果一个公司在成立初期就有巨大的创新,工程和产品团队后面的工作只需要维持和优化,那么这种形式是行的通的,但是一旦市场发生变化,就不知如何应对了,这样的例子大家应该都能想出不少

对个人来说:
维护某个组件的owner经过一段时间会进入舒适区,对现有代码的知识和掌握程度比改进他变得更加重要,代码已经按他熟悉的形式组织好了,只需要轻松的小修小补来延长代码的寿命,也能对其他人产生帮助
会不愿意承担风险,只要让组件能运行下去就是最好的,没有动力做大的创新,也就很难学习掌握新东西和产生大的impact(有点像一直在做即时满足的事
时间久了,个人的职业生涯甚至会变得局限,觉得自己只能做某个领域的工作

facebook的实践给刚加入的工程师一些困惑的印象,也算是他们认为可以接受的cost吧:
没有一个指定的专家来解答问题,实现缺失的feature和修bug
没人来保证代码一致,代码很快会变得年久失修
大家经常会引入新的组件和框架,甚至和现有的产生冲突,也可能引入不成熟的,缺乏维护的组件框架

我们知道大部分公司都是个人作为代码的owner,那么facebook是怎么产生这种独特的集体ownership文化呢,无责任猜想一下,我觉得和facebook提倡的move fast and break things 有关,在个人ownership的时候,我们常常因为依赖别人负责的模块不得不block在他的改动上,而要move fast,更好的做法是自己动手,但对自己不熟悉的代码动手自然会时常break things,大部分公司的move fast有个不要break things的前提,这对电商或是google这类公司是合理的,因为他们的系统价值来自于交易(对goolge来说交易来自于搜索请求),所以要时刻为产生交易做准备。而对facebook,twitter这类社交网络/媒体来说,他的长期价值来自于用户黏性,所以需要持续创新,为了实现长期的价值,短时间的break things也是可以接受的。想清楚了这个优先级,自然能提出move fast and break things这个口号。

这些观点也让我对代码的价值产生了新的思考,代码的价值来自于他产生的功能,至于他的可维护性可读性,都是附加值,facebook甚至为了核心价值可以很大程度放弃附加价值,算是做的比较极致的,他们愿意也有足够的资源去反复重建已经难以维护的系统(网上有一些证据 https://www.reddit.com/r/programming/comments/3r90iy/facebooks_code_quality_problem/ )。当然对其他公司来说,需要找到自己的平衡,如果功能在迭代过程中不断扩大价值,那么保证可迭代的质量也是非常重要的。