认识达内从这里开始

代码库
青岛达内专业培训
大部分的 Google 代码都存在统一的源代码库中，可供 Google 内部所有工程师访问。但是 Chrome 和 Android 则分别有单独的代码库。

Google 的代码库，在 2015 年 1 月的统计中，共计 86T 数据，上10亿个文件，9百万个源代码文件，其中包含了 20 亿行代码。迄今为止共计 3500 万次提交，每个工作日平均发生 4 万次更新。

任何 Google 员工，都可以随意的访问所有代码，并下载、编译，可以在自己的环境下自行改写，但任何更改的提交，都需要通过代码负责人的审批才可以。

所有的开发都在库的头部进行。对代码进行任何更改后，自动化系统将进行测试，并在几分钟内通知开发者和代码审查者，对更改的测试是否失败。

代码库中每个分支都有单独的文件注明“代码所有人”，只有代码所有人才有权利审核提交的更改。通常情况下，项目组的所有成员都是“代码所有人”。

编译系统

Google 使用分布式编译系统，叫做 Blaze。Blaze 提供了标准的命令，用于编译和测试库中的所有代码。Blaze 这种统一的编译工具，让 Google 公司的所有工程师都能随时编译和测试任何软件，也都能跨项目工作。

程序员需要撰写“BUILD”文件，用来引导 Blaze 如何编译软件。在Go语言的代码中，build 文件可以自动生成。

每个编译步骤必须是“隔离”的，只依赖于声明的输入。为了实现编译的分布式运行，必须强制要求正确输入所有的依赖：只有声明了的输入才被发送到进行编译的机器上去。

每个编译步骤的结果是确定的。这样保证了编译系统可以缓存编译结果。软件工程师可以回退到老的版本号，并重新编译，且得到完全一样的二进制结果。

编译结果缓存在云端。包括中间结果，这样当有别的编译请求过来，系统直接应用缓存的结果。

增量的重新编译非常快。编译系统运行在内存中，当重新执行编译任务时，它能够分析文件上次编译后发生的增量变化。

提交前检查。Google 有专门的自动化工具，用来在发起代码审查和准备提交更改到代码库时，进行一整套的标准检查。
代码审查

Google 开发了基于 Web 的代码审查管理工具。程序员可以申请对代码进行审查，审查者可以在浏览器上比较差异，并写上评语。当写代码的人发起一次审查申请，则系统自动发邮件给审查者，并附上代码查看页的链接。

对源代码的任何更改，必须经过最少一次审查。如果更改不是由“代码所有人”做出，则还必须由所有人中的一位进行审查。

系统可以自动推荐合适的审查者。当然，写程序的人，可以自己选择审查者。

Google 鼓励工程师们，将每一次代码更改控制在较小的规模上。 30-99 行的代码更改，通常视为“中等”；300 行以上则标记为“大”； 1000-1999 行，则是“巨大”；

测试

单元测试是必须的，在 Google 的开发中广为采用。集成测试和回归测试，也较为普及。Google 有一个自动化的工具，用来衡量测试覆盖的范围，这个结果也在代码浏览器中可以查看。

部署前一定要做压力测试。项目组要用表格或者图标显示关键参数，尤其是压力之下的延迟和错误率。

Bug 跟踪

Google 使用的 Bug 跟踪工具叫 Buganizer。有的团队，安排专人分配 Bug，有的团队则在例行的会议中分配。

开发语言

Google 内部有四大语言，一般都建议工程师在这四种里挑选。四大语言是：  C++，Java， Python， Go。不用多说，减少语言数量，可以增加代码复用，并提高内部协作。

每种语言都有代码规范，保证风格统一。公司范围内，还有针对“代码可读性”的培训，由经验丰富的老司机，对新人进行培训。代码审查，也需要对“可读性”做专门的评审。

在不同语言之间的交互操作，要通过Protocol Buffers 来处理。Protocol Buffers 是 Google公司开发的一种数据描述语言，类似于XML能够将结构化数据序列化，可用于数据存储、通信协议等方面

调试工具和性能分析工具

Google 的服务器连接了很多库，提供用于调试服务器的工具。服务器崩溃时，可以自动导出堆栈轨迹到日志文件。 还有 Web 界面用于调试，可以用来查看呼入和呼出的 RPC 调用、更改的命令行标志值、资源消耗、性能分析等。
发版

Google 的大部分项目组，都有固定的软件工程师负责发版。

大部分的软件，发版比较频繁。通常是周发版，或者每两周发版，有些项目组甚至每天发。所以，自动化进行发版就是必须的了。频繁发版有助于工程师们保持斗志，提高整体速度，实现更多的迭代，从而也可以获得更多的反馈，并做出更多有益的更正。

上线

要上线任何更改，并对用户可用，则需要项目组外很多人的审批。审批来自多个方面，包括法律合规、隐私保护、安全要求、可靠性、业务需求等等。

Google 有一个内部的上线审批工具，用来执行审查和上线审批。通过定制，这个工具，对不同的产品有不同的审查和审批流程。

过错总结

发生了重大的服务事故后，相关人员要起草过错总结报告。文档描述事故细节，包括标题、概要、影响、时间段、原因、故障组件、行动。 总结的聚焦在于问题，以及未来如何解决，而不是聚焦在于人，也不是为了惩罚责任人。
频繁的重写代码

Google 鼓励频繁的重写代码，任何软件每隔几年就重写一遍。一来可以优化产品，采用技术，去掉无用的功能，另外还可以转移知识到新员工，并保持员工的斗志。

20%的自由时间

尽人皆知，google的工程师拥有 20%的自由时间，可以随意做感兴趣的东西，而无需审批。这当然是为了激发工程师的各种创意，同时也让工程师们保持高效率，而不是窒息在必须完成的任务中。 另外，也考虑到，很多员工都会私下里自己做一些东西，那么还不如鼓励大家将这些研究方向公开。