facebook是如何管理代码的

转贴自http://blog.leezhong.com/translate/2011/01/18/how-facebook-ships-code.html

原文在此,看完之后,终于明白为什么优秀的工程师都去了/想去facebook,因为那里是工程师们的天堂。

译文:

我对facebook的运转着迷。这是一个很独特的环境,不容易被复制(他们的体系并不适合所有的公司,即使他们努力尝试过)。下面是我和facebook的朋友们关于他们如何开发和管理项目的记录。

现在距离我收集的这些信息又过去6个月了,我相信facebook肯定又对他们的项目开发实践进行了改进。所以这些记录可能会有点过时。同时facebook的工程师驱动文化也越来越为大众所知。非常感谢那些帮助我整理这篇文章的facebook的朋友们。

记录:

  • 截止到2010年6月,facebook有将近2000名员工,10个月前只有1100名,一年之间差不多翻了一番。
  • 两个最大的部门是工程师和运维,每个部门大概都是400-500人。这两个部门人数大约占了公司的一半。
  • 产品经理与工程师的比例大约为1-7到1-10。
  • 每个工程师入职时,都要接收4-6周的培训,通过修补bugs和听高级开发工程师的课程来熟悉facebook。
  • 培训结束后,每个工程师都可以接触线上的数据库(更大的权力意味着更大的责任,也有一份”勿做清单”,不然可能会被开,比如共享用户的隐私数据)。
  • 有非常牢靠的安全体系,以免有人不小心/故意做了些不好的事。
  • 每个工程师可以修改facebook的任何代码,随时可以迁入。
  • 浓厚的工程师驱动文化。”产品经理基本可以被忽略”,这是facebook一名员工的话。工程师可以修改流程的细节,重新安排工作任务,随时植入自己的想法。
  • 在每月的跨部门会议上,由工程师来汇报工作进度,市场部和产品经理会出席会议,也可以做些简短的发言,但如果说得太多,很可能就会被打小报告。他们确实想让工程师来主导产品的开发,对自己的产品负责。
  • 项目需要的资源都是自愿的
    • 一个产品经理把工程师们召集到一起,让他们对他的想法产生兴趣。
    • 工程师们决定开发那些让他们感兴趣的特性。
    • 工程师跟他们的经理说:”我下周想开发这5个新特性”。
    • 经理会让工程师独立开发,可能有时会让他优先完成一些特性。
    • 工程师独立完成所有的特性——前端/后端/数据库,等等所有相关的部分。如果需要得到设计人员的帮助,需要先让设计人员对你的想法产生兴趣。其他如架构之类的也一样。但总体来说,工程师要独立完成所有的任务。
  • 对于某个特性是否值得开发的争论,通常是这么解决的:花一个星期的时间完成他,并在小部分人群中(如1%)进行测试。
  • 工程师常常希望解决难题,这能获得声望和尊敬。他们很难对前端项目或UI设计产生太大的兴趣。这跟其他公司可能正好相反。在facebook,后端任务,比如新的feed算法,广告投放算法,memcache优化等等,是工程师真正感兴趣的。
  • 所有的代码修改都要进行审核(通过一个或多个工程师),但News Feed是个例外,因为太重要了,Zuckerberg会亲自review。
  • 所有的修改至少要被一个人审核,而且这个系统可以让任何人很方便地审核其他人的代码,即使你没有邀请他
  • 工程师负责测试,代码修复,和维护自己的项目。
  • 每个办公室或通过VPN连接的员工会使用下一版的facebook,这个版本的facebook会经常更新,通常比公开的早1-12小时。所有的员工被强烈建议提交bugs,而且通常会很快被修复。
  • 很奇怪只有很少的QA或自动测试——”大部分工程师都能写出基本没有bug的代码,只是在其他公司他们不需要这么做。如果有QA部门,他们只要把代码写完,扔给他们就行了”
  • [针对上一条]我们有自动测试,代码发布前必须要通过测试。我们不相信”所有的工程师都能写出没有bug的代码”,毕竟这是一个商业公司。
  • 很奇怪,缺少产品经理的影响和控制——产品经理是很独立的和自由的。产生影响力的关键是与工程师和工程师的领导们们搞好关系。需要大致了解技术,不要提一些愚蠢的想法。
  • 所有提交的代码每周二打包一次。
  • 只要多一分努力,终于一天会发生改变。
  • 星期二的代码发布,需要所有的提交过代码的工程师在场。
  • 代码打包前,工程师必须在一个特殊的IRC channel上。
  • 运维执行打包过程
    • facebook有大约60000台服务器
    • 有9个代码发布级别
    • 最小的级别只有6台服务器
    • 星期二的代码发布会先发布到6台服务器上,运维组会检测这6台服务器的反应,保证代码正常工作,然后再提交到下一级
    • 如果发布出现了一些问题(如报错等等),那么就停止下一级的部署,提交出错代码的工程师负责修复问题,然后从头继续发布。
    • 所以一次发布可能会经历几次重复:1-2-3-fix. 回到1. 1-2-3-4-5-fix. 回到1. 1-2-3-4-5-6-7-8-9
  • 运维组是受过严格训练,倍受尊敬,而且有商业意识的。他们的工作包括分析错误日志,负载和内存状态等等。还包括用户行为。
  • 代码发布期间,运维组使用IRC-based页面系统,可以通过facebook/email/irc/im/sms ping每一个工程师,如果需要他们注意的话。对运维组不做回应是一件很羞愧的事。
  • 代码一旦发布到第9级,并且稳定运行,就算发布成功了。
  • 如果一个特性没有按时完成,也没什么大不了的,下次完成时一并发布即可。
  • 如果被svn-blamed,public shamed或工作经常疏忽就很可能被开除。”这是一个高效的文化”。不够高效或者不够聪明的员工会被剔除。管理层会在6个月的时间里观察你表现,如果不合格,只能说再见。每一级都是这个待遇,即使是C级别和VP级别,如果不够高效,也会被开除。
  • 被责骂不会导致解雇。我们特别尊重别人,原谅别人。大部分高级工程师都或多或少犯过一些严重的错误,包括我。但没有人因此被解雇。
  • 我也没有遇到过因为上面提到过的犯错误而被解雇。有些人犯了错,他们会非常努力地去修复,也让其他人得到了学习。
