软件集成策略

流水先生的《软件集成策略》第一部分写得很精彩，我喜欢这种接地气，能让人一口气看下去的技术书。

书的第一部分描述了一个融入了软件集成思想的职场故事。

故事1《集成这破活》：男主人公晓川是一个集成工程师，他刚刚进入一个项目，因为还在初始阶段：程序员提交不多，合并也很快且不容易出问题，后面的编译、链接、打包、创建基线都很快。

故事2《对项目的不利影响竟然这么大》：项目经理老刘找到晓川，问他能否缩短集成的时间（比如从两周缩短为一周）。晓川回答说关键是提交代码的质量，只要程序员提交的代码都能构建通过，那他这边再集成到一起构建就肯定没问题。

故事3《构建错误是怎么来的》：可是如果程序员提交都没问题，集成到一起构建就肯定没问题吗？

故事4《与QA部门同事沟通》：QA部门的英英回应说程序员流程手册上写明了提交前必须通过构建。

故事5《第一个改进方案》：晓川与英英跟项目组开会时候通过了一个改进方案：程序员在提交分支之前，必须发信给项目组确认“已通过构建”。

故事6《意料外的问题》：程序员小周提交的构建，信中明确“已通过构建”，可是晓川拿过来在集成分支里构建却发现无法通过。英英根据之前的约定通报了小周的问题，却引起小周很大不满，他坚持在提交前已经通过构建，那么问题出在哪里呢？最后经晓川检查发现问题出在小周用了一个比集成分支更新的库。

故事7《合并导致的问题》：晓川明白了既然是没有基于最新基线，多造成了很多合并的问题，那么基于最新基线，就能够有效地减少合并的问题了！