我覺得凡是在開發軟體的開發者，管軟體開發的管理者，開軟體公司的老闆，都可以從這本書裡獲益；總括來說，開發軟體跟開發軟體系統，是完全不同的問題，前者是技術，關係的是個人工程師的熟練度；後者卻是管理，關係的是一群工程師如何溝通。
簡單的軟體大部分的軟體工程師都能寫出來，但，軟體系統需要在不同平台上測試過、需要完整的文件說明、需要讓內藏的錯誤儘可能的被找出來，這當中的工夫是以倍數在算的；如果算上每個工程師間的溝通成本，缺乏管理能讓大型團隊一事無成，這也是本書名的來由：「人月」並不是衡量軟體系統開發難度的好指標，我們都知道一個工程師寫一個月和三十個工程師寫一天，所能得到的東西是完全不一樣的。
每一章，作者都針對一個軟體系統開發的管理要訣進行說明：如何組成有效率的團隊、架構設計師的重要、團隊要如何溝通、文件怎麼管理……。可以算是作者在大型系統開發打滾多年之後總結出來的武功祕籍，一步步讀來，除了吸取作者字字珠璣的告誡，也讚嘆作者在那電腦還是珍貴資源的年代，就能完成如此大型的系統開發，網路上也有不少人整理出書中的重點，可見Heresy blog，有第一到十二章的整理（我也很好奇為啥十二章之後就沒整理了lol）：
https://kheresy.wordpress.com/2011/03/22/the_mathical_man_month_p1/
https://kheresy.wordpress.com/2011/03/25/the_mathical_man_month_p2/
https://kheresy.wordpress.com/2011/04/01/the_mathical_man_month_p3/
本書的第十六章是一個頗具話題性的章節：沒有銀彈
這裡的銀彈不是指金錢，而是指在對付可怕的狼人(軟體系統專案)時，大家總希望可以出現神奇的銀彈可以讓狼人一槍斃命，但作者認為：沒有，這世界上就是沒有銀彈，沒有任何突破能讓軟體系統的生產力大幅提升一個數量級；想要弄好一個軟體系統，好好規劃、實行才是正途
作者的論點是，因為軟體就是如此複雜的工作，現在的進步例如引入高階語言、物件導向、分時(time-sharing)、人工智慧等等，都只是處理軟體附屬上的困難，沒有直指本質的複雜核心，當附屬的困難被解決了，本質的困難仍未解決，人們在創作、溝通、理解軟體上，仍然有著無法解決的本質困難，而附屬困難並佔不到軟體開發的9/10以上。
詳細內容可見：
http://zh.wikipedia.org/wiki/%E6%B2%A1%E6%9C%89%E9%93%B6%E5%BC%B9
我個人的看法是沒這麼悲觀，以十年來看，軟體開發也許沒有十倍進步，但長久看下來，我們的軟體生產力仍然進步神速。
現今的高階語言，也許可以用C++的standard library 為濫觴，為常用的複雜架構定下一個標準，現在要寫出複雜結構的程式碼遠比過去容易，也更不容易出錯；安全、多執行緒方面，新一代的高階語言如AZ大神推薦的Golang，最近在研究的Rust等，都針對這方面進行了補強。直譯式語言讓原型(prototype)建立更容易，展示程式概念也更加輕鬆寫意，在各種平台上也能有同樣的表現。
對測試、自動化產生code 都有更好的支援，servo用python 去剖析規格文件，自動產生出幾萬行的程式碼；網路提供的服務，例如issue tracker, git, CI測試、文件控管，林林總總的服務，程式碼的生產、測試、管控遠比過去強大得多。
十年也許太短，把「沒有銀彈」的尺度拉開，軟體本質的複雜性問題仍然被解決中，隨著軟體解決問題的能力不斷上升，我個人樂觀的覺得，我們生產軟體系統的生產力，仍然有超過一個數量級的提升。
－－
引用本書開頭的一段文字，大意是這樣的：雖然程式設計師很辛苦，要不斷在軟體系統的焦油坑裡掙扎，永遠解不完的bugs，被客戶刁難，被上司責怪；但軟體還是有光明的一面，把腦中想像的東西實作出來的成就，解決問題的快意。儘管走在軟體的路上有苦有樂，總的來說，樂趣還是多於苦難。
儘管前途崎嶇，崎嶇的路上，我們還是會笑著走過去。
一本讓我頗有共鳴的書，推薦給所有正在焦油坑裡掙扎的軟體開發者們(喂)。
沒有留言:
張貼留言