开始以为这本书会有一些偏理论，然后读过之后才发现有一种想见恨晚的感觉，作者在项目管理中遇到的很多问题正是我们也经常遇到的。

首先引用敏捷第一宣言：“我们的首要任务是尽早持续交付有价值的软件并让客户满意。”

常见的发布反模式

• 手工部署软件
• 开发完成之后才行类生产环境部署
• 生产环境的手工配置管理
  
  

配置管理

   
   版本控制

• 对所有内容进行版本控制
  
  • 不只是源代码管理，每个与锁开发的软件相关的产物都应被置于版本控制之下
  • 不推荐将编译后的二进制文件纳入版本控制，
    
• 频繁提交代码到主干, 为了确保提交代码时不破坏已有的应用程序
  
  • 一是提交代码之前运行单元套件
  • 二是增量式引入变化，建议每完成一个小功能或一次重构之后就提交代码。
    
• 使用意义明显的注释，注释中最好包含一个链接，可以链接到项目管理工具中的一个功能或缺陷。
  

   
   依赖管理

• 外部库文件管理 * 应该始终指定外部库的确切版本
• 组件管理
  

   
   实现持续集成

• 准备工作
  
  • 版本控制（git，svn）
  • 自动化构建（fastlane）
    
• 持续集成的前提条件
  
  • 频繁提交
  • 创建全面的自动化测试套件
  • 保持较短的构建和测试过程
    
• 必不可少的实践
  
  • 构建失败之后不要提交新代码
  • 提交前在本地运行所有的提交测试，或者让持续集成服务器完成此事
  • 等提交测试通过后再继续工作
  • 回家之前，构建必须处于成功状态
  • 不要将失败的测试注释掉
    

   自动化测试中的测试替身

• 哑对象（dummy object）指那些被传递但不被真正使用的对象，它们通常只用于填充参数列表。
• 假对象（fake object）是可以真正使用的实现
• 桩（stub）为每个调用提供一个封装好的响应。
• 模拟对象（mock）是一种在编程时就设定了它预期要接收的调用。
  

   提交阶段

提交阶段是怎样工作的？

• 编译，并在集成后的源代码上运行提交测试。
• 创建能部署在所有环境中的二进制包
• 执行必要的分析，检查代码库的健康状况。
• 创建部署流水线后续阶段需要使用的其他产物。（比如数据库迁移或测试数据）
  

提交阶段的首要目标是要么创建可部署的产物，要么快速失败并将失败原因通知给团队。

• 提交阶段比较有用的度量项
• 测试覆盖率
• 重复代码的数量
• 圈复杂度
• 输入耦合度和输出耦合度
• 编译警告的数量
• 代码风格
• 提交测试阶段测试套件的原则与实践
• 避免用户界面 测试困难，耗费时间和精力 速度慢 * 可以放在验收测试节点处理
• 使用依赖注入
• 避免使用数据库
• 在单元测试中避免异步 * 解决方法就是拆分测试，将异步操作拆分单独的单元测试。
• 使用测试替身 Stub, 常常需要额外写很多代码，我们不需要关心桩是如何被调用的 Mock, 一般通过Mock框架模拟对象，我们需要验证代码是否以期望的方式与模拟对象交互。
• 最少化测试中的状态
• 自动化验收测试
  
• 窗口驱动器模式，也就是分为测试实现层和窗口驱动层，这样使测试实现层抽象层次更高，只有窗口实现层才与具体的GUI打交道。
• 我理解的自动化测试是：为了验证用户故事是否满足业务而编写的一系列操作过程，与单元测试不同的是，它是面向业务，而单元测试是面向开发人员的。
• 如何实现验收测试
  

   分支与合并

几种常见的分支发布策略：

• 主干开发；说白了，就是所有开发人员都往主干分支上提交代码。
• 按发布创建分支；即当软件准备发布的时候，才从主干创建分支。
• 按功能特性分支；应该是当下很多公司比较喜欢使用的一种策略。
• 按团队分支；比较适合大型团队，为每个团队都创建一个分支。
  

基于主干开发的三个好处：

• 确保所有的代码被持续集成。
• 确保开发人员及时获得他人的修改。
• 避免项目后期的“合并地狱”和“集成地狱”。
  

文中指出，“创建分支”与“持续集成”往往是背道而驰的，意味着说创建分支越多，就越难实现持续交付，因为开发人员都在各自的分支频繁提交代码，而“分支”上的代码往往在几天之后（甚至更长的时间）才会合并回主干，这样会导致在后期才会发现因合并代码导致的种种问题。（DevOps时代）

