软件集成策略
流水先生的《软件集成策略》第一部分写得很精彩，我喜欢这种接地气，能让人一口气看下去的技术书。
书的第一部分描述了一个融入了软件集成思想的职场故事。
故事1《集成这破活》：男主人公晓川是一个集成工程师，他刚刚进入一个项目，因为还在初始阶段：程序员提交不多，合并也很快且不容易出问题，后面的编译、链接、打包、创建基线都很快。
故事2《对项目的不利影响竟然这么大》：项目经理老刘找到晓川，问他能否缩短集成的时间（比如从两周缩短为一周）。晓川回答说关键是提交代码的质量，只要程序员提交的代码都能构建通过，那他这边再集成到一起构建就肯定没问题。
故事3《构建错误是怎么来的》：可是如果程序员提交都没问题，集成到一起构建就肯定没问题吗？
故事4《与QA部门同事沟通》：QA部门的英英回应说程序员流程手册上写明了提交前必须通过构建。
故事5《第一个改进方案》：晓川与英英跟项目组开会时候通过了一个改进方案：程序员在提交分支之前，必须发信给项目组确认“已通过构建”。
故事6《意料外的问题》：程序员小周提交的构建，信中明确“已通过构建”，可是晓川拿过来在集成分支里构建却发现无法通过。英英根据之前的约定通报了小周的问题，却引起小周很大不满，他坚持在提交前已经通过构建，那么问题出在哪里呢？最后经晓川检查发现问题出在小周用了一个比集成分支更新的库。
故事7《合并导致的问题》：晓川明白了既然是没有基于最新基线，多造成了很多合并的问题，那么基于最新基线，就能够有效地减少合并的问题了！
故事8《第二个改进方案》：晓川与英英在项目组会议中提出了第二个改进方案：程序员在提交分支之前，必须保证已经跟最新基线合并过了，提交的版本是基于最新基线。
故事9《见义勇为好少年》：英英跟晓川说她的部门经理给了她建议：以后在通报批评某人之前，要跟当事人核实，不要直接公布对方出错。英英还说她的部门经理夸晓川为英英的解围是见义勇为。
故事10《把集成效率提高一倍》：老刘找到晓川，希望从两周变为每周做一次集成。
故事11《把改进方案讲给老大听》：晓川跟部门老大讲述了，两周变为每周做一次集成，反而工作量会变小。
故事12《跟项目经理谈判》：承诺尝试每周一次集成。
故事13《敲定第三个改进》：对程序员来说，里外里工作量抵消了。对于集成变频繁后，可能会有更多的提交进入到更新的基线，因此程序员向自己任务分支合并的工作量会变大。另一方面，集成变频繁后，程序员在任务开始时，基于的基线也有可能会变得更新了。里外里就抵消了。
故事14《每日构建》：晓川提出更密集的集成：每天下午1点开始集成，如果下午5点半之前，当天集成结束，那么第二天的提交必须基于这个基线；如果下午5点半之前集成没有结束，那么第二天的提交可以基于上一个基线。
故事15《在春节到来之前》：晓川在考虑如何让集成工作更自动化。因为每天都在做重复的事情，发邮件，收邮件，合并提交，找人解合并冲突，构建，找人解决构建问题，出基线，汇总修改内容以便出报告。写点脚本多好玩。
故事16《老大给的材料》：老大给了晓川一个网址，里面是一个构建管理工具，是关于集成自动化；还有一篇文章，是关于持续集成的。
故事17《持续集成竟然这样干》：晓川看了那篇文章里面提到了工作模式：第一，所谓提交是由程序员直接把要提交的改动合并到集成分支；第二，程序员随时可以提交任何内容到集成分支；第三，集成工程师的集成不是计划好的，而是上一轮集成构建后，只要有新的提交就马上开始新一轮集成构建。
故事18《阿根廷探戈》：开始研究老大提供的构建管理工具。
故事19《用哪个持续集成工具好》：老大的持续集成文章里也提到了工具，叫持续集成服务器。这个工具是开源免费的，比老大推荐的工具好。晓川跟老大商量了下，用新计算机做每日集成，而老计算机做试验：创建基线，邮件通知。随后晓川去找项目上商量改流程，改成程序员任何时候都可以发信申请提交，只要他的任务分支已经基于很新的基线，并且通过了构建。
故事20《英英的强烈反应》：英英不同意程序员自己决定提交，认为难以控制。
故事21《同时解决两个问题》：晓川写了个脚本，开始时会与程序员交互，询问程序员待会儿是否需要自动执行更新任务分支，以及随后做构建。如果程序员已经手动更新过任务分支，并且手动启动过构建，那就告诉脚本不需要。而如果程序员还没有做这两个步骤，就告诉脚本一会儿要自动执行这两个步骤。
故事22《失败的改进》：晓川想增强现在使用的持续集成工具，就是自动测试。只要自动测试工具可以用一行命令启动一套自动测试工具集，那就能嵌入到持续集成工具里，在编译构建之后调用。QA部门老大提出自动测试在技术上具体怎么弄，应该是测试部门负责。后来就成立了一个自动测试攻关小组，包括测试部门两位同事，晓川和英英。晓川闲来无事，又开始研究静态程序分析的自动检测技术。晓川坚持把静态程序分析加到集成中去，结果却是严重影响了基线生成的速度。可是晓川依然坚称程序员应该在提交程序之前运行静态程序分析来提高程序质量。最终会议上激烈讨论后，各老大都否决了晓川的改进。会后英英点醒了晓川，过于独断专行，有点骄傲了。晓川认识到自己的错误，跟项目组商量最终解决方案是在基线出来后再运行静态分析，大致上每天晚上运行一次。
故事23《自动冒烟测试》：集成就是排除问题、提高质量的过程；但集成不能一味贪图质量。当初在集成中仅编译构建，就基本遵循了这个原则；而后来加入静态分析，就破坏了这个原则。那么在集成过程中排除了编译构建的错误后，如何抓住重点又抓住破坏力大的问题？得靠测试啊。在跟测试部门讨论自动化测试用例集的会议过程中，晓川提醒大家不要犯自己过去的错误，加入太多内容。大家一起讨论并整理出了一个列表，并标上了严重等级。这时候英英提醒大家，也许问题A比问题B严重，但问题B比问题A更容易发生，所以从风险管理角度，得统计每个问题发生的频率，这需要历史数据，如果没有就得从现在开始累积。最终的方案是把测试用例按照大的功能分成若干组，程序员可以挑选和本次改动相关的组，加上一组最基本的测试用例。
故事24《不可靠的自动测试》：因为自动化程序没有更新，导致有的程序员提交前运行自动化测试出错。晓川的解决方法就是把自动化测试脚本也放到了版本库里。在脚本运行时，会去检查各个构建工具的版本，能尽早发现工具与环境的问题。
故事25《如何进一步缩短工期》：晓川建议何不把集成分支当成超级任务的分支，也就是说每完成其中一个小任务，就提交到集成分支，于是依赖它的其他小任务就可以开始了。
故事26《没用的提交说明》：测试团队反馈程序员提交的基线说明对于测试团队来说太细了，看不懂，他们只想知道完成了哪些新功能。晓川写了一个小脚本，能提取出对测试人员有用的信息。能解析出任意两个给定基线间，所有对测试人员有用的信息。之所以是两个基线，是因为现在基线出得很频繁，测试人员关心的是上次测过的基线和这次要测的基线之间，有哪些重要的变化。
故事27《缺陷为什么这么多》：CC是code complete，就是程序功能开发基本完成的意思。测试部门忙啊，英英向晓川抱怨程序员只顾功能不管质量，缺陷呼呼的往里进。QA弄出很多流程，让程序员们觉得复杂，也难以有理想的管理方式。晓川在思考程序员的提交到底应该有什么样的质量呢？
故事28《草原夜色》：爱情故事。。。。
故事29《十字路口》：晓川师傅要调到测试部门了，因为集成工程师的工作越来越自动化，而还有不少测试没有自动化。晓川的老大找晓川谈话，希望他到新项目中把集成工作上的经验外推到上线工作。英英的老大也来找晓川谈话，QA部门即将更名为过程改进部，希望晓川到他们部门去，优化整个集成工作而不仅限于优化出基线的这部分集成。
故事30《我还没答应呢》：爱情故事终于有了结尾。。。。
