譯序

器書誠可貴,道書價亦高

 

 

軟體製程

 

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

 

但光靠軟體大軍還不夠,除了在人的數量上努力,軟體開發技術的向上提升也同等重要,甚至更為重要。在這行中,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不只是需求導向、也是風險導向、測試導向、程式師導向的方法論,但絕不是呆伯特那種『老闆導向』就是了。 J