0 Comments

越冷越懒

气温不断的下降,杭州已经下过一场大雪,那天一路的薄冰,让多少人迟到。

人也越冷越懒,懒得写博客。

期间。

我搬了家,一年了,在杭州。从当年刚来杭州租住在一个老得不能再老的居民区,到这次搬到了一个还有点样子的小社区,总算这一年还是有点收获的。

体检报告出来了。少吃,多运动。工作这些时间,吃地沟油太多了。

过了冬至,吃了汤圆。

计划有,但是执行基本没有,不知道这种状态还要持续多久,习惯一旦养成就很难改了。所以,趁早。

接着,准备过圣诞。

1 Comment

淘宝的职业发展图

给技术人员和管理人员的参考。

淘宝职业发展

1 Comment

中秋

很久没写东西了,工作看上去没有上半年那么繁忙,不用每天到十一二点,但是事情依旧很多都交织在一起。

计划的旅游一次次被搁置,终于有一天告诉自己不能在延后了,把leve设成H,希望能实现-_-

工作整一年,感觉时间过得很快,晚上做个梦,想起以前的生活,小学初中高中,想起的都是在舟山的日子,那个小小的岛屿,我成长的地方。大学四年,虽过得看似精彩,却也没有多少感触,认识了一帮兄弟一起打打闹闹,也认识了一群伙伴一起努力奋斗,这些就是最大的财富。

在杭州的工作,也平平淡淡,对这座城市,没有太多的感情,除了西湖边的一片片幽林小径确能让人忘记繁琐杂事,剩下的,就是忙忙碌碌纷纷扰扰。蜗居在城北的出租房,过着一天又一天,能够在这样的一个下午,听着歌上着网,已是难得。

0 Comments

字符终端与图形界面的困惑

现在许多银行的综合业务系统(柜面)经历着从字符终端向图形界面的蜕变,特别是中小商业银行,在IT转型上更为快速。

然后,习惯了字符终端,在开发图形界面时或多或少留下的字符终端的影子。确实,改变是困难的,但照搬字符终端的开发是得不偿失的。

将字符终端照搬到图形界面上,失去了字符终端快速的特点,也没有体现图形界面信息量的优势。

现在的字符终端模式,输入交易码进行交易,更像是面向过程的,一个交易码就针对了一个柜面交易,看不出交易间有什么关联性,做业务纯粹只是为了做业务,仅此而已。

