《The Mythical Man-Month（人月神話）》讀後感（2）
第10章 未雨綢繆
在化學領域中，在實驗室可以進行的反應過程，並不能在工廠中一步實現。一個被稱為“ 實驗性工廠（pilot planet）”的中間步驟是非常必要的，它會為提高產量和在缺乏保護的環境下運作提供寶貴經驗。軟體系統設計中也同樣有這方面的問題，若把設計的演算法應用到待發布的軟體中，根據時間進度把第一次開發的產品釋出給客戶，顯然這是非常糟糕的事情。
因此，管理上的問題變成了“是否預先計劃拋棄原型的開發，或者是否將該原型釋出給使用者？”，將原型釋出給使用者，可以獲得時間，但是它的代價高昂——對於使用者，使用極度痛苦；對於重新開發的人員，分散了精力；對於產品，影響了聲譽，即使最好的再設計也難以挽回名聲。
首先，我們要意識到，變化是與生俱來的，實驗性的系統必須被構建和丟棄。那麼，該如何為上述變化設計系統呢？這其中最重要的措施是使用高階語言和自文件技術，以減少變更引起的錯誤。採用編譯時的操作來整合標準宣告，在很大程度上幫助了變化的調整。此外，當系統發生變化時，管理結構也需要進行調整，我們還需要變更計劃組織架構。
在程式釋出給用後，變化仍將繼續。對於一個廣泛使用的程式，其維護總成本通常是開發成本的40％或更多，維護成本受使用者數目的嚴重影響，使用者越多，所發現的錯誤也越多。Campbell指出了一個顯示產品生命期中每月bug數的有趣曲線，它先是下降，然後攀升。缺陷修復總會以（20－50）%的機率引入新的bug。
圖3 出現bug數量是釋出時間的函式
在每次修復之後，必須重新執行先前所有的測試用例，從而確保系統不會以更隱蔽的方式被破壞。同樣，設計實現的人員越少、介面越少，產生的錯誤也就越少。系統軟體開發是減少混亂度（減少熵）的過程，所以它本身是處於亞穩態的。軟體維護是提高混亂度（增加熵）的過程，即使是最熟練的軟體維護工作，也只是放緩了系統退化到非穩態的程序。
第11章 干將莫邪
這裡要給大家科普一下，干將莫邪（ye，第二聲）不是一個將士叫莫邪，更不是王者榮耀裡的干將莫邪。干將是春秋楚國的一名鐵匠，奉楚王之命造劍，後其與妻子莫邪鑄成寶劍兩把，一曰干將，一曰莫邪。在干將將雌劍獻與楚王之後，便被楚王殺害，其子之後完成父願，用雄劍將楚王刺殺為父報仇。這一傳說讚頌了劍工高超的技藝，寶劍文字的神采和少年的壯烈，批判了統治者的殘暴。
本章當然是借干將莫邪高超的鑄劍技藝來告誡專案經理：軟體開發僅有通用工具是遠遠不夠的，他們應該制訂一套策略，以及為通用工具的開發分配資源，與此同時，他還必須意識到專業工具的需求。專案經理必須考慮、計劃、組織的工具有目標機器、輔助機器和資料服務、高階語言和互動式程式設計，來為專業需要和個人偏好制定更多專業的工具。
第12章 整體部分
經過以上十二個章節的討論，我們現在來探討下如何開發一個可以執行的系統？如何測試系統？如何將經過測試的一系列構件整合到已測試過、可以依賴的系統？
Bug在我們開發中難免會遇到，而產品的概念完整性在使它易於使用的同時，也使開發更容易進行以及 Bug 更不容易產生。細緻的功能定義、詳細的規格說明、規範化的功能描述說明以及這些方法的實施，大大減少了系統中必須查詢的 bug 數量。
為了剔除Bug，作者給出了測試規格說明、自頂向下的設計、結構化程式設計三個建議。程式除錯整體看來有四個步驟：本機除錯、記憶體轉儲、快照、互動式除錯。軟體系統開發過程中出乎意料的困難部分是系統整合測試。系統除錯花費的時間會比預料的更長，需要一種完備系統化和可計劃的方法來降低它的困難程度。作者建議使用經過除錯的構件單元，系統整合除錯要求在每個部分都能正常執行之後開始；搭建充分的測試平臺，產生相當於測試物件一半程式碼量的供除錯使用的所有程式和資料也不足為奇；對測試期間進行嚴格控制；一次只新增一個構建；變更階段化、定期變更。
第13章 禍起蕭牆
千里之堤毀於蟻穴，一天一天的進度落後是難以識別、不容易防範和難以彌補的，專案進度也經常以一種難以察覺，但是殘酷無情的方式慢慢落後。
這一點我們作為學生應該體會很深刻，當我們開啟教輔系統，發現今天的作業只有兩門，而截止日期在一週後，我們會怎樣做？那當然是選擇原諒他了，開啟Dota、吃雞，搞一搞自己感興趣的研究，看看視訊等待。在等到提交作業前，我們會發現不僅這兩個作業量難以在短時間內完成，而且我們作業由兩個變成了四個！特別是對於我們USTCer，給你喘息機會是不存在的，由於開始的懈怠或者延誤，將導致你之後的作業都會晚於預期完成。
軟體開發亦是如此，那麼我們該如何有效地預防這個問題呢？根據一個嚴格的進度表來控制專案，其中第一個步驟是制訂進度表。里程碑的選擇只有一個原則，那就是，里程碑必須是具體的、特定的、可度量的事件，能夠進行清晰定義。對於里程碑的結果，只有達到和未達到兩種，不能說是90%、99%完成了。
作為程式的開發者，我們應該是進取的，關心每一天的滯後，因為它們是大災禍的基本組成元素。作為專案經理，讓老闆知道地板下的汙垢——專案進度上的問題，無論是減少角色衝突和鼓勵狀態共享，或是直截了當的展示，這一點對預防專案滯後也是非常有幫助的。
第14章 另外一面
公共應用程式的使用者在時間和空間上都遠離它們的作者，因此對這類程式，文件的重要性更是不言而喻！對軟體程式設計產品來說，程式向用戶所呈現的面貌和提供給機器識別的內容同樣重要。
現實中可能經常會出現這樣的現象，在團隊與客戶交付的會議中，技藝高超的程式設計師向客戶“哐哐哐”展示產品技術細節，客戶往往聽得一頭霧水，而產品經理則會用相對不那麼“技術”的話語來向客戶闡述，客戶便恍然大悟。這裡，我們可以將技藝高超的程式設計師理解為計算機程式，是人與機器互動的資訊；產品經理則是需求文件，代表了程式與使用者間的互動。
文件的必要性不言而喻，問題在於什麼樣的文件才是好的文件？不同使用者需要不同級別的文件，每個使用者都需要一段對程式進行描述的文字，這其中包括：目的、環境、範圍、實現功能和使用的演算法、輸入-輸出格式、操作指令、選項、執行時間、精度和校驗。除了程式的使用方法，還必須附帶一些程式正確執行的證明，即測試用例。調整程式或者修復程式則需要更多的資訊，修改者需要一份清晰的系統的內部結構資訊，這將包括：流程圖或子系統的結構圖、對所用演算法的完整描述、對所有檔案規劃的解釋、資料流的概要描述、初始設計中，對已預見修改的討論；特性、功能回撥的位置以及出口；原作者對可能會擴充的地方以及可能處理方案的一些意見。
值得注意的是，為了使文件易於維護，將它們合併至源程式是至關重要的，而不是作為獨立文件進行儲存。
第15章 沒有銀彈——軟體工程中的根本和次要問題
人狼的傳說中，人狼是一種具有人和狼兩種特徵的恐怖生物，而銀彈是消滅它的一種最有效的子彈。作者將軟體開發比作人狼，而將提高軟體開發效率的方法比作銀彈。作者預言未來十年，想要試圖通過尋找一種有效地銀彈將軟體開發效率提高一個甚至幾個數量級，這種銀彈不可能出現。
所有軟體活動包括根本任務——打造由抽象軟體實體構成的複雜概念結構，次要任務——使用程式語言表達這些抽象實體，在空間和時間限制內將它們對映成機器語言。軟體工程領域的根本難題在於複雜度、一致性、可變性和不可見性。文中羅列了一些可能的銀彈，如Ada 和其他高階程式語言、面向物件程式設計、人工智慧等，這些都只能解決軟體工程中的非本質困難，而對於軟體工程根本的問題於事無補。就是說，我們某種程度上能夠解決使用程式語言表達抽象的實體，或者將其變得結構化，構建起完整的概念結構，但是仍然沒有解決軟體工程的“複雜度、一致性、可變性和不可見性”這一根本難題。
現在的技術中最有希望的，並且解決了軟體的根本而非次要問題的技術，是開發作為迭代需求過程的一部分——快速原型化系統的方法和工具。這是因為快速原型有助於澄清軟體工程的概念結構，從而降低了後期變更的幅度。基於快速原型進行增量開發，目前已經成為實際開發的標準流程。快速原型化方法是一種增量方法，是一種自外向內型的設計模式。在開發真實系統之前，構造一個原型，通過使用者和軟體開發人員之間的互動，在該原型的基礎上，逐漸完成整個系統的開發工作。
第16章 再論《沒有銀彈》
自從《沒有銀彈》發表以後，遭到了大量的誤解、批評和質疑，作者又專門寫了這篇文章來繼續解釋他的觀點和迴應批評，這裡提到了很多潛在的銀彈。
例如Harel提出的一種叫做Vanilla的框架，Jone的質量帶來生產率的觀點、面向物件這枚“銅彈”、軟體重用等，這些到現在看來並未稱為一枚真正意義上的銀彈。最後Brooks總結說這枚銀彈的本質並未改變，我們依舊沒法找到這枚銀彈，現在是從業者研究和分析革命性進展的時刻，而不是等待或希望它的出現。
第17章 《人月神話》的觀點：是或非？
這裡，作者Brooks回顧了1975年版《人月神話》中那些被推翻和被支援的觀點。他將它們表達成刻板的形式是希望能引起讀者的思考、判斷和討論。
本章類似於一本觀點手冊，這裡便不一一例舉，大家有興趣的話可以翻閱看看。
第18章 20年後的人月神話
本章作為上一章的2.0版本，站在20年後的角度來看當年的一些觀點。
概念完整性和結構師。概念完整性是產品質量的核心。擁有一位結構師是邁向概念完整性的最重要一步。這個原理決不僅限於軟體系統，它適用於所有的複雜事物，如計算機、飛機、防禦系統、全球定位系統等。
開發第二個系統所引起的後果：盲目的功能和頻率猜測。
圖形（WIMP）介面的成功。在過去 20 年內，軟體開發領域中，令人印象最深刻的進步是視窗（Windows）、圖示（Icons）、選單（Menus）、指標選取（Pointing）介面的成功——或者簡稱為 WIMP。這些在今天是如此的熟悉，以致於不需要任何解釋。
沒有構建捨棄原型——瀑布模型是錯誤的！瀑布模型的基本謬誤是它假設專案只經歷 一次 過程，而且體系結構出色並易於使用，設計是合理可靠的，隨著測試的進行，編碼實現是可以修改和調整的。瀑布模型的第二個謬誤是它假設整個系統一次性地被構建，在所有的設計、大部分編碼、部分單元測試完成之後，才為閉環的系統測試合併各個部分。
增量開發模型更佳——漸進地精化。文中列舉了構建閉環的框架系統、Parnas 關於搭建一棵相關產品的家族樹、Microsoft 的“每晚重建”方法、增量式開發和快速原型，這些都對如今的軟體工程領域產生了極大的影響。
關於資訊隱藏，作者指出了Parnas 是正確的，自己是錯誤的。Parnas認為程式碼模組應該採用定義良好的介面來封裝，這些模組的內部結構應該是程式設計師的私有財產，外部是不可見的。資訊隱藏——現在常常內建於面向物件的程式設計中——是唯一提高軟體設計水平的途徑。
此外，Brooks還對其他的一些觀點進行了總結，並對未來軟體工程進行了展望，這裡，我只是引用了他文末的最後一段，其餘的部分就不一一贅述了，我認為我們應該已經具備新世紀的視角來對現如今的軟體工程領域進行獨立判斷。
“軟體工程的焦油坑在將來很長一段時間內會繼續地使人們舉步維艱，無法自拔。軟體系統可能是人類創造中最錯綜複雜的事物，只能期待人們在力所能及的或者剛剛超越力所能及的範圍內進行探索和嘗試。這個複雜的行業需要：進行持續的發展；學習使用更大的要素來開發；新工具的最佳使用；經論證的管理方法的最佳應用；良好判斷的自由發揮；以及能夠使我們認識到自己不足和容易犯錯的——上帝所賜予的謙卑。”
至此，《人月神話》一書就大致敘述完畢了，可能存在很多個人的觀點和理解錯誤，歡迎大家指出並提出意見。這裡請允許我做一個小小的感悟，《人月神話》並非像很多技術類叢書一樣教授我們很多實際的理論知識，它更多的是跟我們交流軟體開發中的一些誤區和心得。作為程式開發人員（這裡就不說是程式猿/媛了），閱讀這樣的書籍，甚至說是小說，對我們理解工作內容和思考工作方式是大有裨益的。就我個人而言，之前看過《敏捷估計與規劃》（Mike Cohn著）一書，實際上，書中的很多理論在人月中的討論中都有體現。
最後，我希望通過我們不僅是我們IT人士的不斷地摸索和交流，不斷尋找出一條適合如今軟體工程開發的道路，續寫這段流傳的人月神話。
書籍下載連結：連結：https://pan.baidu.com/s/1ec9108i1jeQdZFFZiRk0sw；提取碼：hfbs。
以下兩篇部落格在本文的寫作中提供了一定的見解和總結，在此特別感謝。