軟體工程管理——《人月神話的讀書筆記》(chapter11~chapter15)

Chapter 11 未雨綢繆

 

  •實驗性工廠和增大規模對於大多數項目，第一個開發的系統並不合用。現在的問題是“是否構建一個實驗性的系統，然後拋棄它”為捨棄而計劃，你一定要這樣做
 
實話，沒有看懂最後的結論。是翻譯的問題嗎？作者的意思是說要構建一個第一版本的項目，並且做好捨棄的準備？那麼，這個第一版本的項目是否要發布給使用者進行使用呢？其實這個問題在現在看來已經是一個很普遍的現象了，通常情況下，無論哪個軟體廠商都會發布一個beta版本供使用者進行試用，然後進行改進，並且beta測試面向的受眾數量也日益增加。這點在「the Cathedral and the Bazaar」這篇論文中有所提及，實際上beta版本號碼召所有使用者參與進行測試的理念其實借鑒的是開源軟體在這方面的思想，是的軟體的健壯型增強，將軟體測試的任務由僅僅交由專業人士處理擴散到了更多使用者的頭上。這樣做是有意義的。所以，Brooks的觀點有待argue，暴露自己軟體自身的缺點是否是一個不好的行為？或許在一些小應用上，未必不好（忽略某些金融領域的應用）。
 

  拋棄原型的概念本身就是對事實的接受﹣隨著學習的過程而改進
 
其實看到這裡，可以理解Brooks倡導的是一種反覆式開發法的模型，並且他認為一開始的原型是肯定會被捨棄的。這個，在設計複雜系統的時候是這樣，不可能有一開始就設計完美的演算法，因為很有可能系統邏輯的複雜度會超過個人的掌控範圍，而團隊的邏輯設計則會牽扯到交流溝通方面的問題，針對大型複雜系統的設計做到天衣無縫，即使是花上很久的時間也未必是可行的，微軟基本在3~5年的周期以幾千個優秀工程師為團隊，加上出色的管理者，也未必做到（至少現在還沒做到…）。
 

  ∙為變更計劃系統變更的階段化是一種必要技術。每個產品都應該有相應的數字版本號碼。
 
這個思想同樣在raymond的論文中所提及，他同時也表示這個是Linux可以成功的關鍵之一。所謂的版本控制在今天看來已經是一件十分普遍的事情了，各種版本控制的工具已經十分成熟，如svn,cvs,github等等，包括許多商業化的軟體也採用了Linux 命名法則模式，用來標識各個不同的版本。
 

  •為變更計劃組織架構為變更組建團對比為變更進行設計更加困難。當系統發生變化時，管理結構需要進行相應的調整。老闆必須對他們的能力培養給予極大的關注，使管理員和技術人員具有可換性。
 
比較了Bell實驗室和IBM的做法，同樣都是可行的，各有各的好處，應該是因為性質的不同而有所不同，管理者在用人的時候不應該過多的瞻前顧後，擔心大才小用等等問題，果斷的在適當的時候用適當的人解決問題即可。
 

  •前進一步，後退兩步程式維護中的一個問題﹣缺陷修複總會以固定（20%~50%）的幾率引入新的bug
 
這個是常見的問題，也是由於軟體自身的複雜度造成的，但是誠如作者所言，機器在進步，配置在進步，到了一定程度之後必然需要在基於遺留系統的基礎上進行新系統的重新設計。
 

  軟體開發是熵減的過程，所以它是處於亞穩態的，軟體的維護是處於熵增的過程，只是放緩了系統退化到亞穩態的過程。
 
所以，根據這一論點我們可以推斷出的就是原有軟體在舊有基礎上維護升級到達一定版本之後必然會導致全部地推倒重來，或許其核心的設計細想不會改變，但是必然會跟隨硬體的發展而作出適應性的重新設計，正是由於其核心思想不變，故在很長一短時間內將會保留其與遺留系統的相容性，從而兼顧使用者體驗，當新系統維護到一定時間漸漸對更新系統有所訴求時，將會拋棄上一代的主要特性，當然，這也是和硬體技術的不斷髮展分不開的（以上乃個人胡謅…）。

Chapter 12 幹將莫邪

這章主要講的是軟體開發過程中用到的工具，包括軟體平台和硬體平台軟體平台主要講的是開發用的IDE環境也有，當然，當年只能是針對不同的編譯器進行比較，還有就是選擇的開發語言很重要。這點也是作者所指出的，專案管理人員同樣要對這一方面作出相應的管理和規定，不同的開發項目應該選擇不同的開發語言加以實現，在選擇不同語言的同時同樣要選取不同的編譯器，編譯器的最佳化效能不一樣同樣會影響到開發出的項目。硬體上，首先是開發平台的統一。開發人員需要在同樣的開發環境中共同完成開發工作單位，其次是涉及到不同的目標機器上的測試時，也要考慮目標機器的選取。這兩個硬體平台都是需要被考慮到的。當然，本書寫的年份因為比較早，所以很多東西在今天看來已經是習以為常了(¬_¬)

