去年12月SD2.0大会我们邀请了Facebook的蒋长浩作为演讲嘉宾。之前他和同事魏小亮（David Wei）也参加了淘宝与O'Reilly举办的Velocity China 2010大会。再加上更早的Hadoop China大会期间与邵铮等Facebook工程师的交流，让我对这个现在最热门的技术公司独特而高效的开发流程产生了浓厚兴趣，特别是这几点：工程师而非产品经理主导，招聘时百里挑一，很多开发人员都非常年轻，工作起来热情很高，能迅速完成交付，几乎没有什么正儿八经的测试。质量依靠的工具和数据分析。
这两天Skype负责产品的Yee Lee在博客上发表了一篇名为How Facebook Ships Code的文章，迅速登上Reddit和Hacker News等技术网站头条。因为《程序员》杂志第2期正要出刊，没有来得及翻译。今天看到凤凰网的李忠已经翻译出来了，而且质量不错，特推荐给大家。
译文原名“Facebook是如何管理代码的”。具体文字我根据原文的变动又做了一些补充，并改正了一些明显的误译。
CSDN和《程序员》将组织一系列文章，更全面深入地介绍Facebook的经验，敬请期待。（刘江）
我对Facebook的运作方式一直着迷。这是一个很独特的环境，不容易复制（他们的体系并不适合所有的公司）。我和Facebook工作的许多朋友们交流过他们开发和发布软件的方式，下面是交流笔记。
似乎还有其他人对Facebook有兴趣……比如这里以及其他公司的相关讨论。 然而，Facebook对自己的内部流程讳莫如深。他们的工程团队经常发布笔记介绍各种新的功能和内部系统，但都是一些“是什么”类型的文章，对如何开发却不怎么讲。因此对于外部人员而言，了解Facebook是怎样远比其他公司高效地创新和优化其服务，并非易事。为了更多地了解Facebook的运作，我花费数月时间收集了下面这些笔记。为了尊重来源的隐私，我删去了所有人名和具体功能与产品的名字。另外又等过了6个多月才对外公开，所以它们肯定会有些已经过时。我希望发表这些笔记有助于大家了解Facebook是怎样致力于将决策下放而同时又不至于陷入混乱的。Facebook这样做的结果以及其产品是否成体系很难评判，我认为并希望许多面向消费者的互联网公司能从中有所裨益。
非常感谢那些帮助我整理这篇文章的Facebook的朋友们。同时也感谢提出指正的Reddit网友epriest 和 fryfrog 。
笔记
截止到2010年6月，Facebook有将近2000名员工，10个月前只有1100名，一年之间差不多翻了一番。
两个最大的部门是工程和运维，每个部门大概都是400～500人。这两个部门人数大约占了公司的一半。
产品经理与工程师的比例大约为1:7到1:10。
每个工程师入职时，都要接收4～6周的培训，通过修补bug和听高级开发工程师的课程来熟悉Facebook。约10%的受训者无法通过，并被请出公司。
培训结束后，每个工程师都可以接触线上的数据库（更大的权力意味着更大的责任，也有一份"勿做清单"，写明那些行为会导致被开除，比如分享用户的隐私数据）。
[根据网友fryfrog意见修改] 有非常牢靠的防范体系，以免内部人员做恶。如果应要求需要以其他人的身份做事，必须将原因记录，并接受严格审查，此外都是严厉禁止的。
每个工程师可以修改Facebook的任何代码，随时可以签入（check-in）。
浓厚的工程师驱动文化。"产品经理基本可以被忽略"，这是Facebook一名员工的原话。工程师可以修改流程的细节，重新安排工作任务，随时植入自己的想法。（作者原注：我就是产品经理，当然对这一点特别关注。其实从下文可以看出，Facebook的文化其实全面吸收了产品管理实践，他们不是忽视产品管理，而是创造了一种人人对产品负责的文化。）
在每月的跨部门会议上，由工程师来汇报工作进度，市场部和产品经理会出席会议，也可以做些简短的发言，但如果说得太多，很可能就会被打小报告。他们确实想让工程师来主导产品的开发，对自己的产品负责。
项目需要的资源都是绝对自愿的
产品经理游说工程师，让他们对自己的想法产生兴趣。
工程师们决定开发那些让他们感兴趣的特性。
工程师跟他们的经理说："我下周想开发这5个新特性"。
经理通常会尊重工程师的选择，可能有时会让他优先完成一些特性。
工程师负责所有的特性——前端JavaScript/后端数据库代码以及之间所有部分。如果需要得到设计人员（公司内部设计团队很小）的帮助，需要先让设计人员对你的想法产生兴趣。架构师之类的也是一样。总体来说，工程师要完成所有的任务。
对于某个特性是否值得开发的争论，通常是这么解决的：花一个星期的时间完成，并在小部分人群中（如1%的内华达用户）进行测试。（刘江注：蒋长浩介绍，实际操作时通常会选择某些服务器上的用户进行测试。）
工程师总是希望解决基础设施、可扩展性以及其他难题，这能获得声望和尊敬。他们很难对前端项目或UI设计产生太大的兴趣。这与其他公司工程师喜欢做前端并向用户吹嘘“看，这是我做的”的情况，可能正好相反。在Facebook，后端任务，比如新的feed算法，广告投放算法，memcache优化等等，是工程师真正感兴趣的。
所有的代码修改必须经过审查（通过一个或多个工程师），但News Feed是个例外，因为太重要了，Zuckerberg会亲自审查所有改动。[根据网友epriest意见更正]
所有的修改至少要被一个人审核，而且系统可以让任何人很方便地审查其他人的代码，即使没有得到邀请。签入未经审查的代码将被视为恶意行为。[根据fryfrog]
工程师负责测试、代码修复和维护自己的项目。有一些单元测试和集成测试框架，但只是偶尔使用。
还是有QA环节的，只不过没有正式的QA部门。每个办公室或通过VPN连接的员工会使用下一版的Facebook，这个版本的Facebook会经常更新，通常比公开的早1～12小时。所有的员工被强烈建议提交bugs，而且通常会很快被修复。[根据fryfrog更改]
对于很奇怪只有很少的QA或自动测试的说法，Facebook员工这样回复："大部分工程师都能写出基本没有bug的代码，只是在其他公司他们不需要这么做。如果有QA部门，他们只要把代码写完，扔给他们就行了。" [作者原注：这当然是主观之见，我加上这一条是为了与其他公司的标准实践做比较。]
[epriest对上一条的意见] 我们有自动测试，包括代码发布前必须要通过push-blocking测试。我们不相信"所有的工程师都能写出没有bug的代码"，更不可能将公司基于这样不靠谱的理念。
对于很奇怪缺少产品经理的影响和控制的回复：产品经理是很独立的和自由的。具有影响力的关键是与工程经理们搞好关系。需要大致了解技术，不要提一些愚蠢的想法。此外，确立路线图/backlog时，无需任何许可或者通过什么评审。产品经理相对比较少，但是他们都觉得自己负责的是公司确实重要而且自己也有兴趣的领域。
所有提交的代码每周二默认打包发布一次。
多费点力气的话，修改也可以在同一天发布。
星期二代码发布时，需要所有本周提交过代码的工程师在场。
代码打包前，工程师必须在一个特殊的IRC channel上候命，否则会被公开批评。
运维团队是逐渐发布代码上线的：
Facebook有大约60000台服务器
有9个代码发布级别（[epriest]这些级别并不都是全局的，只有三个全局：p1=内部发布，p2=小规模外部发布，p3=完全外部发布。其他6个是辅助性的，包括内部工具、视频上传等）
最小的级别只有6台服务器
比如，星期二的代码发布会先发布到6台服务器上（级别1），运维组会观察这6台服务器，保证代码正常工作，然后再提交到下一级
如果发布出现了一些问题（如报错等等），那么就停止下一级的部署，提交出错代码的工程师负责修复问题，然后从头继续发布。
所以一次发布可能会经历几次重复：1-2-3-fix，回到1，1-2-3-4-5-fix，回到1，1-2-3-4-5-6-7-8-9
运维团队是受过严格训练，倍受尊敬，而且很懂业务的。他们的工作包括分析错误日志，负载和内存使用状态等等。还包括用户行为。比如，如果一个新的发布改变了用户使用某些Facebook特性的百分比，运维团队会从数据中看到，可能因此停止发布，进行调查。
代码发布期间，运维组使用基于IRC的呼叫系统，如果需要，可以通过Facebook/email/irc/im/sms找到每一个工程师。对运维组不做回应会被公开批评。
代码一旦发布到第9级，并且稳定运行，就算发布成功了。
每周发布时如果一个特性没有按时开发完成，也没什么大不了的（除非有严重的外部依赖），特性通常都是完成后再发布。
如果被svn指责、公开批评或项目经常延期，工程师就很可能被开除。"这是一个高绩效的文化"。不够高效或者不够聪明的员工会被剔除。经理们会在6个月的时间里观察你表现，如果不合格，只能说再见。每一级都是这个待遇，即使是C级别和VP级别，如果不是特别高效，也会被开除。
[epriest]代码中有bug不会开除。只在发布时要求加入自己的修改代码，却在出错时没有提供支持（而且也没有让别人替你），才会被开除。
[epriest]被责骂不会导致解雇。我们在这方面特别宽容。大部分高级工程师都或多或少犯过一些严重的错误，包括我。就我所知，没有人因此被解雇。
[fryfrog]我也没有遇到过因为上面提到过的犯错而被解雇。有些人犯了错，他们会非常努力地去修复，也让其他人得到了学习。在我看来，公开批评比用解雇来吓人更有效。
我非常感兴趣的是，Facebook的开发文化接下来会怎样演变，当公司发展到几千员工的时候，这种文化还能继续扩展吗？
你怎么看？开发人员驱动的文化在你们公司能推行吗？
（CSDN注：Hacker News、Slashdot和Reddit上的讨论也很有价值。