持續迭代與持續整合

天有其時，地有其材，人有其治，夫是之謂能參。—《詢子》

讀中國古代哲學，首先感受到的是它的整體思維。

例如天地人一體觀，講究在看待任何事物時，都要把它們放置於天、地、人三大要素構成的宇宙框架中去分析、衡量，以尋找他們的本質和規律，**它們的未來變化。

基於中國古代哲學的中醫也是如此，認為為醫之道，應該上知天文，下知地理，中知人事，綜合考慮自然環境、社會環境、個人氣質，把人體地生理、病理變化放在天、地、人三大要素構成的宇宙框架中去分析和權衡，以尋找其本質和規律，**其發展變化。

說到整體思維，我就想到了一種非常早期的軟體工程模型-瀑布模型。

瀑布模型將軟體生命週期劃分為制定計畫、需求分析、軟體設計、程式編寫、軟體測試和執行維護等六個基本活動。這六個步驟必須按照它們的順序嚴格地依次進行。但如果發現前面的某一步出現了錯誤，就不得不返回到那一步。

客戶需求|- -（分析）-- （設計）-- （編寫）-- （測試）-- （交付） -->最終產品

由此可見，越前面的步驟，對整個生命週期的影響就越大，而且對最終結果的影響也越大。這就使得在前面分析設計的過程中，一定要盡量地小心謹慎，思慮萬全。（當時的分析師、設計師們一定壓力山大 :-( ）

然而即使有著這樣優質的分析與設計為生命週期打前鋒，但這樣的模型仍然不受歡迎，因為它固有的缺點。

1.過程中缺少與客戶的交流，如果產品偏離了客戶的目標，要等到交付的時候才能發現

2.發現上一階段的問題，不得不返工

3.生命同期的過程中，如果客戶想看看半成品是否滿足需求，卻是很難做到的

4.過於倚重分析設計階段，對於暫未暴露的問題難以應對

難道這種全域性觀的思維方式對計算機軟體開發過程不適用嗎？

上文說過，中醫要求通過各個方面去考察，從整體上把握人體的病理狀態與趨勢。既然得到了病理狀態和趨勢，就要對證施治了。他會把施治過程所有要用到的方法與藥物一次性列出來，告訴病人第幾天吃什麼，第幾天做什麼，等到把這一系列整事情做完，就痊癒了嗎？

病人|-
-（**1）--
（**2）--
（**3）
-->健康的人

也許神人能做到，但作為醫生不可能也不允許這麼做。

醫生的通常做法是這樣的：

這樣的好處很明顯：

- 只是對短期目標施治，相對來說簡單，容易做過

- 如果診斷失誤或出現沒有預料到的問題，能夠及時調整策略

看上去剛好能解決瀑布模型的問題，我們也把整個工程分階段，每乙個階段是乙個小瀑布。每次只選擇當前最需要完成的小瀑布並把它做好。這樣一直持續迭代下去，當每乙個小瀑布完成，整個工程也就完成了。這樣，每次只需要對小瀑布做分析設計，不是簡單的多？

客戶需求|- -（目標1）-- （目標2）-- （目標3）-- 最終目標

那麼問題來了，部分+部分+……+部分=整體？這等式成立嗎？

不一定。所有區域性都是最優並不一定最終結果是最優的。

再仔細觀察辨症論治的過程，發現每次重新辨證的時候，不但要分析病理狀態和趨勢，還要結合上乙個迭代同期中病人反饋的結果。

這就是持續整合的過程。

把持續整合與持續迭代運用於瀑布過程中，就成了這樣：

瀑布模型只是乙個簡單的例子，瀑布模型已經不再流行，而各種更合適的模型橫行天下。

這種分析與改進瀑布模型的文章已沒有新意，對軟體工程來說也沒有意義。

以下才是我想要表達的觀點：