话说本人从毕业到现在一直在某B公司工作，前些年折腾过不少开发方式和工具，但总觉得或许有更好的方案，所以很好奇其它公司内部是如何工作的，我曾经浏览过某Y公司内部无所不包的TWiki，也拜访过某F总部了解他们的开发流程，但对某G公司却了解不多，只零零碎碎知道一些，这两天抽空梳理了之前收集到的各种资料，希望能给FEX后续改进提供参考。
注意：以下内容主要信息来自网上收集、『InThePlex』这本书及闲聊，纯粹为了技术交流和讨论，仅代表个人观点，本人从未在某G工作过，不受NDA限制，但大部分信息无法确认真伪，加上某G很大，每个部门都有可能不一样，所以这里的信息也是比较片面的，欢迎大家提供更多参考信息。
分工协作首先，某G大部分产品线都不区分前端工程师和后端工程师，一个人需要用从前到后都负责开发，尽管这几年似乎有变化，能看到专门的FrontEnd职位了，但应该是很少数产品线的做法。
N年前有人去G面试过，和他闲聊后了解到某G要求应聘者必须至少要会C++和Java中的一种，只会Python/PHP是不够的，要是只懂JS就更不行了。这个信息很关键，能用来解释一些内部现象，后面我会提到。
我个人认为前端工程师确实应该了解基本的后端知识，某B公司以前很多前端工程师都只负责模板（比如Smarty）开发，这导致一个很严重的问题，那就是前端工程师往往不知道如何搭建环境，开发时需要依赖后端工程师提供环境和数据，严重影响了开发效率，这也是为什么FIS还内嵌了本地服务功能。
另外国内有公司还对前端工程师做进一步细分，按照职能分为写HTML/CSS和JS的，对于我所属的团队，我个人并不赞同这种做法，因为HTML和JS是密切相关的，这样分工将不利于代码管理与优化，尤其是交互复杂的页面，因为JS很依赖HTML，拆分反而增加沟通成本，但或许在重运营的网站这么做会更好。
代码管理方法以下是一些零碎了解到的几点：
内部所有人都能看到代码
据说在09年时某国家的office有例外（来自『InThePlex』第6章，内容比较不和谐，这里就不展开了）
提交代码需要相关人员的review
这使得某G内部工程师可以很方便地切换项目，很少一个人只负责一个项目
代码只有最新版(trunk)，没有release版本，没有版本号
一般大家喜欢新增接口
如果要修改原有的接口，就必须通知所有使用方，不过因为所有人都能看到所有代码，所以很容易找到有谁使用
据了解某F也是这样的
有个代码的搜索引擎
我认为这种方式比让工程师写文档靠谱多了，因为绝大部分调用这个库的代码都是相似的，所以直接给出例子能让别人更容易上手
估计和下线的CodeSearch比较像（好像还是某高管写的，不过我忘记在哪看到的了）
如果想使用某个基础库，最好的方法是搜索使用到这个库的相关代码，抄过来
代码依赖是通过全局的方式统一管理的
我猜应该很类似Chromium中的GYP，熟悉node的同学可以理解为npm，不过是支持多语言的
之前在某G工作过的iOS工程师也在某篇后来删除的文章中透露代码中不放Xcode项目文件，而是由工具生成出来（话说这篇文章挺有价值的，可惜老外不喜欢转帖，导致现在找不到了）
这种依赖管理方式让人想起某A公司（卖书那个，不是卖水果的）内部完善的SOA机制，不过某A喜欢基于service来重用，而某G看起来喜欢代码级别的重用
很少使用第三方库
只能选用内部维护的版本，比如类似这个MySQL
会将第三方库的编译工具改成内部的，比如Chromium中都改成GYP方便管理
据说想申请用某个新第三方库需要审核，周期比较长
代码管理软件用的Perforce
这个程序用了17年，有千万次changelist（可以理解就是ci数量）
最大的client有6百万个文件（应该绝大部分是数据吧，要知道chromium项目也就不到0万个文件）
文档及相关数据文件也放上面
Reivew工具叫Mondrian（确认就是Rietveld的前身）
某G直接将这个公司买下了（未确认，但下面那篇论文是在某G网站上的，所以我感觉消息可靠），Perforce的员工为某G内部定制了一套代码管理工具
另外我找到一篇Perforce的性能优化的论文，这里面透露了很多G公司内部的代码情况（发表时间是年5月），以下信息取自这篇论文：
整体来说某G的代码管理方式有很多可取之处，尤其是代码开放，能最大程度地调动开发人员的主动性与协作意识，从而创造出更大的价值。不过没有版本管理这点是个双刃剑，我也没想好是否这样会更好。
featureflag因为没有分支，代码只有一份，所以要实验新功能就得通过flag来控制的，这个flag由线上Borg系统来管理，能做到针对某一部分的Cookie开启不同的feature，方便进行对比抽样。
如果某个功能最终不上线，后续需要手工删除相关代码。
这个flag开关功能在某F也有，我认为这是大型网站是必备功能，但需要注意，这个系统本身会成为关键节点，之前某F的类似系统挂过，直接导致整个网站大部分功能都关闭了，所以一旦出问题后果很严重。
严格的代码检查据说某G工程师大部分时间在写单元测试，单元测试可以保证UI无关代码的质量，但对于页面测试就很难了，虽然可以使用selenium，但某G内部大家都不愿意写，我个人认为这个问题确实无解，页面随便一改就导致大量测试失效，我还没见任何一家公司解决（某F说他们用的是Watir，但主要用于保证登录等基本功能可用），目前看来唯一可行的就是自动页面截图diff，某G在ConsumerSurveys这个产品中也在尝试。
据说某G的项目大多没有严格的上线时间点，所以不能以项目紧急为借口来不写单元测试，这点和天朝不太一样，大家更倾向牺牲质量来追求速度。
另外国外公司一般对浏览器兼容性问题都不怎么