XA™的图书主页-查字典图书网

黑客俱乐部〜

2013-04-17

本文带格式版发布在： http://aoxuis.me/2013/04/17/facebook-review/

##Move fast and break things.
快速发布，允许出错。Facebook的这句标语要分两部分来看。
天下武功，唯快不破，敏捷开发是工程师的基本修养，并不仅仅是写代码写得很快，其中的核心是运用迭代来管理开发，我认识的很多工程师都没有真正理解敏捷开发的管理方法，初级工程师很容易陷入到纯粹的技术问题上，而对一些思想和管理方法没有了解，导致层次仅限于人们常说的“码农”。
允许出错，是一个Facebook特色的理念，因为Facebook从早期是一个只有Web产品的公司，Web产品的发布特点是随时可以从服务器端修改，这样即使出错了，修复成本也很低。而且在早期，一个产品更重要的是验证是否满足了用户需求，而不是稳定性，所以快速发布比控制质量更有意义。对于我们现在做的iOS平台产品，发布是由Apple审核团队严格控制的，每一个版本的发布周期都比较长，如果线上版本出现bug，发布下一个版本修复问题需要至少一周的时间，所以每一个版本都应该追求阶段性完美，如何规划版本在iOS平台上成为一个重要的问题。现在Facebook已经是一个影响亿级用户的服务，这样的服务即使中断几秒钟，也是损失巨大的，而且随着员工数量的增多，哪怕每个员工只有千分之一的概率犯错，加起来也是不小的错误率，所以现在Facebook已经去掉了后半句，只保留了Move fast。如果是我们团队，我建议改成`Plan things and move fast`。

