作者  fcamel (飛啊!起舞的小駱駝)  看板   P_fcamel
 標題  [SE]   Book ~ 人月神話, note 5 (end)
 時間  Sat Sep 25 02:55:08 2004


ch19重點滿多的, 有些是現今時代普遍存在的現象, 大家都知道的觀念,
我只挑幾點小記一下

ch19 The Mythical Man-Month after 20 Years <人月神話>的重點是人與團隊, 也因此這本書的讀者群不限軟工領域, 包含各種族群 * 概念整體性(conceptual integrity)和架構設計師(architect) 讓使用者感覺其概念前後連慣是好軟體必備的條件, 小專案和大專案差別點之一就在這裡, 集結大量人手, 又得使感覺有一致性, 英雄式管理是必要的 [NOTE] 我很滿意MS一貫的介面和順手的操作 將架獨立於實作(implementation)和實現(realization)之外 Brooks超過20次的軟工實驗課中, 堅持四個學生的小團隊裡選出一位經理 和一位獨立的架構設計師, 為團隊界定個別角色, 這樣的做法運作得很好, 有利於做出成功的設計 [NOTE] 架構獨立於實作, 或是英雄式管理在落實上或許有很多麻煩, 誰都不想當別人的輪子, 想做含有自己想法的事, 雖然Brooks在初期幾章(my note 1)強調過"Form is liberating", 以及相關論點來表示實作的一方不是無趣的輪子, 但是我還是覺得沒有如同公司階層之類的強制力, 很難落實這個體制 * 2nd System Effect: 過度設計與頻率猜測 功能過度膨脹 為了滿足廣大使用者, 也為了使用便利性, 一開始總想塞進各種特色, 使用便利性則在特色增加過程中喪失, 手冊也愈來愈厚 [NOTE] 以Instruction Set Architecture來看待所謂的"便利功能", 是不錯的例子, IA-32是CISC, 一堆莫明奇妙又用不太到的指令, 使Intel一年年地背著這些包袱; 不止一個領域會牽扯到"便利性功能"造成不便的議題, 寫API時, 提供了不當的exported API, 往後就必須負擔維護成本, 那怕那是個差勁又只有兩三人用的功能, 都無法輕易宣示不向下相容, Effective Java這本書相當計較field, method是否被不當地export給使用者, 和這是同樣的考量點, 這方面的討論有太多可以談了, 總之, 不要輕易抱有 "加這個小功能, 不用多少成本, 讓使用者多一點方便, 何樂不為?" 實際的成本是超乎想像的高, 包含維護, 阻礙新的功能開發 定義使用群: Who they are? What they need? What they think they need? What they want? 頻率: 調查使用者需求是既花成本又令人半信半疑的事, architect必須去猜, 錯誤而明確的猜測也遠比模糊不清要好 * 漸進式開發模式 --- 逐步細分精製 隨時有一個可運行的系統 可早期進行使用者測試 有多少錢做多少事 可提高士氣 * 軟體組合的單位? 堆砌程式的概念單位遠大於單一高階語言的敘述, 副程式, 模組和類別, 若設計和建構時只要把做過的東西加以設定組合, 就可以大幅提升概念層次 OOP在這方面有很大的貢獻 [NOTE] Web Service符合Brooks的理念, 它可說是軟體組合的更大單位, 軟體和軟體之間直接整合, 跨越OS, 跨網路, 並且, Web Service也符合Brooks針對提高軟體開發的另一大觀點, "不要自己寫, 用現成的" Brooks Law的修正: 對落後的專案增加人手"未必"使專案拖更久, 但成本必然更多 早期加入額外人力遠比後期加入還安全, 新加入的人總會有立即負面影響, 需要幾週的時間才能補回來 [ end ]