内部工作流程
以下是打听到的某个产品项目开发流程：
PM 或工程师提出某个想法，UX 做原型 mock PM 申请项目审核（通过率不高）、工程师开发 UX 无关部分 工程师完成开发 线上小流量实验 PM/工程师分析实验结果，完成报告，申请全量上线（通过率不高） 通过数据来证明这个功能是有价值的 需要解释这些数据的变化原因
分批逐步上线，这个过程中还会有很多审核 最终确定是否要上线（通过率不高）
一般整个项目周期很长（至少一季度），项目最终上线时间点无法确定，大部分的项目最终都无法正式上线。
最大的特点是完全靠数据说话，而不是由某个 PM 决定一切，以前有个视觉设计师在离开 G 后就在博客上吐槽这点，他认为这会导致无法进行大胆的界面改版。
这个流程和我们搜索产品几年前的开发流程很类似，对于成熟的搜索引擎来说这么做确实有它的道理，毕竟随便改个什么都很可能影响收入，当然要十分谨慎了，但这种开发方式并不适合面向用户类的产品，如社区、游戏等，因为开发周期太长了，很容易错过时机。
某人一天的工作
这里拿 Matt Welsh 来举例介绍一个工程师在某 G 一天的工作，虽然他不是做前端开发的，但他目前在 Chrome 团队负责移动 Web 性能优化，所以还是比较相关，而且最重要的是他比较喜欢写博客，有意无意地透露了很多信息，所以我比较好公开谈。
另外话说他之前还是哈佛的计算机终身教授（！！！），八卦很多，比如差点说服小扎同学不要搞什么社交网络了，还是好好学习拿毕业证书。。。
这这篇文章里，Matt Welsh 介绍他的一天是如何度过的（另外还提到了在哈佛当教授是如何度过的，也很有意思），我摘抄如下：
9:00，到公司，查邮件 9:30-10:15，写代码，增加功能，编写单元测试，发起 changelist 代码 review，喝无糖可乐 10:15-11:00，切换 git 分支到其它项目，查看同事 review 代码的结果，回复评论并发新版本 changelist 10:00-11:30，再次切换 git 分支，提交一个要运行 3 小时的 MapReduce 任务分析网络延迟日志 11:30-12:00，和山景城的团队成员开视频会议 12:00-12:35，午餐 12:35-14:00，检查邮件，检查 MapReduce 任务运行状态，回复代码 review 的评论，再次提交代码，然后查看任务列表确定接下来的工作 14:00-15:00，和在剑桥（有评论指出这里是波士顿的剑桥，不是英国那个）、山景城等多个地区的团队成员开项目会议 15:00-16:00，喝红牛，这时 MapReduce 任务已经跑完了，生成图表，分析数据中不符合预期的部分，整理代码，准备下一次 MapReduce 16:00-17:00，喝苏格兰威士忌(scotch)并玩吉他英雄(Guitar Hero) 17:00，收拾笔记本回家
看完后我的几点体会是：
前面提到的代码只有 trunk 并不准确，当然每个部门确实可能不一样 代码 review 做得很认真 看起来任务很明确，所以虽然工作时间是 9-5，但效率挺高，这点我最为好奇的，怎么做到将工作安排这么具体？ 除了写代码，分析数据也是每天的重要工作，具体分析什么可以通过他的论文了解，看得出来是很细致的
内部工具
2008 年前的内部工具情况可以通过这篇文章和这个 PPT 了解，不过之后就不清楚了，看起来很多外部工具都有内部版本(Docs、Mail、Talk、Calendar 等）。
这里说一下 Chromium 项目中我看到的工具使用情况：
网站是基于 Sites 搭建的 设计文档喜欢使用 Docs，因为可以在线编辑和评论功能，所以多人协作会很方便 https://codereview.chromium.org/ 在 Groups 中进行讨论 使用 code 来管理 issues Buildbots 来进行编译和集成测试 搭建了各种检测工具来保证质量，具体细节推荐读这本书，看完这本书我最大的体会是没什么神奇的东西，完全靠细心的工作
可用的石头
以下是我认为可以借鉴的地方：
源码不分版本，对内部所有人公开 严格的代码规范及单元测试机制 FEX 所有项目将接入 Travis CI 代码规范及单元测试的强制检查 代码 owner 的 review 机制
通过实际例子来使用，甚至不用看文档 文档及相关资料和代码放一起 这能保证找起来很方便 如果由于种种原因不能放一起，至少也要放链接
外部产品有内网版，比如 Docs GWT 的静态检查机制
原文出处： 百度FEX（@吴多益 | 
