非死book创始人扎克伯格亲自审查核心代码

导语：美国科技博客网站 BusinessInsider 今日撰文揭开了 非死book 程序设计人员的神秘面纱。非死book 代码从开始编写到最终发布，都有着极为严格的程序，CEO 马克·扎克伯格(Mark Zuckerberg)甚至对 News Feed 每个代码更新亲自把关，确保不出现任何差错。

工作中的扎克伯格

非死book工程师是这家社交网站巨头最有价值的财产，他们拥有非常大的自主权，但同时也面临着尽快发布高质量代码的压力。

谷歌(微博)员工李易(Yee Lee)通过与大批非死book工程师的交谈，在一篇博文中披露了非死book代码发布流程。这个流程的确与外界之前想象的相差无几，虽然 非死book对代码发布的监督比人们预想的更为严格。尽管这篇博文发表于一年前，但整个流程自非死book上市以来似乎并未发生太大变化。

非死book员工主要由工程师构成，人数最多的两个团队分别是Engineering和Ops，总计占了非死book员工总数的一半左右。此外，非死book还有大量产品经理。他们要确保代码按时发布。每一个产品经理负责7到10名工程师。

非死book所有工程师都要接受4到6周的培训，学习非死book修复漏洞的方法，聆听资深雇员举办的讲座。在进入“训练营”(Boot Camp)的工程师当中，会有大约10%无法顺利通过测试，最终被劝退。

接受完培训以后，工程师开始接触非死book数据库。他们可以随意核对代码，对数据库做出修改。员工们还会拿到一张“禁做之事”名单，如禁止分享用户数据。尽管如此，非死book还出台了一系列措施，防止此类事情的发生。

同谷歌一样，非死book的企业文化同样以工程师为主。一名工程师说：“产品经理基本上在这里毫无作为。”工程师可以修改尚未正式上市的产品规格，在任何时间提出新的功能创意。

工程师会在每月一次的不同团队例会上提交他们的成果。产品推广经理和产品经理会出席这些会议，但不被鼓励畅所欲言。“如果产品经理在例会上畅所欲言，工程师们就会向领导层反应说，‘上次会议上他们有关产品的意见太多了’。”

在非死book，工程师想做什么，基本上都由他们自己决定。他们会找到主管，说：“这是我想做的五件事情。”产品经理会说服工程师当场试一试，让他们亲身体验这些项目的效果，但他们多数情况下不会对每位工程师的偏好横加干涉。

工程师们不会争论某项功能是否值得尝试，而是开发出原型机。接下来，工程师会用一周的时间开发某项功能并进行测试，以确定它是否值得推出成品。通 常情况下，新功能都是由非死book员工亲自测试。整个过程由一款名为“Gatekeeper”应用控制。这是非死book“黑客”文化的主要组 成部分——快速开发和推出产品，淘汰没有市场前景的产品。

在非死book，每个人都想参与后端产品的开发。可伸缩性和基础架构是工程师最感兴趣的两个问题。所以，工程师很难对实时消息等前端产品感到 兴奋，相反，每个人都希望从事像News Feed算法这样的后端产品。这种做法与其他消费类科技企业的惯例背道而驰，在这些企业，员工都希望参与前端产品的研发工作。

非死book 创始人兼CEO马克扎克伯格(Mark Zuckerberg)会亲自对News Feed每个代码更新把关。在非死book，所有重大升级的代码都进行强制评估，任何一个改动都至少由一人把关。但是，无论工程师对News Feed做出任何改动，都将由扎克伯格亲自把关。

非死book工程师负责测试产品功能，修复产品漏洞，对发布以后的产品进行维护，但他们并不是官方的质保团队。不过，非死book仍然有负责质量评估的工程师，并积极鼓励每位工程师报告产品漏洞。

正常情况下，代码升级会在每周二发布。非死book有专门的评估工具，告诉工程师代码更新的风险有多大。

运营团队会逐步推出代码更新。非死book共有大约6万台服务器，运营团队会逐步将更新后的代码发布到少数几台服务器上，确保它能起作用。最 开始是6台服务器，接着慢慢增加。如果需要做出修改，那么这项工作会由提交代码更新的工程师在线下完成。修复工作完成后，代码会再次在那6台服务器上先试 用，接着增加到更多的服务器上。

在代码更新发布期间，运营团队会通过IRC和其他实时聊天工具一对一通知工程师，他提交的代码是否需要修改。如果修复以后的结果仍然难以令运营团队满意，当事工程师会被“当众羞辱”，虽然李没有提供有关这方面的具体细节，但他说如果这种情况经常发生，工程师会被炒鱿鱼。

原文  http://www.techug.com/非死book-mark-zuckerberg-review-code