今天我看到了本書的第九章，本章主要講了關於軟件開發的方法論。同時作者為我們介紹了軟件缺陷編年史上數量不多但是足以警示世人的驚人災難。

1962年6月，水手一號探測飛船在發射5分鐘後偏離軌道，為避免墜入居民區，飛行控制人員只好將其引爆。問題在哪？導航控制程序中少了一個連字符。1996年6月歐洲航天局投入5億美元建造的阿麗亞娜5號無人運載火箭發射後40分鐘爆炸，原因是在控制其導航系統的程序中有一個缺陷。（代碼要將64位變量轉換為16位變量，但是數字太大，出現緩存溢出，系統停滯了。）從1985年到1987年，由於軟件缺陷，一臺放射治療儀向6名患者放射了過量的X射線。在1991年的海灣戰爭中，在飛毛腿導彈襲來時，由於愛國者導彈的一個電池未能成功點火，敵方導彈擊中美國營地，導致

上述事例以及類似故事數量太少，不足以引起媒體的憤怒和政治上的騷動，但它們卻警示著我們對於程序員工作質量的依賴。

由此更引發了我們對於軟件開發過程中的項目組織方式的思考。幾十年來，典型的項目組織方式遵循“瀑布模型”——將項目切分成為依序進行的多個獨立階段，比如需求定義、設計、實現、集成、測試、和發布。每個階段需在下個階段開始前完成。這套做法在紙上看起來合乎邏輯。但是實踐起來總是不可避免的導致延誤、混亂、和災難。每個階段都耗時無算，但每一個工作正常的。程序員們要麽坐等需求，要麽在拿到需求之前就開始做設計。

之後又出現了一種“螺旋模型”的替代方案。將開發切割成為六個月到兩年的“叠代周期”。可更快生產出可工作代碼的“小瀑布”。從部分完成的產品使用中得到反饋、指導下一代叠代。這個模型在大規模政府承包軟件開發中逐漸成為標準，但在商業軟件的飛速發展中還是太慢。

在20世紀90年代又出現了一種“極限編程”的開發方式。這中方式強調個體和交互勝於過程和工具，可工作的軟件勝於面面俱到的軟件，客戶協作勝於合同談判，響應需求勝於遵循計劃。盡管後者均有其價值，但是我們還是更關註前者。這種開發方式雖然免去了重量式開發的條條框框，但也給一些程序員找到了一些借口，他們只遵循讓他們舒服的規矩。所以在開發過程中出現了很多混亂狀態。

關於開發方式的探索仍在繼續。

夢斷代碼閱讀筆記之三