《人月神話》讀書筆記③：項目控制

九、適當控制：削足適履Ten Pounds in a Five-Pound Sack

• 規模本身不是壞事，但不必要的規模是不可取的
• 應該制定總體規模預算，且時刻清醒
• 在指明模塊有多大的同時，確切定義模塊的功能
• 架構師必須保持警覺，確保連貫的系統完整性
• 數據的表現形式是編程的根本

十、文檔資料：提綱挈領The Documentary Hypothesis

• 關鍵文檔：目標、技術說明、進度表、預算、組織結構圖、工作空間的分配
• 報價、預測、價格，這三個因素互相牽制，決定了項目的成敗
• 軟體項目的文檔：目標、內容（產品技術說明）、時間（進度）、資金預算、地點（工作空間分配）、人員（組織圖）
• 正式的文檔一是確定正確的信息、二是作為溝通渠道

十一、未雨綢繆Plan to Thorow One Away

• 一旦意識到自己的系統出現了非常大的問題，無論再艱難，也必須捨棄
• 唯一不變的就是變化本身
• 程序維護的一個基本問題：缺陷修復總是以固定（20%-50%）的幾率引入新的bug
• 更新時總是前進兩步、後退一步；更少的設計人員、更少的介面才能產生更少的錯誤
• 熵的增加是自發過程(這一點應該不用解釋了吧),而自發過程就是趨向於穩定的過程：系統軟體開發是減少混亂度（減少熵）的過程，所以它本身處於亞穩態；軟體維護是提高混亂度（增加熵）的過程，只是放緩了系統退化到非穩態的過程。

十二、改善工具：幹將莫邪Sharp Tools

• 項目經理必須考慮的工具：計算機設施（硬體&安排策略）、操作系統、語言（定義清晰的語言使用方針）、使用程序、調試輔助程序、測試用例生成工具和處理文檔的字處理系統。
• 目標機器：軟體所服務的對象，程序必須在該機器上進行最後測試
• 方針裝置：提供可靠的調試平台
• 編譯器和彙編軟體
• 程序庫與管理：必須受控；且開發庫與集成、發布可正式分離
• 互動式編程：多個級別上數據和程序的共享和保護，可延伸的庫管理，用於終端用戶之間協作的設施（生產率至少是之前的2倍）

十三、整體與部分The Whole and the Parts

• 剔除bug的設計：開始編程前一定要詳細檢查測試規格說明的完整性和明確性
• 自上而下設計、結構化編程
• 構件單元調試：本機調試、內存轉儲、快照、互動式調試、測試用例
• 系統集成調試：使用經過調試的構件單元、搭建測試平台（可以使用偽構件，或微縮文件）、控制變更（控制各個構件單元的變更或版本之間的替換）、一次添加一個構件（拒絕一次添加多個的誘惑！）、階段（量子）化、定期變更

以上內容為《人月神話》（作者：[美]小弗雷德里克·布魯克斯）的第9-13章讀書筆記及部分摘要，本人加入一定量自己的理解；因水平有限，歡迎大家交流指正，謝謝~

另：《人月神話》是比較偏技術側的書籍，翻譯過來有點佶屈聱牙，我這裡更多只是列了提綱，希望大家有機會還是自己去看、可以有更多收穫~

推薦閱讀：