Facebook 如何发布代码 (How Facebook Ships Code 译文)

　　按：这篇 How Facebook Ships Code 提供了大量的细节信息，之前已经有朋友提供了一个翻译版本，阅读之后发现有些许错误，并且原文有更新，所以基于前面的翻译版本我重新翻译了一个(完整的)版本。一并谢过。希望这个版本对大家也有所参考。

　　我对 Facebook 的运作方式着迷。这是个非常独特的环境，很难被复制(这个方式并不适合所有的公司，即使有些公司尝试过这么做)。下面这些笔记来自我和Facebook的许多朋友的交谈，关于他们开发、运维与软件发布等方面。

　　好像很多人都对 Facebook 感兴趣… 这家公司的工程师驱动文化(Developer-driven culture)已经被公众大加研究，并且其它其它公司也在探求是否/如何实现工程师驱动文化。Facebook 的内部流程实在够神秘，当然，工程师团队也会发布一些关于新功能以及部分内部系统公开备忘，不过这些大多数是”说明”类的文章(What)，而非讲述”机制”(How)… 所以，外部人员很难明白 Facebook 的创新以及如何比其它公司做到更有效的对服务进行优化。我作为外部人员尝试深入理解 Facebook 的运作，汇集了几个月来的这些观察信息。出于对信息来源的隐私保护，我去掉了特定功能/产品的名字。我又等了6个月以后才发布这些记录，所以，有些信息肯定过时了。我希望发布这些信息会有助于了解 Facebook 的管理机制如何在组织中进行决策的推行而非逐步陷入混轮…很难说这与 Facebook 的成败或是 Facebook 的产品协作相关。我相信很多面向消费者的互联网公司会从 Facebook 这个案例受益。

　　*非常*感谢那些帮助我整理这篇文章的 Facebook 内部的朋友们。也要感谢项 epriest 和 fryfrog 这样的朋友，他们协助我进行对本文进行校正、编辑。

　　记录：

　　截止到2010年6月，Facebook有将近2000名员工，10个月前只有大约1100人，一年之间差不多翻了一番!

　　工程部和运维部是两个最大的部门，每个大概都有 400-500人。这两个部门人数大约占了公司的一半。

　　产品经理(PM)与工程师的比例大约为1-7到1-10。

　　每个工程师入职时，都要接受 4 到 6 周的 “Boot Camp” 培训，通过修复Bug 和听更资深的工程师的课程来熟悉 Facebook 系统。每次 Boot Camp 大约有 10% 的人无法完成课程而被淘汰。

　　培训结束后，每个工程师都可以访问线上的数据库【标准课程”能力越大，责任越大” ( “with great power comes great responsibility”) 对此有阐释，另有一份明晰的”不可触犯的天条”，比如共享用户的隐私数据】。

　　[修改, 感谢 fryfrog] “Facebook 有非常牢靠的安全保障，以免有人(你可以想象内部有人有这个权限的)不小心/故意做了些糟糕的的事。如果你已经”成为”了需要别人支持的人，事由将被记录，并且有谨慎的审计。这里不允许钻空子。

　　任何工程师都可以修改Facebook的代码库，签入(Check-in)代码。

　　浓厚的工程师驱动文化。”产品经理基本可以被忽略”，这是Facebook一名员工的话。工程师可以修改流程的细节，重新安排工作任务，随时植入自己的想法。[评论] “本文的作者是一个产品经理，所以这个论断引起里我的注意。你看完整篇文章后会发现，很显然，Facebook 的文化实际上是拥抱产品经理的实践的，所以，不是产品经理的角色被忽略，而是，这家公司的文化看上去是想让”每个人”感受到对产品的责任”。

　　在每月的跨部门会议上，由工程师来汇报工作进度，市场部和产品经理会出席会议，也可以做些简短的发言，但如果长篇大论的话，将如实反馈给他们的主管，”产品人员在上次会议说的太多”。他们确实想让工程师来主导产品的开发，对自己的产品负责。

　　项目需要的资源都是自发征集的：

　　某个产品经理把工程师们召集起来，让他们对自己的想法产生兴趣。

　　工程师们决定开发那些让他们感兴趣的特性。

　　工程师跟他们的经理说：”我下周想开发这5个新特性”。

　　经理会让工程师独立开发，可能有时会让他优先完成一些特性。

　　工程师独立完成所有的特性 — 前端 JavaScript/后端数据库，等等所有相关的部分。如果需要得到设计人员的帮助，需要先让设计人员对你的想法产生兴趣(专职的设计师很少)。请架构师帮忙也是如此。但总体来说，工程师要独立完成所有的任务。

　　对于某个特性是否值得开发的争执，通常是这么解决的：花一个星期的时间实现，并在小部分用户中(如1%的内华达的用户)进行测试。

　　工程师通常乐衷致力于架构、扩展性以及解决”难题”，那样能获得声望和尊敬。他们很难对前端项目或用户界面产生太大的兴趣。这跟其他业务为导向的公司可能正好相反，那些公司人人都想做客户能直接接触到的东西，然后会指着某个特定的用户体验说，”那是我做的”。在 Facebook，后端的东西，比如 News Feed 算法、广告投放算法、Memcache 优化等等，是工程师真正倾慕的项目。

　　News Feed 因为太重要了，扎克会亲自审查任何变动。这是个特例。

　　[更正, 感谢 epriest ]“所有的代码变更都要经过强制性的代码审查(比如一个或者多个工程师)。我相信这篇文章只是说 扎克并不自己审查每一个变更”。

　　[更正, 感谢 fryfrog ]“所有的修改至少要被一个人审查，而且这个系统可以让任何人很方便地审核其他人的代码，即使你没有邀请他。提交未经审查的代码，将被视为恶意行为”。

　　工程师负责测试、Bug 修复以及启动对自己项目的维护。有单元测试和集成测试的框架可用，但很少使用。

　　[更正, 感谢 fryfrog ] “补充一下，我们是有 QA 的，只是没有正式的 QA 组而已。每个办公室或通过VPN连接的员工会使用下一版的 Facebook，这个版本的 Facebook 会经常更新，通常比公开的早 1-12 小时。所有的员工被强烈建议提交 Bug，而且通常会很快被修复”。

　　回复：很奇怪只有很少的 QA 或自动测试 — “大部分工程师都能写出基本没有bug的代码，只是在其他公司他们不需要这么做。如果有 QA 部门，他们只要把代码写完，扔给他们就行了” [编辑：请注意这是很主观的，我选择包括这部分内容是因为这和那些其它公司的标准开发实践完全相反]

原文转自：http://dbanotes.net/arch/facebook_how_facebook_ships_code.html