功能代码的思维模式为创建， 重点在考虑用户、使用场景和数据流程上
测试代码的思维模式为破坏，怎样写测试代码用以扰乱分离用户及其数据
软件开发过程中乌托邦理想模式：功能开发人员、测试开发人员、用户开发人员在可用性和可靠性方面分工合作，达到完美：
代码的组织形式、开发过程、维护是日常工作重点
（1）公共的代码库、和谐的工程工具、公司范围内的资源共享，成就了丰富的google内部共享代码库与公共服务， 有利于加速项目完成和减少项目失败。
共享的基础代码实践规则：
（2）最小化平台依赖
操作系统尽可能地与google生产环境的操作系统一致， CPU和OS变化尽可能小。限制运行环境可以节省大量下游的测试工作，避免环境调试问题。保持简单，同样相对安全
（3）打包
打包是一个过程，将源代码编译成二进制文件，然后将二进制文件统一封装在一个linux rpm包里面
构建整体流程：
google产品由三部分组成：经过良好测试的独立库、可读性与可复用性不错的公共服务库、覆盖所有主要构建目标的单元测试套件
SET参与到测试目标构建中可，做更大规模的集成测试，编写mock和fake工具
通过参与设计和代码开发的方式尽早介入到开发流程中。SET需要了解如何去测试SWE编写的代码，并解答测试问题
若一个产品在概念上还没完全确定成型时去关心质量， 这是优先级混乱的表现；若测试长时间未介入到产品众，则产品可测试性也会很糟糕
google产品团队最初由一个技术负责人和一个或者多个项目发起人组成：技术负责人负责设定技术员方向、开展合作、充当与其他团队沟通的项目接口人， 理解细节
设计文档主要包括项目的目标、背景、团队成员、系统设计
审阅设计文档推荐要点：
SET会对protocol buffer代码做系统全面的审查， 集成测试的运行依赖这些接口的实现。集成测试依赖mock和fake，因为有了它们，一些依赖服务的期望错误场景和条件异常，会比较容易构建
规模更小且目的性更强的自动化计划，并存在可以提供帮助的测试框架， 会吸引SWE一起参与测试
SET应该把精力花费在提高质量方面，而不是花费在维护那些不稳定的端到端测试套件上， 因此SET遵循下面的方法：
SET第一要务就是可测试性， 质量顾问的角色
CL(chang list 变更列表)先经过自动化检查（代码风格、测试用例执行是否通过），然后代码审查（通过邮件方式通知审阅者）， 反复进行， 直到递交者和审阅者满意为止
提交队列主要功能是保持“绿色”的构建， 这是构建系统和版本控制系统之间最后一道防线
提交队列和持续集成构建的由来：P29
在机器上持续不断的构建并运行相应的单元测试与集成测试， 后来发现该系统具有一定的通用性， 可以用来支持其他团队