6
| 本文作者：峰瑞资本 | 2015-11-24 15:30 |
【编者按】本文来自FreeS 组织的内部第一次创业公司 CTO 交流会，FreeS技术合伙人、前 Facebook 工程师覃超，以及神州专车 CTO、前 Facebook 工程师徐万鸿，向创业者讲述：
创业公司应该如何创造自己的工程师文化？以及 Facebook 的看家产品 News Feed 背后的原理。
创业者常常会说：“请帮我们找个CTO 吧。”确实，资深工程师不少，但合格的 CTO 却不多。作为 “C” 字头的技术人员，CTO 所关注的绝不仅仅是工程质量这么简单。内部运营的管理、HR 事务、整体架构都需要用到这位资深码农。而就算从硅谷挖来一位技术大牛，应该如何与之磨合，也是困扰国内创业团队的一个问题。
那么，Facebook在打造企业文化的时候都做了什么？创业公司可以从中学到什么？
Facebook 的 CTO 都在做些什么？
覃超：峰瑞资本技术合伙人，前 Facebook 工程师。
我在 2010-2014 年在 Facebook 工作，主要负责前端移动开发，从 Facebook Phone 到 iOS/Android Facebook App 和 Messager 等做过很多功能。同时我之前做过 PHP 后端的东西。
Facebook 第一特点就是重视技术兼设计。不像苹果纯设计而谷歌纯技术，Facebook 是各占 50%。公司整体装饰有意外多的艺术元素，而新的总部大楼更是由巨擘 Frank Gehry 设计的。
公司内部的彩虹样式装修，是美国高院宣布同性恋合法时加上的，也体现公司对于不同事物的包容和尊重。产品的活力和企业文化包容有很大的关系，所以我建议创业公司不妨都包容开放一点，比如放一个无人机或者 Oculus VR 的眼镜就很棒。
公司里还有很多 Poster，其实我觉得这 Branding 和企业的 “政治教育” 内容。这些海报并不是专门一个人做，公司每个人都做，且公司有一个房间是专门造这些东西的材料，只要你把你的设计交给他们，最后海报就会制作出来。
Facebook 另一个特点就是开放，没有严格的权限控制，例如 iOS 可以看到后端代码，PHP可以看安卓的代码。任何员工只要在公司的内网里，就可以随时打开数据展示的页面，然后看到公司的MAU（Monthly Active User-月活），DAU（Daily Active Users-日活）以及其他按照地区和功能切分的细节数据。这样可以节省工作的管理开支，每个人也不会觉得束手束脚。
另外我们的工作空间就是网吧式的结构。这样有两个特点，好交流也闹哄哄。最重要是有 Peer Pressure，比如你迟到或者打游戏，都会被别人看到。比起其他很多美国的好处是，在 Facebook 工作刷 News Feed 或者微博和知乎是不会被限制的。
公司另一特点是默认给予员工最大程度的信任（按照老美的话说：trust by default），这也是美国文化的特点之一。一进公司就默认对你信任和尊重。它的相对应面是绝对强的执法能力，如果你泄露公司机密，则立马把你开除。历史上出现过几次 Zuck 在 QA 的会议上说的公司机密被泄露的事件，那些泄密者最后基本都被开除。
一个公司最重要的是气氛的和谐。不仅是程序猿之间，还有和设计师、PM，他们也会参加一些讨论，且我们一定要坐在一起，这样类似 UI 上细节的问题，比如颜色、像素对齐等，都可以当面沟通。即使 Facebook 的远程会议系统和线上沟通工具都已经很健全了，但公司还是鼓励坐在一起工作。
Facebook 项目的人员配比：一个项目一般是两三个设计师、5-10个工程师 2-3 个产品经理。每个月一波推进（Scrum 里强调的 sprint），包括 2-3 个功能，按每个功能分一小组来做，但设计师可能会同时做多个设计。Facebook 的流程其实比较传统，但又夹杂很多敏捷开发的元素：一般是设计师先进行设计，然后工程师来开发，但整个过程中双方又经常有交互。整个产品研发过程中，所有人都互相尊重、互相合作，从一开始设计师、工程师、PM 都会在一起讨论，做出来之后还会坐在一起讨论，会马上给一些反馈，然后马上修改好。
工程师写代码的时候也会跟设计师一起交流，交流用的是 IRC 外加 Facebook Chat。但这些我觉得比较过时，比起微信来说，它们算难用的，甚至还没 QQ 好用。任务管理方面，Facebook有自己的Inhouse Task系统，可惜没有开源。类似的工具，现在Trello 、Tower、Teambition 或者 Jira 就很好用，可以用来做产品上的规划，开发进度管理和 bug tracking。
最后我们的 IC 、release、monitoring 这些全部都是内部工具，开发花了不少人力，对于创业公司不是特别适用。对持续集成来说，我觉得最经典的是 Jenkins，但是它的问题就是功能繁复、界面像 80 年代的软件。如果你们用 Github 的话，我也推荐 Travis CI 和 Drone。
在硅谷公司里，在开发流程上我觉得最重要的就是：Code Review。Facebook、Google、Uber 到现在的 Airbnb，无一不是强制要求 Code Review。Code review 过程中，不仅是可以互相检查对方的代码，还可以自动跑 lint 和unit test，对于代码质量的提高和去除没必要的bug非常有帮助。
这里重点推荐一下 Facebook 的 Phabricator。
它是个开源的代码审核和任务管理工具；它的其他功能也极其丰富；还可以搭在私有的服务器上，使其代码和数据不会被盗用。另外我们基金已经把它进行了汉化，变成中文的一个定制版本，并且扩展到其他功能上。比如对BP的审核工作：我们自建了机器人来监控我们 BP 邮箱的内容，然后对于每一个进来的 BP，自动在系统中建立 Deal Review Task；然后我们的BP审核人员和投资经理们跟进。
最后一点 Facebook 让我觉得印象深刻的，是它对于工程师技术能力的高要求和提供的一整套培训。另外就是在硅谷公司工作，要学会有效地描述表达一个观点，逼自己去学和反复复习。我觉得反复的一个过程很重要。反复的过程中，看似在做重复的事情，但是每次我都会意外地迸发出新的灵感。最后对于设计这一块，我们有一个特别强大的设计工具 Origami，可以很方便做交互设计，并且支持直接生成特效的代码。
以下来自徐万鸿：神州专车 CTO，前 Facebook 工程师。
新闻流（News Feed）是 Facebook 最重要的产品，有 10 亿用户，平均每个用户每天会收到他关注的朋友/主页所推送的 2000 个以上 stories。
实时发布，不漏掉重要的 story
从发出 story 到其他人接受 story 的时间在1秒之内，其中排序所花的时间在200毫秒之内。Data loss 要小于1E-6，实现这一点的关键在于系统架构。
把最好的内容放在前面
用户更倾向于与页面前面的内容互动，所以把更好的内容放在前面会带来用户在 Facebook 上更大的参与度。实现这一点的关键在于 Ranking 部分。
系统架构部分
Push model 和 Pull model 这两种模型都是可行的。
Push model 写入多次，读取一次。如果有 1W 粉丝，发布一条消息，会存储在每个粉丝那里，存储 1W 次。这个模型速度比较快，但是需要存储比较多。Pull model 写入一次，读取多次。发布的都写在一个库里，然后每个用户都来读这个数据。
Facebook 内部更倾向于 Pull model，因为 Pushmodel 需要太多的存储空间。
Ranking 部分
如何确定哪些是更好的 stories？我们需要给每一个 story 打分。我们赋予不同类型的行为不同的权重。比如 click, like, comment。这几种行为中，comment 需要更多的代价。click 的代价很小，而 comment 意味着用付出更多的时间来互动，所以我们会给 comment更高的权值。
对于每一个 story，我们需要预测这个 story 被推送给用户后点击、点赞、评论的概率。这里会用到机器学习（machine learning）的算法。先要实时地生成 features，然后要利用数据来 train models，最后 publish models，得到每个用户对每个 story 的每种行为的概率。
关于个性化的部分，采用的是通用的模型和个性化的信息。如果能针对每个用户做不同的 model，效果会更好。但是用户数目太多，这部分的工作量过大。
同时这也是一个实时反馈的系统。用户对每个 story 的行为会实时反馈到这个模型里面，重新训练模型，让效果越来越好。
雷峰网原创文章，未经授权禁止转载。详情见转载须知。
