轉自：http://coolshell.cn/?p=1654 （酷殼）
源文：鏈接 （本文主要根據挑戰者號的問題，以及Richard Feynman那對NASA嚴厲的批評報告，批評了不適當的“自頂向下”的設計方法，並總結了一下軟件工程和其它工程的相通的一些觀點。翻譯水平有限，歡迎指正）
佛羅里達州，美國東部時間1986年1月28日上午11時39分，挑戰者號航天飛機 執行爲期6天的STS-51-L 任務，在發射後，其右側固體火箭助推器（SRB - Solid Rocket Booster）的O型環密封圈（用於連接兩節助推器）失效，泄漏出來的熱汽達到了5000華氏度，直接蒸發了O型密封圈，並灼燒了毗鄰的外部燃料艙，在幾秒鐘內，外部燃料艙出現結構連接失效，空氣的動力迅速分解了航天飛機。在而航天飛機上升72秒以後，助推器脫落，導致航天發飛向側面滑出。幾乎在引航員 Michael J. Smith 發出”Uh oh” 的同時，整個航天飛機完全解體，片刻，航天飛機內部發生爆炸，所有7名宇航員罹難。 那時的我還只是一個小孩，我從電視下方滾動的新聞條目知道了這一慘劇。
在那個時候，火箭助推器工程師曾經警告過這個O型環可能存在問題，但可惜的是，NASA的管理層忽略了這個問題。
美國總統里根委派羅傑斯委員會對事故進行了調查，調查成員包括著名的物理學家Richard Feynman。其不羈的態度和直來直去的方法和羅傑斯委員會的風格形成了鮮明的反差。主席羅傑斯，一個政客，評論Feynman是一個“真正的痛苦”。最後，在委員會提交的報告中，Feynman反判的觀點幾乎被清除了出去。並且，Feynman曾被主席威脅過要把他的名字從報告中完全除掉，但最終，他們還是同意在報告中加一個附錄，但只是個人觀點—— Appendix F – Personal Observations on Reliability of Shuttle。
這是一個好的報告，因爲，這是一個富有才華的報告。其深深地洞察了在實現一些高可靠性的系統時的工程學中的一些很自然性的東西。是的，在這裏，我並沒有放上“軟件工程” 的字樣，只是工程。但Feynman的結論卻非常和我們的軟件開發有着不可分割的關係。這是最基本的東西，無論是軟件工程，還是別的工程學。下面，讓我們來看看，Feynman是怎麼說的：
航天飛機主引擎的建造方式是自頂向下(top down)，我們可以這樣說。整個引擎被設計把所有的事情放在一起，而那些相關的細節上的東西在設計當時還並不是很成熟的。所以，當其中的小零件（軸承，渦輪片，散熱管，等等）出現問題時，我們需要花費昂貴的代價才能找到事故的原因，也很難作出修改。要避免問題發生，需要頻繁的維護和置換重要的零部件。修理很多時候不會解決真正的原因。
可見，軟件開發中也一樣，Bug在整個過程中存在的時間越長， 我們就越難解決這個問題。很顯然，自頂向下的方法，因爲在設計的時候並不熟悉實際問題，所以，Bug從設計的時候就出現了。然而，我們需要明白，需求和設計的不同之處。需求需要對產品一種清楚和良好的定義，設計則是解決如何達到需求的方法。Feynman 在這裏並沒有反對 功能規格說明書，他只是反對自頂向下的設計方法，比如： UML 就是藍圖 的鼓吹者。再來看看他的言論：
航天飛機主引擎是一個非常不同尋常的機器，它和以前所有的引擎都不一樣。這完全超出了以前引擎制的工程經驗。所以，不奇怪的，許多不同的流程和難點都會在工程中出現。然而，很不幸地，這是通過自頂向下設計，所以，那些流程和問題是很難被發現被修正的。設計要求的引擎壽命可以完成55次點火任務（相當於27,000秒的操作，也就是說，第次點火需要500秒），但事實上這並沒有完成。而引擎現在則需要頻繁維護，並需要經常更換重要的部件，比如：渦輪泵，軸承，金屬片，等等。
“不合適的自頂向下的設計方式，導致了問題很難去發現和修正，最終沒有完成設計需求，頻繁性地維護”這些描述方式，聽起來是不是似曾相識？我們每天在做的軟件工程和這個不一樣嗎？Feynman 詳細說明了爲什麼“自頂向下”的設計會讓發現和解決這些問題成爲那麼的難和痛苦的一件事：
很多這些已被解決的問題在一開始設計時都是設計的難點。很自然地，沒有人可以確定那些所有的已發現問題都能會出現，而其中一些，我們並沒有根據正確的原因在正確的地方解決這些問題。
無論這是Linux內核，或是航天飛機引擎，這些設計時的基本的問題都是相通的。而“自頂向下”是其中荒唐的一個，因爲，自頂向下，過度的注重了需求而忽略了現實，而那些下面非常細節的知識絕對是非常需要的，並不是所有的東西都可以抽象成出來。在他說起航空電子系統時（一個NASA的另一個部門）：
該軟件是採用了從底向上的方法被小心地做了檢查。首先，每一行代碼都被檢查過，然後，代碼段和模塊和一些詳細的功能被驗證過。而檢查範圍在一步一步地被擴大，直到新的改變被組合進來最終成爲一個完整的系統。這個過程最終的完整的輸出成爲了最終的產品，成爲了新的release。這個部門完全以一種中立的態度，把軟件作爲一個敵對方，不停地測試，校驗，就像自己就是這個軟件的用戶一樣。
是的，這就是1986年Feynman告訴大家的——Unit Test（單元測試），今天，Unit Test成爲了軟件開發活動中最最重要的一個環節（也許你以爲是Coding）。並不單單只是Unit Test，“步步爲營的增量式”和“以敵對的態度”，都是值得我們所學習的。我們經常聽到有人在抱怨軟件道，因爲軟件工程還太年輕了，還有很多知識我們還沒有得到，所以總是那麼多問題。這完全是胡說！我們痛苦是因爲，我們 總是忽略 早就確定了的， 早爲人所熟知， 以經歷和實踐去證明一切的方法。 當然，在這方面，我們的管理層也需要負責，尤其是那些紊亂的時間進度，錯誤的激勵機制，低檔次的招聘，和一些讓士氣受挫的制度，等等。“管理”和“工程”間的緊張關係最終成爲了糟糕的管理。Feynman在他的報告中也談到了這點，下面其中的一小段話：
總而言之，計算機軟件檢查系統和最負責的態度。是的，那裏並沒有那種自欺欺人而不顧固體燃料助推器的標準。但可以肯定的是，有關管理部門最新的建議，建議取消此類複雜而昂貴的不必要的測試。
這只是其中的一個小段。我把其挑出來是因爲其一針見血地指出了觀點，比如“最負責的態度”，以及“逐步的自欺欺人”。我建議你讀一讀報告全文， 可以讓你得到很多真相。關於軟件工程，下面是幾個主要觀點：
- 工程僅當在和其管理有好的關係的時候才能好。
- 大型的從上從前端的設計是愚蠢的。
- 軟件工程和其它傳統的工程學是一樣的。
- 可靠的系統由幾近殘酷的測試，增量式的自底向上的工程，以及高負責的態度來共同保證。
這篇報告中，還有很多不錯的觀點，如果你感受到了，歡迎你告訴我。
（全文完）
