---
# System prepended metadata

title: 人月神話：Chapter 9-12
tags: [讀書會筆記]

---

###### tags: `讀書會筆記`
# 人月神話：Chapter 9-12

# 第九章  地盡其利，物盡其用
* 空間就是金錢
    * 程式執行時所耗用的記憶體空間是要付出代價的
* 程式大小的控制
    * 必須做好整體空間規劃：包含常駐空間規劃、存取規劃、發展節省空間的技術
    * 先精確定義出模組該做的事，再規定模組的大小
    * 系統架構設計師必須持續保證系統整體性；引導成員注重系統的整體觀&使用者導向是軟體管理者的重要職責
* 節省空間的技術
    * 功能&空間取捨：設計者需決定功能給使用者的彈性程度
    * 空間&時間取捨：可用的空間越多，執行的速度快
        * (1)開發團隊必須在程式設計的技術上受過訓練
        * (2)需具備標準組件的程式庫，程式庫裡的每一個組件都應該包含兩套程式碼，執行速度最快、使用空間最少的
* 資料的呈現方式是程式設計的本質
    * 重新思考資料結構，資料的呈現方式是設計的本質

**討論議題**
1. 是否有上線到特定系統，模型太大需要縮減的狀況？


# 第10章 文件假說
* 成堆的書面資料中，有一小部分關鍵性文件紀錄著任何專案管理的核心工作，這些文件是身為管理者最重要的工具
    * 準備文件是為了讓思考集中、討論言之有物
    * 提供一個運作監督和預警機制
    * 可當作是提供工作報告的資料庫
* 規劃電腦產品的文件
    * 目標、規格、時程、預算、組織編制圖、場地配置、預估預測定價
* 規劃軟體開發專案的文件
    * 做什麼：目標
    * 做什麼：產品規格
    * 何時做：時程
    * 多少錢：預算
    * 哪裡做：場地配置
    * 由誰做：組織編制圖

* 為什麼要有正式文件
    * 記錄決策，遺漏和矛盾之處才會顯露出來，並能引導更多細節決定，以理出清晰而明確的政策。
    * 傳達決策給他人，確保組織中每個人朝同一個方向前進
    * 定時審視確認目前位置，哪裡方向走偏、需修正

**討論議題**
1.	對開發人員來說，什麼樣的規格文件是好的？什麼樣的文件是不好的？
2.	規格文件如何產生？PM是否有跟開發人員討論過規格文件的寫法？
3.	是否遇過不按照規格開發的開發人員？他為什麼不按照規格開發？後來如何解決這個問題？


# 第11章 失敗為成功之母
* 先導試驗工廠與擴大規模
    * 化學反應量產：實驗室成功 -> 先導試驗工廠，獲取經驗 -> 擴大規模
    * 把必然的一次性失敗納入正式計畫之中
* 唯一不變的就是變
    * 軟體產品是無形的，加上易於操控的特性，使得開發人員必須面臨需求上無窮無盡的改變
    * 客戶在目標和需求上的種種改變，定義出一個底線是必須的，且隨著專案進行，這項限制應該要越來越嚴格
* 使系統利於改變
    * 小心地模組化、善用副程式、為模組之間定義出明確而完整的介面，並寫出完整的文件、使用標準呼叫程序和表格驅動技術
    * 運用高階語言、自我說明技術，減少因改變而造成的錯誤
    * 產品編號版本，每個版本擁有自己的時程與凍結日期
* 使組織利於改變
    * 設計人員設計決策是暫時性的，不願意寫成文件，可能受到質疑
* 進兩步，退一步
    * 軟體維護：主要為修正設計錯誤、新增功能
    * 維護一個廣為使用的軟體，需付出開發成本40%代價
    * 軟體使用者越多，發現的錯誤越多，維護成本越高
    * 因修正錯誤而導致其他錯誤的可能性相當高(20~50%)，針對局部錯誤修正實際可能牽連甚廣、維護人非程式碼原作者
    * 每次修復應做迴歸測試，成本高
    * 避免方式：文件說明變動將造成的影響範圍與副作用、較少人較少介面
* 進一步，退一步
    * 軟體維護是複雜化且逐漸趨於混亂的過程
    * 終究會被修改得面目全非，不再適合用來作為改版的基礎

**議題討論**
1. 你認為需求變更是否可能避免？如果重來一次，會如何調整以減少需求變更？
2. 是否遇過需求變更太頻繁或改動太大，造成開發人員不願調整情況？如何跟開發人員溝通？


# 第12章 神兵利器
* 統一開發維護通用的軟體工具，顯然是比較有效率的做法
    * 個人化的工具隊溝通無異，而且會阻礙溝通
    * 搭配的技術會跟著改變，所以工具的生命週期會很短暫
* 擴大共用工具小組的編制，如此就會得到最佳的效率，實際上並非如此
* 仍有特殊化工具的需要，每個團隊都應該配置一位工具專家
    * 電腦設備：作業系統、語言、工具程式、除錯補助軟體、測試案例產生器
* 目標機器
    * 目標機器的種類
        * 機器配備、操作員、系統程式設計師
        * 維護機器的標準支援在最新且可用狀態
        * 記憶體、磁碟
        * 縮減程式佔據記憶體空間：重疊技術、空間削減
        * 偵錯機制：記憶體使用模式
    * 安排上機時間
        * 固定各小組上機時間

* 工具機器與資料維護
    * 模擬器
        * 採用成熟的工具機器來當作可靠的模擬器，減少除錯變因
    * 程式庫與程式的管制
        * 開發程式副本、測試案例、組件測試鷹架@局部自由區域 > 系統測試、偵錯、除錯@系統整合子程式庫 > 可與其他模組整合&測試@現行版本子程式庫
        * 控管:狀態、去向、異動追蹤
        * 程式整合與交付從局部自由區正式隔離與演進

    * 程式編寫工具
        * 儲存備份
    * 文件編寫系統
    * 效能模擬器
    
* 高階語言和交談式程式撰寫
    * 採用高階語言不只可以提高生產力，還可以提高除錯速度，錯誤會比較少，也比較容易找到錯誤
    * 以交談式工具來編寫軟體程式，至少會得到兩倍生產力的效果

**議題討論**
1. 大家是否有推薦幫助專案管理的工具？

