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/ ）。当然对其他公司来说，需要找到自己的平衡，如果功能在迭代过程中不断扩大价值，那么保证可迭代的质量也是非常重要的。

宪学宪卖

jason思想学习笔记