Chapter 13 整體部分

 

  剔除bug的設計關鍵的工作是產品的定義，許許多多的失敗完全是因為那些產品未精確定義而造成的。當遇到一些意想不到的問題時，按步就班的流程並不意味著步驟不能逆轉，直到推翻頂層設計，重新開始整個過程。一些糟糕的系統設計往往就是試圖挽救一個基礎很差的設計，對他添加了各種表面裝飾般的補丁。
 
首先，在「沒有銀彈」一文中，作者就提出了什麼是軟體開發過程中的主要部分，什麼是軟體開發過程中的次要部分。軟體開發的痛點就在於識別並且規格化一個軟體，也就是文中所說的規格化。因為規格化的過程其實是一個明確軟體要做什麼的一個過程，規格的越詳細，造成的歧義越少，那麼軟體開發的過程也就會越順利，bug相應也會較少，同時，在軟體開發的過程中，作者提到通常情況下，我們採用的是自頂向下模組化開發，所以針對模組大小的劃分就顯得尤為重要。
 

  •構件單元調試本機調試：這個步驟的重大＂罪過＂是沒有把程式劃分成測試段，並對執行終止位置進行計劃的前提下，就粗暴地按了＂開始＂。記憶體轉儲：本機調試非常有效。快照：有選擇的轉儲､選擇性跟蹤和將快照插入程式。互動式調試測試案例
 
無論是使用何種先進的調試手段，良好的計劃都是必須的，良好的計劃是可以充分利用先進技術地有利保障，如果沒有良好的計劃,在先進的技術也是白搭。
 

  •系統整合調試系統調試的花費會比預料更長，它的困難證明了需要一種完備系統化和可計劃的方法。搭建充分的系統測試平台：測試平台指的是供調試使用的所有程式和資料。一種測試的輔助形式是偽構件：僅由介面和偽資料以及一些小的測試案例組成。微縮檔案：僅包含典型紀錄，但是涵蓋全部描述的小檔案。特例：偽檔案、輔助程式
 
測試沒有詳細的看過，完全欠缺這方面的知識。但是作者的意思大約是說，需要構建完整的測試案例，必須要避免樂觀主義態度占的主導地位，我們需要假設的是系統中會有很多的錯誤，而不是一個，並且在測試的時候需要保持有良好的日誌記錄，修改後的代碼以及之前含有bug的版本。快速對於bug進行修複是我們需要有的態度。但是，我們修改完之後對於正式版本的發布還是要有一個階段化的周期安排，而不是無序的

Chapter 14 禍起蕭牆

 

  •裡程碑還是沉重的負擔裡程碑的選擇只有一個原則，那就是必須要是具體的，特定的，可度量的事件，能夠清晰定義。裡程碑的邊界和明顯沒有歧義，比他容易被老闆核實更為重要。
 
定義裡程碑是一項很關鍵的任務，在裡程碑的選取上也需要十分講究技巧，不是選擇容易被核實的裡程碑，而是選擇容易被定義被理解被程式員接受的裡程碑，容易被老闆核實的裡程碑未必是邊界清晰的，迷糊的邊界會造成進度的誤判，有可能實際情況是無法被老闆核實的。這也是項目進度會落後的原因之一。實際上，在商業項目的開發中，如果不是因為興趣而聚集到一起的人進行的開發很有可能是無法完全準確地彙報當前的進程的。這點不管怎樣都是很難解決的問題，除非你能保證每一個組員都對於這項任務又無可比擬的熱情或是有共同的利益目標。第二就是在裡程碑的設定上，講求的應該是一個短期快速實現，不斷迭代估計設定的方法。我覺得裡程碑不應該只在項目的開始時候設定一次，或者說，項目的每個階段，甚至是每周都要明確裡程碑，這實際上也是對於項目進度的一個控制，但是不宜設定過於頻繁，過於頻繁地設定會帶來心理上的壓力。
 

  ∙“其他的部分反正會落後”並不是每一天的滯後都是災難隨著項目的推進，PERT圖為前面那個泄氣的借口，“其他部分反正會落後”提供了答案。它展示了某人為了使自己的工作遠離關鍵路徑，需要超前多少，也建議了補償其他部分失去時間的方法。
 
評價一個人的工作是不是滯後了，是不是會影響到項目整體的進度，不是單憑一個人某一天的計劃完成的狀況而制定的，而是根據項目的關鍵路徑來進行判斷的，根據這一個觀點，可以找到項目滯後的原因，也可以找到著力點來進一步提高項目在下一階段的生產效率。
 

  第一份PERT圖通常是很恐怖的
 
我們永遠無法完美的制定計劃注意，永遠無法實際上無論計劃的怎麼好最後都會出現意料之外的變遷。後面調整的PERT圖可能會更加適應本團隊在該項目上的計划進度之類，可作為進度規劃輔助參考工具之一。
 

  •地毯的下面有兩種掀開毯子把汙垢展現在老闆面前的方法，它們都必須被採用。一種是減少角色衝突和鼓勵狀態共用，另一種是猛地拉開地毯。
 
