有關軟體工程的資料

joel 談軟體中文版

Ian Sommerville 的software engineering

極致軟體製程 – 譯序

器書誠可貴,道書價亦高

軟體製程

軟體工程的過去很年輕,軟體工業的未來很光明,但軟體工作的現在卻很折磨人。也因此,軟體工作者,不論是第一線的程式設計師,還是運籌帷幄的專案經理人, 在業界都是出奇的缺。更驚人的是,缺額還年年擴大,我是資訊管理科系的畢業生,我們那一班從事軟體工作的,還不到一半。我想這也是國家要積極培養『本科系 以外』資訊人才的原因之一,因為如果本科系的都跑了一半,那勢必要從別的地方補些人過來,才能滿足資訊社會對資訊系統的殷切需求。

但光靠軟體大軍還不夠,除了在人數上努力,軟體開發技術的向上提升也同等重要,甚至更為重要。在這行中,1個生產力高的技術專家,可能比 20 個生產力普通的技術人員更能發揮作用。而這裡所說的技術,絕不止於程式設計而已。現在台灣的明星產業是電子業,廣大的投資人對 xx 微米、 xx 奈米製程等技術名詞,大抵都能朗朗上口,甚至侃侃而談。對於這些行業而言,製程轉換是否順利,幾乎就直接關係到獲利表現。有些企業甚至以領先國際組織所公布的製程時程為指標,以彰顯自己在同業中的競爭力。而各式的製程工程師(process engineer),更是求才廣告中的常缺。

但軟體工程師可能連自己都忘了,軟體開發也是有所謂『製程』的,那是可行性評估、需求蒐集、分析、設計、編程、測試、文件化、上線、維護等一連串的動作。但不知是這些動作缺乏一個科學定律的支撐、或時程總是太趕、預算總是太緊、人力總是太缺、還是有其它 101 種理由,這道『軟體製程』雖然沒有多少步驟,但施行起來似乎總是困難重重。

不會太久了,像 CMM 這類對軟體公司的『能力認證』成為爭取合約的一項基本前提時,軟體業的大老闆跟小員工,終究會認真看待製程的。

實踐法則

這是一本刺激的書,它披露許許多多驚人而反傳統的觀點,對正規的軟體工程最具挑戰味道的,莫過於『軟體改變成本不隨時間大幅增加』的看法。要知道,軟體最 大的敵人在於變動,甚至可以說,若能提出成功對抗變動的軟體方法,就算還稱不上是『銀製子彈』,最少也可以讓專案風險『暫時停止呼吸』好一陣了。

這也是一本不是那麼好懂的書,我曾詢問過一些『英文好的人』,也曾就書中語意不明處請教過作者 Kent Beck 先生,但疏漏或翻錯之處大概很難完全避免,這當然得全部由我負責,如果你發現我有些地方翻得很遜,或對於discipline、 practice、 scope、 story 等有不同的翻法(這四個字在中文的可能表達方式:規約、心法、專業、紀律;做法、實務、甚至我還想譯為『招數』、『步數』;規模、範圍;故事、功能情節、功能、情節、脈絡),都歡迎你 email 指教: chrita.lee@msa.hinet.net

Extreme 是『極致』的意思,Kent Beck 曾形容這是『把收音機上的旋鈕調到最大聲』,當然,他認為即使把這些做法『調到最大聲』(推展到極致),音質(軟體品質)仍能保持穩定,不會『破音』。我 曾想過的譯法有:激進製程、極端製程、極度製程、終極製程、非常製程、狂熱製程。這些譯法中,『終極製程』不但名稱響亮,也隱含有『最後方法論』的美麗憧 憬,但也就是因為如此,我不敢擴張解釋 Beck 先生的原意。雖然 Grady Booch 也曾認為 OO 會是『最後的方法論』,但我的淺見以為,軟體工程的歷史還短,在自然科學跟社會科學都還沒走到『最後』之前,我實在不敢也不想相信軟體會『後來居上』。

在『獨當一面』這本書中,唐宗漢先生把它譯為『極端程式設計法』,國內提升 OO 教育不遺餘力的高煥堂先生說是『另類製程』,軟體社群網站『點空間』的朋友們則認為『終極製程』是不錯的譯法。讀者們可相互參酌一番。

除了上述的成本觀點之外,XP 裡能稱得上是大膽的,還有搭檔編程、程式共有、四十工時、測試先行、客戶駐點這幾項『實踐法則』(practice)了。

『搭檔編程』顛覆了一般的程式設計作業,它迫使我們與別人溝通、把別人跟自己的想法看得更清楚、(可能)也加快了寫程式的速度,對新手而言(每個人都可能是某方面的新手),這更是一條學習的捷徑,學過電腦的人都知道,有人當場教,學得最快。這群倡導 XP 的人士宣稱,搭檔編程的寫程式速度較快,他們還成立了一個網站,專門探討這方面的種種。網址: http://www.pairprogramming.com

『程式共享』讓我們在寫程式時,更仔細推敲何者才是最簡單的設計,因為,每個人的程式碼都有可能被他人改掉(但介面、功能維持不變)。你的程式碼再也不能偷偷摸摸的藏身在某一個角落。這種做法的最後結果,會讓所有不清不楚的程式碼絕跡,對系統的維護有很大的助益。

