人月神話讀書筆記(六) (轉)

人月神話讀書筆記(六) (轉)[@more@]

第九章 削足適履

1.  的空間規模：規模是系統產品成本中如此大的一個組成部分，開發
人員必須設定規模的目標，控制規模，考慮減小規模的方法。同任何開銷一樣，規模
本身不是壞事，但不必要的規模是不可取的。

2.  對專案經理而言，規模控制既是技術工作的一部分，也是管理工作的一部分。必
須研究使用者和他們的應用，以設定將開發系統的規模。接著，把這些系統劃分成若干
部分，並設定每個部分的規模目標。由於規模--速度權衡方案的結果在很大的範圍內
變化，規模目標的設定是一件頗具技巧的事情，需要對每個可用方案有深刻的瞭解。
聰明的專案經理還會給自己預留一些空間，在工作推行時分配。

僅對核心設定規模目標是不夠的，必須把所有的方面都編入預算。

在指明模組有多大的同時，確切定義模組的功能。

培養開發人員從系統整體出發，面對使用者的態度。

3.  在速度不變的情況下，更多的功能意味著需要更多的空間。其中一個技巧是用功
能尺寸。設計人員必須決定使用者可選專案的精細程度。

4.  考慮空間--時間的折衷。對於給定的功能，空間越多，速度越快。

專案經理可以做兩件事來幫助他的團隊取得良好的空間--時間折衷。一是確保他們在
技能上得到培訓，而不僅僅是依賴他們自己掌握的知識和先前的。特別是使
用新語言或者新機器時，培訓顯得尤其重要。另一種方法是認識到程式設計需要技術積累，
需要開發很多公共單元構件。

5.  戰略上的突破常來自資料或表的重新表達--這是程式的核心所在。資料的表現形
式時程式設計的根本。

 

第十章 提綱挈領

1.  文件的跟蹤維護是專案監督和預警的機制。文件本身可以作為檢查
列表、狀態控制，也可以作為彙報的資料基礎。

2.  軟體專案文件的內容：

目標。待完成的目標、迫切需要的資源、和優先順序。

產品技術說明。

進度表。

資金預算。

工作空間分配。

人員組織。

3.  為什麼要有正式的文件

首先，書面記錄決策是必要的。人們能從令人迷惑的現象中得到清晰、確
定的決策。

第二，文件能作為同其他人溝通的渠道。專案經理的基本職責是使每個人
都向著相同的方向前進，所以他的工作主要是溝通，而不是做出決定。文
檔能極大地減輕他的負擔。

最後，文件可以作為資料基礎和檢查列表。透過週期性的回顧，他能清楚
專案所處的狀態，以及哪些需要重點進行更改和調整。

專案經理的任務是制訂計劃，並根據計劃實現。只有書面計劃是精確和可
以溝通的。透過遵循文件開展工作，專案經理能更清晰和地設定自己
的方向。

 

第十一章 未雨綢繆

1.  對於大多數專案，第一個開發的系統並不合用。可能太慢、太大，而且難以
使用，或者三者兼而有之。要解決所有的問題，除了重新開始以外，沒有其他的
辦法--即開發一個更靈巧或者更好的系統。系統的丟棄和重新設計可以一步完成
，也可以一塊塊地實現。所有大型系統的經驗都顯示，這是必須完成的步驟。
 -- 構建一個試驗性的系統，然後拋棄它。

2.  一旦認識到實驗性的系統必須被構建和丟棄，具有變更思想的重新設計不可
避免。

3.  為變化設計系統，包括細緻的模組化、可擴充套件的、精確完整的模組間接
口設計、完備的文件。另外，還可能會採用包括佇列和表技術。

最重要的措施是使用高階語言和自文件技術，以減少變更引起的錯誤。採用編譯
時的操作來整合標準說明，在很大程度上幫助了變化的調整。

變更的階段化是一種必要的技術。每個產品都應該有數字版本號，每個版本都應
該有自己的日程表和凍結日期。在此之後的變更屬於下一個版本的範疇。

4.  為變更計劃組織架構和團隊。

5.  程式維護中的一個基本問題是 -- 缺陷修復總會以(20%--50%)的機率引入新
的。整個過程是前進兩步，後退一步。作為引入新bug的一個後果，程式每條
語句的維護需要的系統測試比其他程式設計要多，成本非常高。

缺陷不能被徹底修復的原因：

首先，看上去很輕微的錯誤，似乎僅僅是區域性操作上的失敗，實際上卻是系統級
別的問題。其次，維護人員通常不是編寫程式碼的開發人員。

5.  使用能消除、至少是能指明副作用的方法，會在維護成本上有很大
的回報。設計實現的人員越少、介面越少，產生的錯誤也就越少。

6.  維護工作破壞系統的架構，增加了系統的混亂程度。隨著時間的推移，系統
變得越來越無序，無法再成為下一步進展的基礎。這時，系統的重新設計完全是
必要的。

系統是減少混亂度的過程，軟體維護是提高混亂度的過程，即使是最熟
練的軟體維護工作，也只是放緩了系統退化的程式。