开始以为这本书会有一些偏理论，然后读过之后才发现有一种想见恨晚的感觉，作者在项目管理中遇到的很多问题正是我们也经常遇到的。

首先引用敏捷第一宣言：“我们的首要任务是尽早持续交付有价值的软件并让客户满意。”

常见的发布反模式

• 手工部署软件
• 开发完成之后才行类生产环境部署
• 生产环境的手工配置管理
  
  

配置管理

   
   版本控制

• 对所有内容进行版本控制
  
  • 不只是源代码管理，每个与锁开发的软件相关的产物都应被置于版本控制之下
  • 不推荐将编译后的二进制文件纳入版本控制，
    
• 频繁提交代码到主干, 为了确保提交代码时不破坏已有的应用程序
  
  • 一是提交代码之前运行单元套件
  • 二是增量式引入变化，建议每完成一个小功能或一次重构之后就提交代码。
    
• 使用意义明显的注释，注释中最好包含一个链接，可以链接到项目管理工具中的一个功能或缺陷。
  

   
   依赖管理

• 外部库文件管理 * 应该始终指定外部库的确切版本
• 组件管理
  

   
   实现持续集成

• 准备工作
  
  • 版本控制（git，svn）
  • 自动化构建（fastlane）
    
• 持续集成的前提条件
  
  • 频繁提交
  • 创建全面的自动化测试套件
  • 保持较短的构建和测试过程
    
• 必不可少的实践
  
  • 构建失败之后不要提交新代码
  • 提交前在本地运行所有的提交测试，或者让持续集成服务器完成此事
  • 等提交测试通过后再继续工作
  • 回家之前，构建必须处于成功状态
  • 不要将失败的测试注释掉
    

   自动化测试中的测试替身

• 哑对象（dummy object）指那些被传递但不被真正使用的对象，它们通常只用于填充参数列表。
• 假对象（fake object）是可以真正使用的实现
• 桩（stub）为每个调用提供一个封装好的响应。
• 模拟对象（mock）是一种在编程时就设定了它预期要接收的调用。
  

   提交阶段

提交阶段是怎样工作的？

• 编译，并在集成后的源代码上运行提交测试。
• 创建能部署在所有环境中的二进制包
• 执行必要的分析，检查代码库的健康状况。
• 创建部署流水线后续阶段需要使用的其他产物。（比如数据库迁移或测试数据）
  

提交阶段的首要目标是要么创建可部署的产物，要么快速失败并将失败原因通知给团队。

• 提交阶段比较有用的度量项
• 测试覆盖率
• 重复代码的数量
• 圈复杂度
• 输入耦合度和输出耦合度
• 编译警告的数量
• 代码风格
• 提交测试阶段测试套件的原则与实践
• 避免用户界面 测试困难，耗费时间和精力 速度慢 * 可以放在验收测试节点处理
• 使用依赖注入
• 避免使用数据库
• 在单元测试中避免异步 * 解决方法就是拆分测试，将异步操作拆分单独的单元测试。
• 使用测试替身 Stub, 常常需要额外写很多代码，我们不需要关心桩是如何被调用的 Mock, 一般通过Mock框架模拟对象，我们需要验证代码是否以期望的方式与模拟对象交互。
• 最少化测试中的状态
• 自动化验收测试
  
• 窗口驱动器模式，也就是分为测试实现层和窗口驱动层，这样使测试实现层抽象层次更高，只有窗口实现层才与具体的GUI打交道。
• 我理解的自动化测试是：为了验证用户故事是否满足业务而编写的一系列操作过程，与单元测试不同的是，它是面向业务，而单元测试是面向开发人员的。
• 如何实现验收测试
  

   分支与合并

几种常见的分支发布策略：

• 主干开发；说白了，就是所有开发人员都往主干分支上提交代码。
• 按发布创建分支；即当软件准备发布的时候，才从主干创建分支。
• 按功能特性分支；应该是当下很多公司比较喜欢使用的一种策略。
• 按团队分支；比较适合大型团队，为每个团队都创建一个分支。
  

基于主干开发的三个好处：

• 确保所有的代码被持续集成。
• 确保开发人员及时获得他人的修改。
• 避免项目后期的“合并地狱”和“集成地狱”。
  

文中指出，“创建分支”与“持续集成”往往是背道而驰的，意味着说创建分支越多，就越难实现持续交付，因为开发人员都在各自的分支频繁提交代码，而“分支”上的代码往往在几天之后（甚至更长的时间）才会合并回主干，这样会导致在后期才会发现因合并代码导致的种种问题。（DevOps时代）