作者  fcamel (飛啊!起舞的小駱駝)  看板   P_fcamel
 標題  [SE]   Book ~ 人月神話, note 4
 時間  Sat Sep 18 14:44:18 2004


針對上篇<沒有銀彈>的後續觀點, Brooks針對許多人的來信做分析和評論,
個人認為, 單單看過<沒有銀彈>和沒看過差不多,
一定要連著這篇一起看, 才能有所體會, 兩篇都很長就是了...

ch16 "No Silver bullet" Refired 本篇於1995年所寫 Cox(提出軟體IC的人)指出採取可再利用, 可替換組件的方式可解決部份本質性問題, 但本質性困難源自軟體概念上的複雜性, 非開發軟體方法的困難 ( reuse組件是軟體開發的方法 ) 系統複雜性是由無數個分別必須精確定義的小細節所組成的函數, 集合眾人智慧這種非協調性的工作, 必須有足夠的一玫性才能用一般性規則 加以精確地描述, 而這看來是極不可能的事 * <沒有銀彈>的論點很悲觀? Brooks:"我經常都是太過樂觀多於太過悲觀, 我畢竟是程式設計師的背景, 而樂觀正是我們這行的職業病" 再次強調, <沒有銀彈>表示不會有捷徑, 各種創新發展已成熟並充份發揮, 將共同達到數量級的成長 * 生產力的情形 相對於量身訂作的軟體, 大眾市場發展絕對是軟工最長遠的趨勢, 套裝軟體成為開發主流, 大家用買的, 不用自己做 美國管理系統公司董事長Ivan Selin於1987年寫信給Brooks提供套裝軟體相關的觀點: 使用者認為的套裝軟體應該不只是更通用, 同時更能輕易自訂特性, 這才能說服使用者使用套裝軟體, 在他的公司裡, 絕大部份不懂軟體的使用者很非拆使用套裝軟體, 他們認為喪失了某些必備的特色和功能, 所以輕易客製化對他們來說是很大的賣點 Brooks承認Ivan Selin的觀點是對的, 他低估了套裝軟體可客制化的程度和重要性 * OOP --- 這顆銅彈行嗎? 以OOP的精神來看, 極為符合堆積木完成軟體的哲學, 模組化, 簡潔的介面, 可再利用, ... 為什麼OOP成長如此緩慢? David Parnas寫信給Brooks的觀點: 因為OO已和各種不同複雜語言混在一起, 應該要教大家OO是設計的類型, 並告知設計的原則才對, 但大家卻把OO視為特殊工具的運用, 是否能寫出好程式和使用工具無關, 除非我們教大家如何設計, 否則這些語言發揮的效用很有限, 大家用這些語言做出爛設計, 得不到好處, 假設好處很少, 那它就流行不起來 [NOTE] 我極為同意OO是觀念, 原則, 而非工具, 若把OO定位搞錯, 當然無法發揮OO的好處, 排斥OO; "寫出好程式和使用工具無關"這點我持相反意見, 常在論譠看到很多人這麼說, 甚至提出"高手用C也能寫出很OO的東西, 菜鳥用OOPL也寫不出OO的東西", 問題是, 高手很少, 而且高手用C寫出的OO, 一般人體會的程度呢? 本質就不是OOPL的語言, 硬要拿來做OO, 效果有限, 也要處理很多不必要的工作 Brooks對OO的看法: 投資集中在前期, 回收集中在後期 Coggins: OO不會使第一個專案開發變快, 下一個也不會, 同類型的第五個才會 這種後期才能回收的模式使得管理者需要勇氣, 使得OO難以推廣 * 再利用的情形呢? JPL的Van Snyder的觀點: 我們推測, 軟體再用的障礙不在寫, 而是用, 假如軟體工程師認知到去找一個能滿足需求的組件, 其代價比重寫高, 可以確定, 重複性的組件會被做出來, 注意, 這裡指的是"認知", 換句話說, 這和實際重制成本沒有關係 軟體再利用在數學軟體上能很成功地運用, 原因有兩個: 1. 它很難懂, 每行程式都要傷很多腦筋想才寫得出來 2. 有一套豐富而標準的數學專業術語可描述每個組件 所以, 重制一個數學軟體組件的成本相當高, 成現成組件找到某個功能的成本相當低, 專業期刊都會發表並蒐集演算法, 以合理的成本提供出來, 做為商業用途則提供更高品質, 成本高些, 但仍很合理, 其它領域可能無法精確扼要地界定出一個人的需要, 這些因素共同造就數學軟體再利用的吸引力, 而非重制 [NOTE] 我完全同意Van Snyder的觀點, 太精闢了 另外, 設計再用元件說來容易做來難, 不只要有好的設計, 也要有好的文件, Brooks估計開發成本要3倍左右 [ to be continued ]