在一個大型項目中，擁有一個計劃控制小組是很有必要的，該小組首先是對於項目進度有一個控制，其次是對於未完成的部分進行一個計劃。這點很像風險評估，一個項目組中，這樣的小組存在是很有意義和必要的，尤其是大型的項目種，所有的計劃評估均有專案經理來完成的話顯然是不妥的。並且使用有經驗的人來進行這一職務的擔當更為有利。

 

  •裡程碑還是沉重的負擔裡程碑的選擇只有一個原則，那就是必須要是具體的，特定的，可度量的事件，能夠清晰定義。裡程碑的邊界和明顯沒有歧義，比他容易被老闆核實更為重要。
 
定義裡程碑是一項很關鍵的任務，在裡程碑的選取上也需要十分講究技巧，不是選擇容易被核實的裡程碑，而是選擇容易被定義被理解被程式員接受的裡程碑，容易被老闆核實的裡程碑未必是邊界清晰的，迷糊的邊界會造成進度的誤判，有可能實際情況是無法被老闆核實的。這也是項目進度會落後的原因之一。實際上，在商業項目的開發中，如果不是因為興趣而聚集到一起的人進行的開發很有可能是無法完全準確地彙報當前的進程的。這點不管怎樣都是很難解決的問題，除非你能保證每一個組員都對於這項任務又無可比擬的熱情或是有共同的利益目標。第二就是在裡程碑的設定上，講求的應該是一個短期快速實現，不斷迭代估計設定的方法。我覺得裡程碑不應該只在項目的開始時候設定一次，或者說，項目的每個階段，甚至是每周都要明確裡程碑，這實際上也是對於項目進度的一個控制，但是不宜設定過於頻繁，過於頻繁地設定會帶來心理上的壓力。
 

  ∙“其他的部分反正會落後”並不是每一天的滯後都是災難隨著項目的推進，PERT圖為前面那個泄氣的借口，“其他部分反正會落後”提供了答案。它展示了某人為了使自己的工作遠離關鍵路徑，需要超前多少，也建議了補償其他部分失去時間的方法。
 
評價一個人的工作是不是滯後了，是不是會影響到項目整體的進度，不是單憑一個人某一天的計劃完成的狀況而制定的，而是根據項目的關鍵路徑來進行判斷的，根據這一個觀點，可以找到項目滯後的原因，也可以找到著力點來進一步提高項目在下一階段的生產效率。
 

  第一份PERT圖通常是很恐怖的
 
我們永遠無法完美的制定計劃注意，永遠無法實際上無論計劃的怎麼好最後都會出現意料之外的變遷。後面調整的PERT圖可能會更加適應本團隊在該項目上的計划進度之類，可作為進度規劃輔助參考工具之一。
 

  •地毯的下面有兩種掀開毯子把汙垢展現在老闆面前的方法，它們都必須被採用。一種是減少角色衝突和鼓勵狀態共用，另一種是猛地拉開地毯。
 
在一個大型項目中，擁有一個計劃控制小組是很有必要的，該小組首先是對於項目進度有一個控制，其次是對於未完成的部分進行一個計劃。這點很像風險評估，一個項目組中，這樣的小組存在是很有意義和必要的，尤其是大型的項目種，所有的計劃評估均有專案經理來完成的話顯然是不妥的。並且使用有經驗的人來進行這一職務的擔當更為有利。

Chapter 15 另外一面

 

  •需要產生什麼樣的文檔不同使用者需要不同層級的文檔•自文檔化的程式每個資料項目包含兩個檔案都需要的所有資訊，採用指定的索引值來區別，並把它們組合到一個檔案中去。考慮到流程圖方法的落後以及進階語言占統治地位，把程式和文檔放一起顯然是合理的。
 
本章一開始提到的文檔化的方法正是我們現在常用到的文檔化的方法，包括很多模板也是這樣提供的。但是文章後半部分所提到的“代碼即文檔”的觀點，不正是當今所謂的敏捷開發所提倡的嗎？所謂的“代碼重用的意義”不僅僅在於開發時候的代碼重用，同樣的，在文檔的記載上也存在著重用這麼一說，如果注釋恰當規範，不僅僅是減少了代碼閱讀以及文檔編寫的難度，同時也提高了代碼重用的可重用度，不是嗎？從某種意義上來說，代碼如果可以構建話量產，那麼必然需要合適的說明書，就好比是組裝宜家的傢具，價廉物美不乏設計性，但是大部分的器件仍舊是通用的，軟體開發想要做到這一步，估計正常化是一個很大的難題，除非是系統計的應用開發，在一個新的軟體出現很長時間內，只要構件規範，我覺得未必是不可能的，不過，話又說回來，軟體的生命力在於不斷的革新，可不可以以後就看作是這種元器件技術的不斷革新？有沒有可能？