##开放环境
Facebook员工在这里改变世界。 ![env](http://ww2.sinaimg.cn/large/a74e55b4jw1e3sk7dabb9j.jpg)
开放式的办公环境我很喜欢，[虽然V2EX上讨论时比较有争议](http://v2ex.com/t/65298)，有人喜欢也有人不喜欢。不喜欢的人主要是认为如果在这种环境沟通，很容易影响别人。团队讨论对无关的人来说是一种噪音。几个人凑在一张桌子上显得拥挤。我认为这些问题都是可解决的：
1. 讨论区跟办公区相隔一定距离，尽量不干扰别人。讨论去会议室是个好习惯。
2. 桌子要大，每个人的可用面积至少要能摆得下3个显示器那么大，要有足够的置物空间。
在腾讯的时候每个人的座位比较宽松，可是每个人的座位是一种半开放的隔间，你和你对桌的人是有一块挡板隔起来的，你必须要站起来才能看到对桌的人。这样容易给人更多的隐私空间，但是不便于员工之间互相交流。老大们还有自己的办公室。
而Facebook选择这种开放式环境跟它的文化有关，它的愿景是[Make the world more open and connected](http://www.facebook.com/facebook/info)，开放的观念体现在Facebook的方方面面，从员工起就是这样，所有员工是一种扁平化的结构，没有强烈的层级观念，从事管理和技术工作的人没有高低之分，只是工作职责不同，连Mark Zuckerberg也是跟其他人坐在一起，座位并不比其他人大。相信不少人都见过这张照片，Zuck的桌上那张`Stay focused & keep shipping`的批萨盒很显眼。
![desk](http://ww4.sinaimg.cn/large/bfadf3bejw1e3sn9ba5qwj.jpg)
Zuck在公司内有固定时间，回答员工的任何问题，但是明确规定不允许员工对外人透露公司内部的情况，因为员工只有做到对外守口如瓶，才能做到对内知无不言。公司文化要求每个员工不是为了自己、为了团队、为了部门而工作，而是为了整个公司而尽力，所有人沟通顺畅，则事半功倍。在腾讯的同事都知道“部门墙”这个概念，表示部门与部门之间像有一道墙一样的沟通障碍。如果一个大公司能够保持Facebook这样的开放文化，真的很不容易。

##黑客文化
业内人士应该都知道由大公司举办的几个开发者大会，例如Apple WWDC、Google I/O、Facebook F8，其中F8这个名字是怎么来的？有人说是因为Facebook总共有8个字母，实际上是因为每次F8大会最后都有8个小时的Hackathon（黑客马拉松）活动，8是为了强调Facebook的黑客文化。关于Facebook的黑客文化，丰富到可以单独写一篇文章来阐述，这里只能点到为止。
###学习和创造
没有黑客会喜欢重复劳动和没有创造性的工作。黑客的最核心价值观是“所有信息都应该是自由传播的”。黑客的驱动力不是偷窃和破坏，而是学习和创造。Zuck作为公司的首席黑客，每年都会给自己定下挑战，2009年是坚持每天打领带，2010年要学中文，2011年是只吃自己亲手屠宰的动物（素食主义者），2012年坚持每天写代码。
###自己决定做什么
作者王淮在雅虎工作的时候，一个组提开发需求给另一个组，是需要很多次沟通的，而且需要提需求的小组老大找实现的小组老大沟通，然后另一方来分配工程师的时间。这样的官僚机构在Facebook是不可想象的，两边的对接工程师会直接沟通，自己定做不做、什么时候做、做到什么程度。这里有个前提是Facebook的工程师都具有较高的产品和项目管理素养，而不仅仅是一个完成别人分配任务的工具。
###激发兴趣
Hackathon鼓励参加的人尽量放下日常工作，完全根据兴趣开发，可以天马行空，不受任何约束。每个人可以发布自己想做的项目，然后聚集起感兴趣的合作者来共同完成，这些临时的搭档会激发出不一样的灵感。
###代码胜于雄辩
Code wins arguments. 黑客会迅速制作原型，看看是否行得通，而不是在会议室召开数天的马拉松会议来讨论最佳的方法。实际交付出东西的人比权力最大的人更能说服黑客。
###工程师驱动
Facebook和Google一样具有工程师驱动的文化，因为他们都拥有一流产品素养的工程师。他们不见得花所有时间在写代码上面，而是有很多时间要用于思考、设计和跟产品经理的合作。在整个产品的开发过程中，工程师和产品经理主导的比例大概是60：40。

##面试招聘
技术面试会细到要求你告诉面试官一行行代码怎么写，Facebook甚至做了类似[Collabedit](http://collabedit.com/)或[sync.in](http://sync.in/)这样的实时编辑工具，应聘者自己在电脑上写，面试官在另一边就能看到。面试官可能会问到Facebook碰到过的真实问题，看看对方会怎么解决，说不定老问题可以聊出新的火花。并且最好能说明自己的思路，卡壳的时候面试官会给出提示。Facebook会回避类似脑筋急转弯的智力型题目，重点都在具体的编程问题上。
除了技术面试，面试过程中会有20%的时间用来做文化适应性面试，介绍公司文化，确定应聘者与公司的核心价值观不冲突。例如Done is better than perfect(完成比完美更重要)；乐于团队合作，而不是单枪匹马；不要只听老板的话，要做一些自己的决定。最后是看应聘者是否有学习新东西的意愿和能力。
面试结束后，所有面试官会给应聘者打分，并给出具体的评价和理由。面试官必须在当天反馈评价，招人是Facebook第一优先级的工作。Facebook尊重每一个应聘者，希望这种高效率给应聘者留下好印象。就算应聘者不适合Facebook，也欢迎他们推荐自己的朋友来试试。招聘是竞争的第一步，业内一流人才如果没有进入你的公司，那他们就在竞争对手的公司服务。这意味着，产品还没在市场上正式过招，你就输在了起跑线上。
Facebook的招聘原则是`Hire slow, fire fast`。招聘标准很高，只和最一流的人合作，一流人才无法容忍二流人才，对于平庸的人才从不妥协。对一流人才来说，仅仅“足够好”是不够的，他们能尽其所知，用其所长，学其所不能，从而迅速完成目标并远超期望。这里并不是说没有包容心，而是说希望每个人都是为自己树立高标准、喜欢互相学习、互相挑战、能够完成艰巨任务的人。Facebook财大气粗，是可以提出较高的要求，如果是创业小公司，可能就没办法这样，因为往往也招不起高端人才，对招来的人扬长避短才是更实际的办法。
炒鱿鱼要快，任用二流人才就像服用慢性毒药。如果一个人确实是能力问题，需要迅速炒掉，否则会对团队造成极大的负面影响，他们造成的损失会多过给公司带来的正面影响。这一点我也深有体会，有时候一个庸才带来的损失，十个天才也弥补不了。
Facebook收购了30多家创业公司，主要原因就是觊觎他们的人才，而不是产品。

##新兵训练营
所有新入职的工程师会参加称为Bootcamp的培训，学习代码库、工具和方法，最好在第一天就能提交代码。新人在进来之后并不会立即安排工作岗位，他们会随着融入Facebook的过程，找到适合自身能力和兴趣的小组。一般新员工有更大的主动权来选择，选定的组不能拒绝他。如果是认为他不行，那不如解雇他；如果不愿意让他来你的组但可以到其他组，这种想法违背Facebook文化，“我们都是为Facebook工作的，而不是为了某个小组工作”。
每个人会有一位导师，导师允许占用1/4的工作时间，负责解答新人的各种问题，从工作、生活到八卦。传递规章制度，比如休假、福利等等一些实用而琐碎的信息。第一次打开电脑后会收到6封电子邮件，1封是欢迎信，另外5封是介绍他们将要执行的任务，一般是简单的bugfix，目的是熟悉开发流程。
培训当中的课程会介绍公司的整体情况，让新人有全局认识，然后会介绍重要产品、技术框架和技术工具，最后会介绍非产品和技术的其他部门。

##技术管理
###迅速发布，再进行监测
Move fast and monitor closely. Facebook使用灰度发布方式，发布之后监控这个产品的几个最重要指标，从运营数据来看这个产品有没有达到预期。这一点上，我们还有很多路要走，我们的监控应该看到更加专业的运营数据，细到针对特性的指标。
###工具文化
最优秀的人才不是在最赚钱的产品部门，而是放在工具开发那一块，因为工具做好了，可以事半功倍，所有人的效率都可以提高。Facebook常见的工具：
* 给新工程师分配开发机器的管理系统，一键申请，自动初始化。
* 代码库管理用[git](http://git-scm.com/)，集成一些hook，包括提交前自动检测是否符合代码规范，自动检测是否有覆盖的测试用例。
* [Phabricator](http://phabricator.org/)，已经开源的code review工具。只有通过code review的代码，才允许提交到服务器端的代码库中。
* 发布工具。灰度发布，可以选择用户特点（比如对年龄、性别、地域、受教育程度等方面的限制）。Bit Torrent算法实现分布式快速更新，几十万台机器发布只需要几十分钟。
* 监控工具。数据收集只需要1〜2行代码，整理、分类、存储都在后台自动完成，可视化报表可以即时生成。
* 告警工具。数据波动自动告警，发邮件、发短信，设定既定应急方案去解决。，如果不行，全球24小时轮班的站点稳定工程部门会打电话给你。
* 最重要的目标、任务、目标日期、负责人写在白板上，挂在离我们最近的墙上。
* 客服工具。用户提交的问题会被引导到网站帮助，解决不了的会被自动分配到相关的运营组处理。工具产生常见的通用解决方案，例如一键退款，回信内容自动产生（用户姓名、问题原文等个体信息会自动嵌入），可以选择是否修改内容。如果针对某一个功能问题突然增多，会自动提醒运维人员手动查看，然后决定是否需要工程师介入修复。所有用户问题的统计信息会被自动统计，以保证客服质量。
* 招聘工具。做题系统、题库管理、自动打分、面试评价、权限控制。
* 业绩评价工具[Work.com](http://work.com/blog/category/rypple/)。以前叫做Rypple。
所有不断重复的好习惯，Facebook都会将其自动化，做成工具。如果有开源的工具，就用开源的，可以改造后再回馈代码给开源社区；如果没有开源的，那么符合需求的商业工具，Facebook乐意购买，并不是所有工具都要自己开发，因为不希望重复制造轮子。

###一对一碰头会
这个有点像腾讯的PDI。上下级之间的碰头会，主要涉及的是个人发展和工作事宜，在半个小时或一小时里，只关心对他们重要的问题。一类是工作上的具体问题，第二类是个人发展上的问题，第三类是公司发生的一些事情的沟通。会议的主导方是他们，我们可以聊任何他们感兴趣或对他们有帮助的话题。他们需要准备好要讨论的问题，以及对上一次碰头会的后续跟踪（Follow-up）。每次讨论结束，会制定行动项目，避免空谈。下属会在当天电邮一个简短的会议记录，主要就是书面写下行动项目，方便下一次对照。每天讨论，我们会关注在以下几个方面：
1. 工作开不开心(Happiness)？
2. 效率高不高(Productivity)？
3. 工作的影响大不大(Impact)？
4. 有没有学习成长的机会(Growth Opportunity)？
总结起来，叫做Happy PIG（快乐小猪）理论。

##成熟的流程与制度
在本书的后半段，都在介绍Facebook的一些产品研发流程，以及考核激励体系。这些方法在大公司都差不多，跟腾讯的几乎完全一样，没有什么特别值得一说的。

##总结
看来国内外的公司在流程制度上都差不多，主要的差别还是在前面所说的部分，核心就是工程师的素养，我认为这是中国工程师普遍需要提高的部分。Facebook的很多理念和思想，是值得很多公司学习的，但是映射到自己的场景里，是否同样适用，就需要自己根据实际情况去思考了。

本书（第三版）勘误~

2010-12-07

一、硬伤
P101L4 ~ L6的内容为:
"没有为处于TASK_STOPPED、、EXIT_ZOMBIE或EXIT_DEAD状态的进程建立专
门的链表。由于对处于暂停、僵死、死亡状态进程的访问比较简单，或者通过PID，
或者通过特定父进程的子进程链表，所以不必对这三种状态进程分组。"

L7 ~ L9的内容为：
"没有为处于、状态的进程建立专门的链表。由于对处于暂停、僵死、死亡状态进程
的访问比较简单，或者通过PID，或者通过特定父进程的子进程链表，所以不必对
这三种状态进程分组。"

对应的英文原文为:
Processes in a TASK_STOPPED, EXIT_ZOMBIE, or EXIT_DEAD state are not linked in specific lists. There is no need to group processes in any of these three states, because stopped, zombie, and dead processes are accessed only via PID or via linked lists of the child processes for a particular parent.

Processes in a TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE state are subdivided into many classes, each of which corresponds to a specific event. In this case, the process state does not provide enough information to retrieve the process quickly, so it is necessary to introduce additional lists of processes. These are called wait queues and are discussed next.
翻译：TASK_可中断或 TASL_不可中断状态的进程被细分为很多种类，每一种都只响应某一特定事件。这种情况下，进程状态无法提供足够的信息以快速解析进程，所以需要引入附加的链表。它们被成为等待队列并且接下来讨论。

二、错别字
P46L-3 "80x86微处理器中的分段鼓励程序员把他们的程序化分乘逻辑上相关的实体，例如子程"
此处"化分"应该为"划分"。

P49L-9 "与高级电源管理(AMP)..."
P49L-5 "像前述与AMP相关的3个段的情况一样,..."
AMP应该为APM

P61L-7 "(Page Cache Disablt)标志指明当访问包含在这个页框中的数据时,"
"Disablt"应该为"Disabled"。

P71L-12 "...例如，IBM Thinkpnd把"
很明显的应该是"Thinkpad"。

三、有些地方有尾巴
p598L11 "spinlock_t tree_lock Spin lock 保护基树的自旋锁"
此处的"Spin lock"系多余的。

四、半角全角不分

只是大致的翻一翻，希望仔细看过这本书的再挑更多的错误。有了第一个硬伤，充分说明这些翻译们的辛劳和严谨。真的太有才了，在译者序的最后有"......为第二版和第三版之间的差异做了大量校对工作，同时还参与部分翻译工作。全书由陈莉君审校并统稿。"不知道陈老师是否真的统过稿，值得怀疑。

等多请看原文：http://www.chinaunix.net/jh/4/914783.html
英文版官方勘误：http://www.oreilly.com/catalog/understandlk/errata/