游客

标题: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%
[<<][[1]][2][3][>>]

查看评论(0)
发表评论



首页