2015年2月27日 星期五

人月神話

這本書其實有點老舊了,舉的例子都老到不行,不過讀起來還是覺得相當中肯。

我覺得凡是在開發軟體的開發者,管軟體開發的管理者,開軟體公司的老闆,都可以從這本書裡獲益;總括來說,開發軟體跟開發軟體系統,是完全不同的問題,前者是技術,關係的是個人工程師的熟練度;後者卻是管理,關係的是一群工程師如何溝通。

簡單的軟體大部分的軟體工程師都能寫出來,但,軟體系統需要在不同平台上測試過、需要完整的文件說明、需要讓內藏的錯誤儘可能的被找出來,這當中的工夫是以倍數在算的;如果算上每個工程師間的溝通成本,缺乏管理能讓大型團隊一事無成,這也是本書名的來由:「人月」並不是衡量軟體系統開發難度的好指標,我們都知道一個工程師寫一個月和三十個工程師寫一天,所能得到的東西是完全不一樣的。

每一章,作者都針對一個軟體系統開發的管理要訣進行說明:如何組成有效率的團隊、架構設計師的重要、團隊要如何溝通、文件怎麼管理……。可以算是作者在大型系統開發打滾多年之後總結出來的武功祕籍,一步步讀來,除了吸取作者字字珠璣的告誡,也讚嘆作者在那電腦還是珍貴資源的年代,就能完成如此大型的系統開發,網路上也有不少人整理出書中的重點,可見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,被客戶刁難,被上司責怪;但軟體還是有光明的一面,把腦中想像的東西實作出來的成就,解決問題的快意。儘管走在軟體的路上有苦有樂,總的來說,樂趣還是多於苦難。

儘管前途崎嶇,崎嶇的路上,我們還是會笑著走過去。

一本讓我頗有共鳴的書,推薦給所有正在焦油坑裡掙扎的軟體開發者們(喂)。

沒有留言:

張貼留言