『四十工時』這種『大老闆的慈悲』,應該內建成為一種工作倫理,準時下班是一種美德。畢竟,如果家庭沒有了、身體健康沒有了,就算寫出『宇宙無敵』的軟 體,大概也找不到人分享,很多書籍的作者,不都把書獻給家人嗎?我記得以前的國中公民課本曾說,古往今來的偉人,大都不追求個人的片面成就,而追求生活上 的全面成功。著名的『人生導師』柯維,也持同樣看法。這當然不應該只是偉人的權利。

『測試先行』是我認為門檻最低的 XP 實務了,先把測試程式寫好,有助於我們制訂出最直觀的物件模型,大量的測試程式雖不能使系統百分之百正確(甚至有人還認為『根本』就不能靠測試確保品質,不然 Windows 9x 的品質應該好得多),但對品質確有助益,更重要的是,作者所說的『信心』,有了測試程式做後盾,改系統時就不會投鼠忌器,這是一種程式碼的 integrity,亦即,程式碼變動時,不影響既有系統的完整性跟正確性。

至於『客戶駐點』,門檻就很高了。在客戶至上、付錢的是大爺、市場競爭等因素下,技術方的籌碼似乎不多。但我想到了 Kevin Kelly 在他那本著名的 New Rules for New Economy(中譯本為NET&TEN,大塊出版社,趙學信譯)一書所提及的『誰有最聰明的顧客,誰就能贏,因此,企業經營的訣竅在於找到顧客參與程度的極限』的看法。也想起了 Use Cases 先驅 Ivar Jacobson 在 2001 年的台灣行演講中提到的軟體開發未來四大趨勢之一『客戶的參與度將大幅提昇』。而已逝的 MIT 教授、資訊界意見領袖,邁可˙德托羅斯更在 What Will Be(中譯本為《資訊新未來》,時報出版社,羅耀宗譯)中,談到『明天的資訊科技團隊處理的資訊量,占組織總資訊活動的比率,會比今天低,因為組織中有那麼多人直接利用資訊市集做自己的事』。軟體工程專家 Edward Yourdon 亦曾提過一個大環境的問題,就是『今日的孩子們終將長大並成為明日的使用者』。今天有很多新興的網路公司,使用者的電腦素質之高,足以改寫企業 e 化的本質跟過程,他們自行利用市場現成的軟體工具,就能完成許多以往要大費周章自力開發系統才能做到的事。

今日的資訊技術進展如此之快,光靠資訊人員絕不足以生產出高品質的軟體,這一切還得靠『客戶升級』,網路瀏覽器就是一個最好的例子,這種通用的 UI,對客戶的電腦能力有著更高的要求,不是像洗衣機一樣,單鍵就可以全部搞定。

仍須努力

XP 針對的是中小型團隊和中小型專案,但世界上畢竟還有大型專案跟超大型專案,究竟這種重視人甚於重視製程的輕量級方法論,能不能跟像 RUP 那種重量級的方法論(其實 RUP 是『能屈能伸、可輕可重』的『製程框架,process framework/model』)分庭抗禮呢?

當然,尚在強褓中的 XP,還需要時間來證明它自己。

輕量級跟重量級分別代表著兩個極端(所以如果你要說 RUP 是『Extreme』亦無不可),一邊是注重人甚於製程,另一邊則是重視製程甚於人。這代表一個不甚有經驗的人,也可以照著重量級製程的種種『憲章』、 『制度』、『條文』、『守則』、『程序』、『步驟』…一步步來,優點當然是穩定,缺點當然是僵化。輕量級製程也差不多,好處是彈性,壞處是混亂。所以,取 長補短吧!導入任何製程都不免要做些修正,沒辦法全盤複製的。導入XP 時,有公式用公式,沒公式用模式,如果都沒有,那就只好用常識了。

圖書市場

國內圖書市場長期以來極缺乏這類的書,走進書店,一排排『程式技術』的書琳瑯滿目,而『做事方法』的書卻寥寥可數。如果說,一套軟體的誕生跟成長(維護與 演化),必須要有完整的製程方可竟其功的話,那我們對『前段製程』這段『胎教』期就太不重視了。我們有必要追求程式技術這種『器』跟做事方法這種『道』的 均衡發展。我不禁想說:

器書誠可貴,道書價亦高,安為銷量故,盡將道書拋?

感謝出版社給我一次機會,也給了所有軟體工作者一次機會,讓我們一起來追求這種均衡。

李潛瑞

2002年3月16日

新竹

延伸閱讀

除了談怎麼開發軟體,這本書所提及的概念,含括了複雜科學、渾沌理論、自我組織、生命演化等新興科學領域。Kent 跟一群志同道合的朋友,創立了名為『輕巧聯盟』(Agile Alliance)的組織,成員包括 Use Cases 專家 Alistair Cockburn、 UML Distilled 作者 Martin Fowler 等人,並且已經有出版品。另外,成員之一 Jim HighSmith 所寫的 Adaptive Software Development 一書,也可與本書交互參照,書中提到的『適應』概念,或可為軟體演化的指導原則。

天下文化的科學人文系列,有上述領域的一些翻譯好書。不同於以往那種『由上而下』的控制過程,XP 標榜『由下而上』的形成共識。這種全然的需求導向,也符合今日全球製造業紛紛轉型為服務業的大趨勢。其實,XP 不只是需求導向、也是風險導向、測試導向、程式師導向的方法論,但絕不是呆伯特那種『老闆導向』就是了。 :

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: