持续迭代与持续集成
天有其时，地有其材，人有其治，夫是之谓能参。—《询子》
读中国古代哲学，首先感受到的是它的整体思维。
例如天地人一体观，讲究在看待任何事物时，都要把它们放置于天、地、人三大要素构成的宇宙框架中去分析、衡量，以寻找他们的本质和规律，预测它们的未来变化。
基于中国古代哲学的中医也是如此，认为为医之道，应该上知天文，下知地理，中知人事，综合考虑自然环境、社会环境、个人气质，把人体地生理、病理变化放在天、地、人三大要素构成的宇宙框架中去分析和权衡，以寻找其本质和规律，预测其发展变化。
说到整体思维，我就想到了一种非常早期的软件工程模型-瀑布模型。
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动。这六个步骤必须按照它们的顺序严格地依次进行。但如果发现前面的某一步出现了错误，就不得不返回到那一步。
| 客户需求 | –（分析）–（设计）–（编写）–（测试）–（交付）–>最终产品 |
由此可见，越前面的步骤，对整个生命周期的影响就越大，而且对最终结果的影响也越大。这就使得在前面分析设计的过程中，一定要尽量地小心谨慎，思虑万全。（当时的分析师、设计师们一定压力山大 :-( ）
然而即使有着这样优质的分析与设计为生命周期打前锋，但这样的模型仍然不受欢迎，因为它固有的缺点。
1.过程中缺少与客户的交流，如果产品偏离了客户的目标，要等到交付的时候才能发现
2.发现上一阶段的问题，不得不返工
3.生命同期的过程中，如果客户想看看半成品是否满足需求，却是很难做到的
4.过于倚重分析设计阶段，对于暂未暴露的问题难以应对
难道这种全局观的思维方式对计算机软件开发过程不适用吗？
上文说过，中医要求通过各个方面去考察，从整体上把握人体的病理状态与趋势。既然得到了病理状态和趋势，就要对证施治了。他会把施治过程所有要用到的方法与药物一次性列出来，告诉病人第几天吃什么，第几天做什么，等到把这一系列整事情做完，就痊愈了吗？
| 病人 | – （治疗1）–（治疗2）–（治疗3）–>健康的人 |
也许神人能做到，但作为医生不可能也不允许这么做。
医生的通常做法是这样的：
从整体上分析，得到病人的病理状态与趋势，病理状态也许是复杂的，有主症，有并发症，有急症，有慢性症
针对主症或者急症，确立一个短期（不超过三天）的治疗目标，制定治疗方案
病人接受治疗后，向医生反馈治疗效果和病情发展，例如变轻或严重或没有变化
医生结合病人的反馈，进一步从整体上辨证及施治。
辩证 -> 论治 -> 辩证 -> 论治 。。。
这样的好处很明显：
- 只是对短期目标施治，相对来说简单，容易做过
- 如果诊断失误或出现没有预料到的问题，能够及时调整策略
看上去刚好能解决瀑布模型的问题，我们也把整个工程分阶段，每一个阶段是一个小瀑布。每次只选择当前最需要完成的小瀑布并把它做好。这样一直持续迭代下去，当每一个小瀑布完成，整个工程也就完成了。这样，每次只需要对小瀑布做分析设计，不是简单的多？
| 客户需求 | –（目标1）–（目标2）–（目标3）–最终目标 |
那么问题来了，部分+部分+……+部分=整体？这等式成立吗？
不一定。所有局部都是最优并不一定最终结果是最优的。
再仔细观察辨症论治的过程，发现每次重新辨证的时候，不但要分析病理状态和趋势，还要结合上一个迭代同期中病人反馈的结果。
这就是持续集成的过程。
把持续集成与持续迭代运用于瀑布过程中，就成了这样：
从整体上分析项目的状态与目标
从整体上思考这个目标，将它划分成多个阶段的小目标
从整体上分析这个小目标，选择其中一个。这个目标对于整体来说只是一部分，但对于它自己来说，又是另一个整体。
把这个阶段性的小目标当一个整体，对它按照瀑布流程做分析与设计
交付这个小目标，并收取反馈
根据反馈调整剩余的小目标
确认当前需求 -> 交付 -> 确认当前需求 -> 交付 。。。
瀑布模型只是一个简单的例子，瀑布模型已经不再流行，而各种更合适的模型横行天下。
这种分析与改进瀑布模型的文章已没有新意，对软件工程来说也没有意义。
以下才是我想要表达的观点：
“整体”与“部分”是一对阴阳。它们是对立统一的关系。
整体”与“部分”又可以相互转化。在一定条件下，“部分”可以看作“整体” ，“整体”又可以看作是另一个“整体”的“部分”。
“整体”的问题可以分割成“部分”来处理，即持续迭代。
“部分”的问题也可以通过“整体”来调整，即持续集成。
持续迭代和持续集成是交替进行的过程，缺一不可。
整体 -> 部分 -> 整体 -> 部分 。。。