图1:中心主题是交易码。

为什么不能在图形界面上进行变革?

让业务更具备面向对象的特性,不再以冷冰冰无意义的交易码作为中心主题了。客户来做一笔存款,先刷卡,输入密码,界面上可以分割成几个区域进行显示,显示操作区,客户信息区,客户历史交易流水,牺牲了速度但增加了信息量。但是速度怎么办呢?我只想要存款,矛盾就在这里了。

图2:中心主题是客户。

谁有好的解决方案呢?

1 Comment

PDF字体混乱

很久没写博客了,虽然最近系统上线还算稳定,也不用像前几个月一样加班到半夜三更,但每一天还是过得比较繁忙,可能因为学习的东西比开发时更加多了吧。趁着这段时间开发任务不重,多学点其他东西了。

我也是在这次开发中接触到PDF的,因为采用了服务器PDF打印的方式,所以对PDF势必需要一些了解。起初我对PDF并没有太大的关注,觉得只是一种文件格式而已,用了activePDF生成PDF,丢到客户端一打印就完事了,但事实并没有那么简单。

首先activePDF对中文的支持就让我头疼了很久,对PDF文件格式的不了解,让我只能一个个去摸索一个个去测试,对于字符编码更是一头雾水。搞定这个以后,又出现了始料不及的事情,用户机上打印出来的字体和我们开发测试机上的完全不同,甚至说有点随机,难道PDF还依赖本地字库?

结果在网上查了很多资料,终于看到了内嵌字库这个东西,而且发现中文字体并不会自动内嵌到PDF中,而西文字体则可以,然后不同客户机安装了不同的字体,PDF找不到所要的字体就会使用最相近的一种,就出现了客户机字体各异的问题。

解决的方法就是把中文字体内嵌到PDF中,我用的方法是打印到文件,在acrobat中打印到文件,选择下载亚洲字体,就能把中文字体嵌入到PDF中,做到与客户机无关了。这样做的缺点就是PDF中的一些信息会丢失,比如表单域的信息,书签等等,所以我是先做好模板嵌入字体,然后在这个基础上加上表单域供activePDF调用。

PDF也是一滩很深的水哦,以前太小看它了-_-

0 Comments

世界为了杯

很久没更新博客了,不是没时间,只是比较懒。事情其实很多,系统上线了,不断的调整修改。

端午去了苏州,结果发现越是推荐的景点越是离谱,苏州城的环境还不错,比舟山繁华,比杭州怡静,古老的房子和园林营造了不错的氛围。苏州乐园这个地方,和宁波的凤凰山差距不是一点点的。

接着周末单位去开了卡丁车,还算好玩,就是贵了点。

然后又和小S去了余姚,会熊哥,狗贼和宁波,本想去摘杨梅,结果到了三七镇被告知杨梅还没熟,不过无所谓,用熊哥的话说,大学同学聚会罢了,只可惜了S经理的油费和过路费。

接着就是世界杯,买几注彩票,在电脑前,回味着小时候看世界杯的感觉,可惜,不再。

0 Comments

喘气

近半年来,终于有了双休日。系统上线到凌晨两点,稀里糊涂就这样过去了。接下来的,是更黑暗的时刻,黎明,还很遥远。

中午休息的时候会去边上的舟山东路逛逛,城院,树大,让我想起了一年前的我,毕业一年了,在这里一年了,工作一年了。终于明白了,大家并不是怀念那个地点,而是回味那段时间,从我的18岁到22岁。

端午想出去旅游,也许是厦门,也许是成都,也许哪里也去不成。

0 Comments

富士康的楼

话说要出了人命才知道问题的严重,富士康告诉我们,死不能解决任何问题。因此,该干嘛干嘛去吧,别以为挂了就能有好日子了。

0 Comments

冒泡

继续每天的加班,最初,大家认为7点下班是一种幸福,现在,大家觉得11点能回到家是一种梦想。

我依旧需要冷静,纵然加班到焦头烂额,也应该明白自己在做什么,越乱,越刺激。

突然发现许多小小的梦想都被别人实现了,比如Square,就是一个很好玩的小东西,随身刷卡,还真有这东西了。

洗洗睡了,难得能在2点前睡觉:)

0 Comments