作者  fcamel (飛啊!起舞的小駱駝)  看板   P_fcamel
 標題  [SE]   Book ~ 人月神話, note 1
 時間  Fri Aug 20 20:03:48 2004


人月神話 (The Mythical Man-Month) 確實是本易讀有料的好書,
也值得這樣仔細地探索它的內容, 但若沒寫個專案玩玩,
看這書應該是很索然無味的

我將陸續把看的心得和摘要寫出來


導讀: (by 曾昭屏) 軟工是跨領域的, 包含傳統寫, 測程式, 還有管理學, 經濟學, ... ch1 任何一個programmer都會相信車庫裡的兩個小伙子以驚人的速度開發程式, 並有重大突破, 但這和真正的軟體有很大的出入 fig1.1: 程式 -> 軟體系統(介面, 系統整合) 需要3倍開發程式的時間 程式 -> 軟體產品(通用, 測試, 文件, 可維護) 需要3倍開發程式的時間 軟體系統產品: 需要9倍以上的開發時間 [NOTE] 和我寫小工具的心得差不多, 自己用爽的話, 一下就完成了, 後續寫文件和檢查錯誤操作, 反而花了coding 3倍的時間 新技術和舊產品迷思: 既然一個軟體的開發是如此的慢, 當它完成時, 已趕不上新的技術, 市場何在? "The real tiger is never a match for th paper one." 新的技術要實現在新的軟體裡, 又是另一個緩慢週期的開始, 不用擔心 ch2 "隱藏在軟體專案時程下的第一個錯誤假設就是一切都會進行得很順利" 在餐館, 廚師可以為了味道堅持慢出餐, 但在軟體界卻不行, 客戶總是要求準時拿到成品, 使得品質低落, bug一堆, 維護困難 man-month可以用來評估開發的前提是 --- 工作可以切分, 不需要溝通, "生小孩就是需要9個月, 你叫多少個媽一起生都一樣, 軟體工程就是像這樣的工作" 軟體創作本質屬系統性工作, 需要複雜的交互關係, 所以溝通成本很高, component debuggin & system test因連續性而被影響最徹底 Brooks的時程經驗法則: 1/3 規劃 1/6 寫程式 1/4 組件測試和早期系統測試 1/4 系統測試, 完成所有組件 軟體專案不順的主因: 缺乏良好的時程規劃 [NOTE] 溝通是不可免的, 而且是破除"人月神話"的原因, 投入再多人力, 也不會提升速度, 反而因溝通而降低生產力 "如何避免不必要的溝通"卻是我每次合作後的心得, 看來這個思考方向是錯的 (見後文) 事前排定測試時間, 可以提高品質, 避免進度落後時, 無法把測試列入考量 ( Brooks的這些心得是30年前的產物, 和新穎的XP, 有些吻合 ) 排程不對, 是secondary cost的主因 ( 而我總是沒有定排程, 沒有經驗, 不會評估 ) ch3 精英策略無法用在大型專案, 再怎麼強的小團隊, 仍需過久的時間開發大型專案 主從架構: 主設計不分開, 由少數人主導 溝通降低 專業分工 已證實可行, 生產力高, 可用在大型專案(分成許多"外科手術團隊") [NOTE] 針對前章man-month的迷思, 和溝通是效率瓶頸但又不可避免, 提出折衷解決方案, 但引出"民主和專制"的爭議點 注意, "外科手術團隊"裡, 只由一兩人主導, 其它人是協助, 他們的意見, 主導者可以完全不理會 我過去的合作經驗, 全部是平等地位, 沒有leader, 這樣的合作模式, 大概是高中營運社團的後遺症, 那時我們一共3, 4人, 類似內閣制運作, 我覺得很棒 但後來程式開發的合作, 卻因此浪費一半的開發時間在討論"main程式怎麼寫?" 而且那時, 我沒有想過測試的問題, 以為測試很簡單, 程式寫得好, 測試就容易, 甚至認為除錯是不必要的時間, 盡力把main寫好, 後續這些時間可以盡量減少 ch4 Reims大教堂以整體合諧性為第一標目, 捨棄個人主設計的趣味, 八代建築師都維持不變, 而使它更為出名 軟工不像蓋教堂, 但概念不一而造成的問題, 比蓋教堂更糟 Brooks的主張: "系統設計時, 保有conceptual integrity是最重要的原則" ( 呼應"外科手術團隊"的組織 ) 以鐘為例, 架構是"鐘面, 指針, 發條旋鈕", 小孩子學會鐘的架構後, 不論由手錶或教堂高塔的鐘, 他都看得懂 ( 而兩者的實作方式不同 ) architecture/implemantation分工: 由少數人制定architecture, 交由另一組人implement 若許多重要構想和conceptual integrity衝突 -> 重作, 或改變conceptual integrity Form is liberating (形式就是解放): 沒有限制的實作小組, 會引發很多和架構相關想法或爭論, 而沒有關注真正的實作 ex: R. W. Conway開發PL/I的compiler PL/C, 最後放棄和語言相關的更改, 他們了爭論語言本身的不同意見, 耗掉了所有精力 ( 別忘了他們原意是要作compiler ) 架構設計小組由少數人組成, 實作人員可能的反對理由: 規格過於功能性, 沒有有反映成本 實作人員無創意空間 制定規格時, 實作人員沒事作 實作仍需創意, 而且少了與實作無關的思考, 更有發揮空間而不會偏離主題, 制定規格時別成立實作小組, 他們就不會沒事作了 設計, 實作, 實現的垂直分工, 大幅減輕水平分工的負擔, 簡化溝通, 增進conceptual integrity. [NOTE] 強週conceptual integrity(書中譯為"概念整體性"), 世界第一大企業GE的前總裁"威爾許"有著類似想法, 他把員工按照"工作表現好壞"和"認同公司理念與否"分成四種人, 工作表現好但不認同公司理念的人, 會造成公司細部瓦解, 反而應該請他走路, 總之, 理念不合就走路, 不論能力 architecture/implemantation分工是否會使impl.小組無法發揮創意? 沒有相關經驗, 這部份沒有心得, 從名詞上直觀來看, 很少人想當impl.小組的人吧? 或許後續討論是用來騙impl.小組捨棄小我, 專心當螺絲釘吧? [ to be continued ]