2004年11月18日 星期四

《人月神話》讀後心得

分享

書名:人月神話:軟體專案管理之道 (The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition))
譯者:錢一一
ISBN:9867889185
出版商:農學社
出版日期:2004-04-01
頁數:405

  最近把這本書看完,此書的作者Frederick P. Brooks曾在IBM任職時擔任過超過一千人的專案主導人,而書裡的內容正是作者在專案結束後所獲得的經驗跟反思。

  對於急於知曉書中精要的人,可以把前序跟後記看完,有個概觀後,直接跳讀第18章「《人月神話》的主張:是真是假?」,再依序閱讀16章「沒有銀彈:軟體工程的本質性與附屬性工作」,17章「再論『沒有銀彈』」,19章「《人月神話》二十年」。

  第一章中作者對程式、軟體系統、軟體產品、軟體系統產品的定義與區分,對我來說是一個衝擊。

  程式:本身是完整的,寫這個程式的人可以在開發系統上執行它……也就是個別的程式設計師用以評估生產力的東西。

  軟體產品:可以讓任何人執行、測試、修改和擴充的程式,並且適用於多種操作環境,以及不同情況的資料。……必須以通用的風格來編寫,特別是輸入資料的範圍與形式……程式必須經過徹底的測試……一個程式要晉升為軟體產品,還必須有完整的文件,以指引別人使用、修改或擴充它。

  軟體系統:彼此交互運作的一組程式集合,程式之間有律定共同的資料格式與合作模式……。

  軟體系統產品:不同於以上所述的簡單程式……但卻是真正有用的,也是大部分軟體工程企圖要做出來的東西。

  關於如何要求工程師寫程式文件,作者在第15章「一體兩面」中提到:

  多年來,我一直辛勤地工作,並在軟體工程的課堂上強調好文件的必要性,但即使一再地諄諄教誨,卻還是沒用。我假設學生們其實已經學會了如何寫好文件,只是缺乏寫文件的動力,所以我嘗試……親自上場展現文件怎麼寫,這下子效果就好多了。

  書中227頁便展示了一段程式,並說明作者如何在程式中寫註解。這樣的方式,很明顯的比單獨列出原則清晰許多。

  所謂的「人月神話」是當專案進度落後時,試圖招募更多的人手來解決落後的進度,反而會招致反效果。原因是必須有原專案成員訓練新進人員,訓練完成前,能工作的人力反而減少;當新進人員訓練完成後,原有工作的重新分配及成員之間的溝通變得更加不易,也會拖延專案的進行(作者強調專案架構概念的一致性對於系統的穩定及建構非常重要,而新進人員可能無法維持架構概念的一致性)。另外,有些專案系統的建構工作是連續性不可切割的,也使人手的增多無助於追趕進度。

  專案人員之間有良好溝通的重要性也在於要維持系統架構的一致,但本書作者與《The Art of Designing Embedded Systems》的作者Jack Ganssle都強調,根據研究,安靜不受打擾的工作環境對提昇工作效率有極大的幫助。

  作者認為在開始寫程式之前,將規格、介面先仔細考慮訂定,並寫成文件,可以藉由文件溝通,讓成員清楚架構概念。另外,為了避免概念不一致,作者建議專案的架構設計以集權的方式來進行。

  系統建置的時候,每一個模組都應先測試,並解決所發現的錯誤後才可以加入系統中。模組加入系統中後,需再做測試,以確定系統的穩定及模組間的正常運作。作者建議系統的建置採模組功能漸增的方式來進行,維持一個持續可穩定運行的系統,才不至於在時程快要結束時,既無法完成所有功能,也不能建立可運行的系統。

  在《The Art of Designing Embedded Systems》中所提到的code review的進行方式,我認為可以輔助達到「人月神話」作者所提到上述原則。透過code review,實作人員可以對系統的其他架構更加瞭解,減少程式的錯誤,增加程式的可讀性,並同時知道其他人寫了哪些函式,以後若有需要可加以利用(這增加了程式的再利用)。


相關文章:
  你是雲雀(lark)、貓頭鷹(owl),還是蜂鳥(hummingbird)?
  熬夜加班(唸書)有多沒效率?
  劣幣驅逐良幣的加班文化
  別搞錯了,Google的「打盹艙nap pods」可不是員工福利
  松下幸之助談工作
  樵夫
  學習新解:多元智能理論心理學家的看法
  《大腦當家:靈活用腦12守則,學習工作更上層樓》(Brain Rules)
  傑克‧威爾許(Jack Welch)檢驗策略的5張投影片
  為顧客創造價值

0 意見: