工程师团队的交付物就是即将发布的代码。代码的组织形式、开发过程、维护是日常工作重点。谷歌多数代码存放在同一个代码库中，并使用统一的一套工具。这些工具和代码支撑着谷歌的构建和发布流程。谷歌所有的工程师无论是什么角色，对如何使用这些工具环境都非常地熟练，团队成员可以毫不费力地完成新代码的入库、提交、执行测试、创建版本等任务。
这种单一的代码库模式，使得工程师可以很从容地在不同项目之间转换而几乎不需要什么学习成本。公开的代码库、和谐的工程工具、公司范围内的资源共享，成就了丰富的谷歌内部共享代码库与公共服务。
那么，这是怎么做到的呢？谷歌的工程师形成了一套不成文但非常重要的实践规则，工程师在维护修改这些代码的时候都要遵守这些规则：
1、所有的工程师必须复用已经存在的公共库，除非在项目特定需求方面有很好的理由。
2、对于公共的共享代码，首先要考虑的是能否很容易地被找到，并具有良好的可读性。代码必须存储在代码库的共享区域，以便查找。由于共享代码会被不同的工程师使用，这些代码应该容易理解。所有的代码都要考虑到未来会被其他人阅读或修改。
3、公共代码必须尽可能地被复用且相对独立。如果一个工程师提供的服务被许多团队使用，这将为他带来很高的信誉。与功能的复杂性或设计的巧妙性相比，可复用性带来的价值更大。
4、所有依赖必须明确指出，不可被忽视。如果一个项目依赖一些公用共享代码，在项目工程师不知情的前提下，这些共享代码是不允许被修改的。
5、如果一个工程师对共享代码库在某些地方有更好的解决方案，他需要去重构已有的代码，并协助依赖在这个公共代码库之上的应用项目迁移到新的代码库上。这种乐善好施的社区工作是值得鼓励的。
6、谷歌非常重要代码审核，特别是公共通用模块的代码必须经过审核。开发人员必须通过相关语言的可读性审核。在开发人员拥有按照代码风格编写出干净代码的记录之后，委员会会授予这名开发人员一个“良好可读性”的证书。
7、在共享代码库里的代码，对测试有更高的要求。
谷歌在平台方面有特定的目标，就是保持简单且统一。开发工作机和生产环境的机器都保持统一的Linux发行版本；一套集中控制的通用核心库；一套统一的通用代码、构建和测试基础设施；每个核心语言只有一个编译器；与语言无关的通用打包规范；文化上对这些共享资源的维护表示尊重且有激励。
使用统一的运行平台和相同的代码库，持续不断地在构建系统中打包，可以简化共享代码的维护工作。构建系统要求使用统一的打包规范，这个打包规范与项目特定的编程语言无关，与团队是否使用C++、Python或Java也无关。大家使用同样的“构建文件”来打包生成二进制文件。
一个版本在构建的时候需要指定构建目标，这个构建目标由许多源文件编译链接产生。下面是整体流程：
1、针对某个服务，在一个或多个源代码文件中编写一类或一系列功能函数，并保证所有代码可以编译通过；
2、把这个新服务的构建目标设定为公共库；
3、通过调用这个库的方式编写一套单元测试用例，把外部重要依赖通过mock模拟实现。对于需要关注的代码路径，使用最常见的输入参数来验证；
4、为单元测试创建一个测试构建目标；
5、构建并运行测试目标，做适当的修改调整，直到所有的测试都运行成功；
6、按要求运行静态代码分析工具，确保遵守统一的代码风格，且通过一系列常见问题的静态扫描检测；
7、提交代码申请代码审核，根据反馈再做适当的修改，然后运行所有的单元测试并保证顺利通过。
产出将是两个配套的构建目标：库构建目标和测试构建目标。库构建目标是需要新发布的公共库，测试构建目标用以验证新发布的公共库是否满足需求。
网友评论