作者  fcamel (飛啊!起舞的小駱駝)  看板   P_fcamel
 標題  [SE]   Book ~ 人月神話, note 2
 時間  Mon Aug 30 22:13:14 2004


人月神話裡有些經驗不能一味地套入現行情況, 但不代表這些經驗已不適用,
要思考作者的處境和背後的理由, 我認為思索這些,
並與現在的環境分析比較, 會有不錯的體悟


ch5 2nd-system effect 第一個設計總是慎重而簡單的, 第二個系統卻很糟, 容易overdesign 可能犯的錯誤: 和現有系統基本假設不符, 卻想延用經驗 當時的技術已過時, 在第二個系統裡應該引進新的技術 [NOTE] 我在寫php時, 很喜歡套用過去經驗(因為我不熟php, 想省工), 犯了許多次2nd-system effect, 最後我把討論區刪了, 在php裡減少一些include(), 以避免我犯更大的錯誤 (那個討論區用了3次, 但它卻是我一次寫php硬趕弄出來的劣質品) ch6 1. 手冊由架構設計師寫, 架構設計師要提供一種實作方式, 而不是特定的實作方式 [NOTE] 雖然沒有明說, 這表示架構設計師也要懂得實作 手冊的用途是詳細告知規範和未規範的內容 ( ex: 傳遞C的函式參數, 在執行上的順序是未定義的, 不可依懶它 ) 2. 正式定義並帶有散文定義的解釋文件是最理想的, 兩者要並存, 並且以其中一者為主, 以免解釋衝突造成混亂 [NOTE] 原本我覺得有個正式定義, 再加解釋實在很蠢, 為何不一次解釋清楚, 搞一堆專有名詞自找麻煩 而作者的意思是, 兩者都有存在的必要, 並舉出正式定義的優點, 精確, 具週延性, 但不易看懂 3. 要有獨立測試的小組 ch7 人力配置和專業分工是減少溝通的方法, 權力和責任造成樹狀組織, 但溝通是網狀的, 兩者衝突 視人力調配組織, 而非由人去配合純屬理論的組織 ch8 討論和評估程式產值的數據 ( 沒有概念, 這種評估有準確度嗎? ) ch9 省空間的一些技巧 (現在沒有必要了) 各小組的開發往往造就局部最佳化, 忽略整體最佳化 ( 惡性競爭 ) [NOTE] 早期MicroSoft內部就是如此? Windows 3.1跨到NT是很艱辛浪費資源的過程, 而Office強調Word和Excel的互通原件則是正面的例子 ch10 管理員要把目標和其它重大事項寫下, 別預期講過一次後, 大家都會懂, 即是你認為那是非常簡單的事 ch11 丟掉重作是必然的, 不用擔心是否要作試作品, 設個底限, 坦然面對改變, 愈接近完成, 底限愈嚴格, 否則不可能完成 [NOTE] 我和別人合作時, 總是為了要不要先作個prototype(試作品), 再重作而爭論許久, 因為prototype會占時間, 若可以一次作好最省事 作者以他豐富的經驗點破這簡單的道理, 其實大家都知道, 就作吧, 不成功就當它是試作品, 再重來吧 ch12 每個團隊都應該有個工具專家, 個人專用工具會阻礙溝通, 軟體工具統一開發和維護較有效率, 個人特殊需求可以向工具專家請教 如同觀察星象要在晚上, 天亮前進行除錯是最好的, 雖然沒有理論站得住腳, 但作者的經驗顯示, 一大早起來除錯是很有效率的 ( ????????????????????????????????????????????????????????????) ch13 top-down design is good. 一次整合一個組件 版本控管很重要 反對非常少而頻繁的改版, 這會造成混亂 [NOTE] 版本的演進意謂整體測試, 測試的成本很高, 在制定時程時, 要把改版的整體重測列入 在XP的前提下, 測試的成本很小, 簡言之 +> 最小需求 -> 實作 -> 自動化測試 -> 重整 -+ | | +<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+ 換句話說, 當測試成本不能最小化時, XP的作法可能不適用, 比方目標平台不是PC, 團隊只能拿到少數幾台, 或是測試動作極為費時, 可能編譯和執行都要很多時間, 雖然這在現今不太可能發生 ch14 milestone是具體100%完成的事件 (非80%完成, 90% no bug這類模稜兩可的描述) 靠經驗事先評估加入時程 不是每個誕誤都要緊張地處理, 如何找出該關心的延誤? PERT chart, critical-path schedule是無可取代的工具 ( 它們是什麼啊...??????????? ) 2個該讓老闆知道的訊息, 別動不動就煩他 意外狀況 計畫執行現況 大型專案最好設立一個 1~3 人的計畫監控小組, 這樣老闆才能完全專心在決策 ch15 流程圖是不必要的, 若需要, 一頁已足夠 ( 指程式邏輯細部的flowchar, 整體架構用適當的圖表會易於討論 ) 文件盡可能放在同一份, 寫在程式裡最理想, 稱為self-document ( javadoc is good!! ) 另外寫文件配上流程圖很蠢 軟體文件通常寫得很爛 維護麻煩, 程式的修改往往不會立反應在文件裡 [ to be continued ]