{iThome 書評—7} 重構—改善既有程式的設計中譯版

重構:改善既有程式的設計
— Refactoring : improving the design of existing code 重構:改善既有程式的設計 — Refactoring : improving the design of existing code
———————————–
作者/Martin Fowler/等著
譯者/侯捷, 熊節/譯
出版社/碁峰 出版
ISBN/9867594061

內容簡介
當物件技術成為老生常談之後 — 尤其在 Java 編程語言之中,新的問題也在軟體開發社群中浮現了出來。缺乏經驗的開發人員完成了大量粗劣設計,獲得的程式不但缺乏效率,也難以維護和擴展。漸漸地,軟體系統專家發現,與這些沿襲下來的、品質不佳的程式共處,是多麼艱難。物件專家運用許多(而且日漸更多)技術來改善既有程式的結構完善性與性能,已有數年之久。但是這些被稱為「重構」(refactoring)的實踐技術,一直(只)流傳在專家領域內,因為沒有人願意將全部這些知識錄寫為所有開發人員可讀的形式。這種情況如今終於結束。在《Refactoring: Improving the Design of Existing Code》書中,知名的物件技術者 Martin Fowler 闖入新的領域,褪去那些名家實踐手法的神秘面紗,並展示軟體從業人員領悟這種新過程的重大意義。

只要受過適度訓練,一位技巧嫻熟的系統程式員可以在拿到一個糟糕的設計之後,把它翻新為設計良好、穩健強固的程式碼。本書之中,Martin Fowler 告訴你重構機會通常可以在哪裡找到,以及如何將一個糟糕的設計重新修訂為一個良好的設計。每個重構步驟都十分簡 — 簡單到了似乎不值得去做的程度。重構涉及將欄位(field)從一個 class 搬移到另一個class,或將某些程式碼拉出來獨立為另一個函式(method),或甚至將某些程式碼上下移動於繼承體系(hierarchy)之中。這些個別步驟雖然可能十分基本,積累下來的影響卻能夠徹底改善設計。重構已經被證明可以阻止軟體的腐朽與衰敗。

除了討論各式各樣的重構技術,作者還提供了一份詳細名錄(catalog),其中有超過 70個已被證明效果的重構手法,以饒富幫助的重點,教導你實施的時機,實施時的逐步指令。並各自攜帶一個例子,顯示重構的運轉。這些富有良好解說價值的實例都以 Java 寫就,其中的觀念適用於任何物件導向編程語言。

Martin Fowler 是一位獨立諮詢顧問,他運用物件技術解決企業問題已經超過 10 年。他的顧問領域包括健康管理、金融貿易,以及法人財務。他的客戶包括 Chrysler, Citibank,UK National Health Service, Andersen Consulting, Netscape Communications。此外Fowler 也是objects、UML、patterns 技術的一位合格講師。他是《Analysis Patterns》和《UML Distilled》的作者。

Kent Beck 是一位知名的程式員、測試員、重構員、作家、五弦琴專家。

John Brant 和 Don Roberts 是《Refactoring Browser for Smalltalk》的作者,此書可從http://st-www.cs.uiuc.edu/~brant/RefactoringBrowser 獲得。他們兩人也是諮詢顧問,研究重構的實踐與理論有六年之久。

William Opdyke 在伊利諾大學所做的 object-oriented frameworks(物件導向框架)博士研究,導出了重構領域的第一份重要出版品。他目前是 Lucent Technologies/Bell Laboratories 的一名卓越技術人員。

譯者 侯捷,致力計算機技術教育超過 10 年 — 以著作、翻譯、評論、專欄、授課等多重形式。對於各種層級、各種定位、各種技術領域之 Framework Libraries 有濃烈興趣和鑽研。

譯者 熊節,普通程式員,喜編程,樂此而不疲。酷愛讀書,好求新知。記性好忘性大,故凡有所得必記諸文字,有小得,無大成。胸有點墨,心無大志,惟願寧靜淡泊而已。夜闌人靜,一杯清水,幾本閑書,神交於各方名士,獻曝於天下同好,吾願足矣。

前言

本書我覺得可以說是軟體界兩大奇書之一 (另一本就是“Design Patterns”)。設計模式講究的是在程式碼之前 (常所說的系統分析與設計活動)的事先設計,而重構講究的則是程式寫碼後對結構的重整。

我們要先瞭解一件事,軟體設計不可能如建築業一般,只在藍圖上畫好設計圖就能建構出穩固的高樓大廈。軟體開發是要經過不斷地分析、設計、寫碼、測試與修正… 。漸增與反覆,才有可能建構出高品質與強固的系統。事先的設計能保障程式碼相當程度的品質,但不可能完美無瑕,事實上,即使如本書作者 Martin Fowler,也仍須透過程式碼的驗證回饋,再回頭來修整軟體的結構。可以說,運用在紙上藍圖的設計模式與在程式碼的重構本都是設計中的一環,“Top-down (SA/SDPG)”與“Bottom-up (PGSD/SA)”兩者本就不應該在軟體工程是被分開為兩種方法論,而是互補,缺一不可,才有可能建構出軟體設計開發的正回饋環路。

所以重構的對象為程式碼,目的在於對程式碼背後所隱含的結構作重整,提昇對軟體系統的彈性與穩定,同時也相對能讓程式人員容易維護與讓寫碼更有效率。因為設計不可能一開始就是正確,它會隨著設計者的經驗成長而進化;程式碼被閱讀和修改的次數遠多於它被編寫的次數。保持程式碼易讀、易修改的關鍵,就是重構。

本書的作者為 Martin Fowler,不過其實考究起來,“重構 (Refactoring)”一詞是由 Kent-beck在 Smalltalk 專案中率先所提出的概念,並用在實務的顧問輔導。Fowler 是集眾多有經驗的軟體開發先驅們之大成,而把他們所經常用在程式碼重整的技巧整理編寫成重構名錄 (catalog of refactoring),模仿如設計模式一般,對每一個重構給予命名與應用時機等,讓程式人員之間方便利用這些詞彙作為溝通,而成為日常開發實務上的習慣。

瞭解為何重構、為誰重構、何時重構

閱讀全文 »

Adapter 設計模式案例與 UML 解答

有位網友以 Email 問了一個關於 Adapter 設計模式的情境描述:
 KWBank 收購了 BankOne , 怎樣用 Adapter pattern 將兩者 的 客戶資料整合….?

他說看了這篇教學:Design Pattern—Adapter 模式,仍舊不瞭解該如何解答。

這邊我就一併列出回覆給該位網友的回應,供讀者們參考:

基本上,Adapter Pattern在使用上,會比較針對『Service』來進行設計。
參考下圖,在這個設計中,兩個Adaptee Class負責擔任如2孔轉3孔的插座一樣,至於新銀行的所有Client程式,則是直接面對CustormerAdapter的物件;如此一來,就可以隔絕掉不必要的外部程式碼,所有跟外部溝通的,都透過Adaptee的物件去存取。

圖 1、範例—訂購系統的類別圖(Class Diagram)
(點擊圖片鏈接看原圖)圖1、範例—Adapter 設計模式案例圖

{iThome 書評—6} Rational 統一流程入門

統一流程入門 第二版
— The Rational Unified Process An Introduction 2nd 統一流程入門 第二版 — The Rational Unified Process An Introduction 2nd
———————————–
作者/Phillippe Kruchten/著
譯者/趙光正/譯
出版社/維科圖書有限公司 出版
ISBN/957-8675-79-8

內容簡介
這本書非常簡潔,裡面快速介紹Rational統一流程(Rational Unified Process ,RUP)的一些概念、結構、內容和動機。RUP是一個具備網際網路功能的軟體工程流程,它強化團隊的生產力並提供成員最好的軟體實務經驗。RUP非常特別,開發團隊可以透過它了解統一模型語言(Unified Modeling Language , UML)、軟體自動化和業界最佳實務經驗的所有優點。

Rational統一流程統一整個軟體開發團隊的工作,並且讓每位成員達到最高生產力,因為它為大家帶來了成千上萬個專業與頂尖業界領導者的經驗。想在可預期時程內、用合理預算、輕易完成為品質軟體嗎?快拿本書當作你的指導手冊吧!本書作者與你分享他最深層的流程相關知識,並且把焦點放在RUP的關鍵點,讓你很快就能專精RUP這個已被證實過、確實可行的軟體開發解決方案。

本書第二版主要根據最新版的Rational統一流程更新以符合最新內容。事實上,完整的RUP2000裡’還包括:
1.更多的e-開發指引
2.一份學習地圖,教你如何把流程應用到各式各樣的專案和技術上
3.擴充過的測試分析,現在它會橫跨整個產品生命週期
4.改良過的應用程式介面設計範園一特別針對如何開發有效的網際網路應用程式
5.針對及時與互動系統,提供更詳盡的說明
6.深入淺出介紹如何用樣式和框架來設計系統

Philippe Kruchten是Rational統一流程產品的首席架構設計師。他有超過25年的大型、軟體密集式系統開發經驗,這些系統的領域包括通訊、安全防禦、太空、交通和軟體開發工具。他並擁有Ecole Centralc de Lyon(法國)的機械工程學位和French Institute of Telecommunications的電腦科學博士學位。

前言

RUP (Rational Unified Process) 是由 IBM Rational 所研發並推廣的軟體開發流程。它是一套流程框架 (Process Framework),可根據開發團隊的需求去調整或擴充,自訂的流程描述不外乎包括了四項元素:誰(Who)做了什麼(What),如何做(How)和什麼時候(When)做;它也是一套產品,由 Rational 所研發和維護,並整合在該公司的 Rational Suite Enterprise 套裝軟體內。安裝好該光碟產品,便可以把這份產品當成 RUP 的虛擬電子教練 (e-coach),它提供一個完整的超鏈結網頁,以 HTML 格式來描述流程,並附有各種格式的樣版(Template),如 HTML、RTF、PDF…等,及一個簡單的 Case Study:Rational Project Web Example;而 RUP本身更是一種軟體工程流程(Software Engineering Process),它提供研發單位一個嚴謹的方法,分配軟體開發工作和責任,目的是確保在可預期的時程和預算內,開發出符合使用者需求的高品質軟體。

本書不到 300 頁的內容,是將RUP 作一個整體介紹,算是一個縮影。作者是由 RUP 的首席架構師 Kruchten 所著,事實上,第一章是由軟體三巨頭之一的 Grady Booch 所撰寫的論文,是本書最有價值的地方;而第二至第六章則涵蓋了 RUP 的流程框架介紹,包括了靜態結構的流程描述與動態的流程行為說明。最能代表 RUP 的是一張看起來像是鯨魚的二維流程結構圖,水平軸代表時間和流程開始後的各個生命週期,也就是分為初始、詳述、建構、轉移等四個開發階段;以及垂直軸代表的是核心工作流程,也就是把活動按照本質加以分類的結果。諸如企業塑模、需求、分析與設計、實作等活動,也稱之為規程 (discipline)。七至十七章則是第二部分的工作流程介紹,是由 RUP 流程開發團隊的工程師們所撰寫的,諸如專案管理的工作流程、需求的工作流程等,包括了工作流程的目的、定義主要的概念、工作人員與工作成果、活動與輔助工具等。這一部份的內容看看參考就好,因為工作流程不外乎是談及什麼人在某個時間點做了什麼事 (產出),以及如何串接等,每一個專案的開發都會是不一樣的,沒有必要也不可能採取統一制式的工作流程。

最佳的軟體開發實務經驗

Grady Booch 在第一章的論文中,揭露出軟體的價值何在,以及所衍生出在軟體開發時經常發生問題的症狀,諸如無法處理需求的變動、模組間無法配合、軟體很難維護與擴充、太慢發現專案的嚴重瑕疵 (Defect) …等。同時也提及了專案雖然有不同的失敗原因,但最主要的原因包括了:不精確的溝通方式、脆弱的架構 (Architecture)、很難處理的複雜性、不一致的需求、設計和實作、測試不足、沒有客服風險等。

從根本問題找解決方案,並應用在商業上證實可行並廣為業界的成功組織所採用的軟體開發方式,而成為 RUP 的關鍵性精髓,也可以說是軟體開發最佳的實務經驗 (Best Practices),包括了:以反覆式 (Iterative)方式開發軟體、管理需求、以元件為基礎 (Component-based)的架構、以視覺化方式製作軟體模型 (Visually Model Software)、持續驗證軟體品質、控制軟體的改變。

當然,這些實務經驗可非一蹴可幾,是需要經過軟體組織持續不斷的學習與摸索,並建立紮實的本質素養方可的。舉個例,光是以元件為基礎的架構這一部份,要能瞭解什麼是元件,要如何適切地切割元件的大小,要如何定義出元件的介面,也可以說就是 Design for Interface,把善變的部分封裝在元件內部,這些可不是容易的事;再則以反覆式的開發方法,聽起來有道理,但做起來卻相當難執行,因為人們一般很難忍受不確定性,尤以專案經理時常抗拒這種開發方式,因為它看起來像是永無止境、無法控制的脫序行為。事實上,反覆式在 RUP 的規範中,是可以被控制的,每次反覆都是以編號、週期和目標妥善計畫。只是因為這一些會衍生出專案管理的其它議題,才使得專案管理人員喜歡循序的瀑布(Waterfall) 開發方法,每一個開發階段都定義了很明確的產出。問題是,我在前兩期介紹 XP 時,也曾提及了,軟體的根本問題在於風險。而瀑布式太晚把風險揭露出來,這在現今多變的需求開發中是早已證實不可行的。若反覆式是證實才能解決軟體開發的根本問題,那麼,無論過程遇到一些阻礙,還是應該堅持來達成。 ”Do the Right thing”後,才能“Do the thing Right”!

本書特別在第四章中,介紹了 RUP 的動態結構即為反覆式的開發方式。這也說明了一件事,那些把 RUP 當作僵化官僚的開發模式的軟體組織,實在沒有去用心體認 RUP 的關鍵精髓,擷取其成功的實務經驗,而只是把它拿來當作應付階層式組織各級主管的工具而已,因為很容易產出美美的文件,用它來交差應付。我在許多比較大型的組織中,的確看到很多這樣的現象,這麼多的軟體開發人才,卻一直在那裡空轉著,浪費太多不必要的資源,殊為可惜。

以架構為中心及使用案例驅動的開發流程

本書第五、六章,揭露出“4+1”的架構觀點,及以使用案例驅動 (Use case driven)的開發流程。架構可不容易被解釋與認知,RUP 是嘗試利用觀點 (View)來解釋架構,以讓軟體開發人員瞭解這些觀點的主要產出 (artifacts),以及如何調和這些產出,並仍能維持有一致性的全貌與見解。

“4+1”共五個觀點,包括了邏輯觀點、實作觀點、程序觀點、配置觀點,還有一個擺在中間的使用案例觀點,利用它來驗證其它觀點,也可以就是利用需求功能來驗證各個階段的開發產出。每一個觀點都有相關角色的開發人員職掌,例如需求分析師會專注在使用案例觀點、結構分析/設計師會專注在邏輯觀點,而程式設計師當然就是著重在實作觀點了。

RUP 是強調“Use Case driven”,但卻不是 “Use Case First”的。兩者的差異在於前者是利用功能需求驗證架構的一致性、結構的彈性、以及實作的完整性等;而後者則是純然以需求作為涵蓋整個系統的建構,卻忽略了其它的觀點,而使得系統不具彈性、延展與可重用性等。國內短線的專案開發生態經常是如此,而導致軟體人員只重視需求的功能面與實作的技術面,卻忽略了軟體的主結構,也使得系統不具應變的特性了。

我為什麼要介紹 RUP? 我不是輕量型 (lightweight)的敏捷式 (Agile)開發流程的擁護者嗎? RUP 給一般軟體人員的印象是僵化、官僚、受控制的重型 (heavyweight)開發流程,事實上,我在熟讀本書之後,更確定了,RUP 的本質精髓與其它所謂敏捷式的開發流程根本就是一樣的,它們均強調反覆式的開發、需求導向、以及對測試的重視,只是作法 (how-to)不一樣而已。而 RUP 被視為是高度儀式化的重型開發製程,這也是被那些崇尚軟體工程的專案管理人員給濫用了,卻忽略了軟體也包括了心理學、哲學與藝術的成分存在,而不是只有工程學而已 [Kruchten 2002]。另外,要注意的是,UML 可以是國際標準,但是流程卻沒有所謂的標準,它充其量只是範本 (Template)、一種框架而已。這麼說好了,團隊開發成員之間可以講相同的語言(UML),以利相互的溝通;但每個團隊要如何達成目標,則各有其方法與程序(Process)來達成任務。程序是“How-to”,每個團隊的“How-to” 是不會完全一樣的。

{iThome 書評—5} 深入淺出設計模式中譯本

深入淺出設計模式
— Head First Design Patterns 深入淺出設計模式 — Head First Design Patterns
———————————–
作者/Freeman, Sierra & Bates/著
譯者/蔡學鏞/譯
出版社/歐萊禮 出版
ISBN/9867794524

內容簡介
寫應用程式時需要依照需求預先規劃、設計,而設計模式累積了前人的經歷,經由四人幫彙整出一系列的設計模式,以利後人可以套用。本書集合四人幫的23個模式(十幾年前的事)外加這十幾年來新增的一些模式,作者群以詼諧、幽默、圖文並茂、打破傳統著書的方式,由淺入深地詳解了設計模式的精神及重點。全書全部以當紅的 Java 程式語言為範例。

前言

幾乎有經驗的軟體人員,手裡都會有一本四人幫 (GoF, Gang of Four) 著作的「設計模式 (Design Patterns)」,此本可以說是軟體業的聖經,書中介紹的 23 個設計模式,已被大量運用在系統框架 (Framework)及應用領域上。不過本書卻是相當的艱奧難懂,如同金庸小說中的「九陰真經」上卷一般,充斥的盡是心法,但若沒有從實務汲取到相當經驗的話 (極少數人是可以透過“內觀”來悟出心法,但那真的相當稀少),是很難領悟並活用這些招式的。所以坊間出版了眾多“「九陰真經」的下卷”,透過大量的實例,來闡述上卷所揭露出的心法。

這些書可以算是「設計模式」的註釋版了,不過大部分仍是以程式碼來作解釋,除了比較不容易解釋設計模式背後的哲理外,也稍嫌沈悶了一點。倒是本書,怎麼說呢?相當相當的特別!跳脫了任何種類軟體書籍的寫作方式,運用作者群在神經生物學、認知科學、學習理論等,來協助讀者將這些設計模式給深刻烙印在你的腦海中。書本封面是一位酷酷的美少女,仰著頭看著你;每一章的封面則是美國 1960 代紳士淑女們的黑白照片,簡單的意象來表達該章節想要傳達的主題;書中內容則是充斥著大量的漫畫式照片、插圖、手稿等,利用問與答的方式,來解釋一般讀者們在學習過程中,常碰到的問題與思考;同時在章節前後陸續列出了九個相當重要的 OO 守則,這些守則也可以說明軟體設計的根本,說真的,要能通透這些哲理,最少也要花上 10 年以上的功夫修煉才有可能運用得爐火純青;喔,還有填字遊戲,利用每一章所讀過的英文句子,來填出與模式相關的關鍵字彙,真的相當有趣,實在是複習的好幫手!

唯一不變的真理就是時常在改變

第一章「介紹設計模式」部分,利用了模擬鴨子游泳戲水、呱呱叫遊戲的案例,來帶出物件導向的四個基本概念:抽象、封裝、多型與繼承,也提及了重要的一件事,OO 不是只為了“做”出來,而是因為 彈性、延展性、可重用性的設計考量,賦予系統生生不息的價值。從設計實作的過程中,你會發現到,好像有些會一再重覆發生的問題,可以利用一些特定的模式來解決該問題。這些模式,可以說是 OO 設計經驗的精華所在,可以讓我們建構出具有良好 OO 設計品質的系統,更可以讓開發者之間有一個共同的字彙,來提高溝通的價值。對了,大多數的模式和守則,都是著眼於軟體改變的議題上,這也就是道出了模式的根本價值在於協助開發者如何應付改變 (Change),“Design for Change”,這可以說是軟體設計不可避免,也是唯一不變的真理了。為了要能應付改變,我覺得有兩條絕對要謹守的原則就是: 1. 將變動的部分封裝起來;2. 針對介面寫程式,不是針對實作寫程式。尤以後者,可以說是絕大部分軟體人員所無法體會的了,這是一種基於“變”的設計態度,卻非實作技術面的議題了。

他山之石,可以為錯

本書是把 23 個設計模式中的 14 個,給擺入到 1~11 章內,利用案例,作相當精闢的解說。剩下的 9 個模式,作者認為比較沒有經常地被使用,所以是放在附錄中,但仍有可取之處,所以也會利用簡單的幾頁說明用法與為何要使用的原因。我想先讓讀者瞭解一下,四人幫的設計模式,是分為三大類:生成 (Creational)、結構(Structural)、行為 (Behavioral)。生成如工廠 (Factory)模式,顧名思義,就是會幫你製造物件,再回傳給呼叫並符合該介面規格的 Client。這在多型的設計,經常會在 Server 端使用生成模式,以免讓你的 Client 與伺服端的具體類別綁住 (不要忘了,Design for Interface);結構模式,則經常反映了問題領域的概念,例如 複合 (Composite)模式,可以表達樹狀的層級,如組織 (Organization)、BOM (Bill of Material)表等;行為面的模式,一般設計者比較不容易能抽象化,因為它可能是根據設計的議題,將原本在分析階段,某一個類別的行為,抽離出來也成為類別,而能應變具再利用的價值。簡單的說,就是把行為當成物件,每一種不同行為的物件,再分門別類,並制訂出共同操作的介面 (interface)規格,與原來擔負某一行為的本體 (context)類別,關連在一起。狀態 (state)、策略 (strategy)、命令 (command)等模式,就是屬於此種行為性的模式。

最後一個章節則是指導你如何學會與設計相處,挺有意思的,它讓你瞭解設計模式的本質與其組成的主要成分;「如果你發現到處於某個情境下,面對著一群限制的問題,正影響著所欲達成的目標,然而,你能夠採用某個設計,克服這些限制並達到該目標,將你領向某個解決方案。」情境 (context)、問題、解決方案 (solution),正是組成模式的三個主要組成元素。當我們仔細觀察其定義後,進而,能組織並活用這些設計模式,更甚者能融入於心智、成為隨手拈來可得的利器,而創造出自己的模式,造福他人,成為共同溝通的語彙,那可真的是一種心靈上的愉悅,設計模式的威力與目的,正是如此。

本書很厚,600 多頁,但閱讀因為太輕鬆了,你完全感受不到厚厚的一本,還會覺得意猶未竟。眾多推薦人當中,竟然還有美式足球的明星球員推薦呢,真的難以想像,他怎麼有時間看這類的專業書籍? 但也可想而知,本書的易讀性,就是這樣地讓人可以把它帶到健身房,一邊閱讀,還能臉上堆滿笑容。

{iThome 書評—4} 極致軟體製程中譯本

極致軟體製程
— Extreme programming explained : embrace change 極致軟體製程 — Extreme programming explained : embrace change
———————————–
作者/Kent Beck/著
譯者/李潛瑞/譯
出版社/培生 出版
ISBN/9867910311

內容簡介
本書分成三大部分:

第一部份:問題
從『基本的問題』到『回歸基本面』的章節,構築出XP試圖要解決的問題,並點出評估對策的標準。這部分會告訴你整個XP的概念。

第二部份:對策
從『快速走一遍』到『測試的策略』的章節,把第一部份抽象的概念,轉變成具體方法論的實踐。這部分說的就不是大體的狀況了,而是會把每一種實際做法,跟第一部份所說的問題和原則銜接起來。

第三部份:實踐
從『XP的導入』到『XP的應用』的章節,圍繞在如何實踐XP的各式主題上—像是實踐出適合自己的XP、它對『非常專案』中各種成員角色分工的期待、以及對商業人士的意涵。

這本書談的是XP背後的一些想法—它的緣起、哲學、故事、和迷思。
本書意欲幫助你在獲得充分訊息的狀況下,做出是否導入XP的決定。

如果你 讀過本書後,正確地做出用與不用XP的決定,我都已經達到我的目標。
本書的第二個目標,是要幫助那些正在使用XP的人,能夠對它有更深入的了解。

前言

製程是否與軟體設計有關? 我以為設計本來就不能昧於現實,要能在現實與理想之間,找出調和的解決方案—這會與現實的開發環境有關;再加上設計必然會面對團隊開發時,眾多“人”觀點之間的謀和溝通等議題—這也會與製程有關。所以我也會在「軟體設計必讀經典」系列中,介紹關於製程、方法論等一些好書。其中,本次書評的主角—極致軟體製程,最會是我想推薦給讀者們的經典指標。看到這本書,就如同在舊書攤找到絕世的武功秘籍一般,講究的是心法的傳授,整本書沒有一行程式碼、只有少數幾張圖而已,全都是口述的文字,但閱讀起來完全不沈悶,非常的白話,如同閒話家常般的告訴你軟體的一些道理。

XP, eXtreme Programming (X 要大寫,凸顯了 Magic Letter),中文翻譯為“極致”軟體製程,我覺得 eXtreme 一字也可翻為“極端”,極致代表的是將軟體製程發揮到最善;極端表達的則是有些顛覆傳統開發的方法,但很有效。(例如,搭檔編程,兩個人一起寫一支程式,開發效能反而提升)

教祖康貝特 (諧音),從本書發表以後,儼然成為與 UP (Unified Process)相對立的一種教派:一為輕量級 (XP)、另一為重量級 (UP)的開發製程。(當然,事實上那是僅從方法論的角度來比較看待之,這些製程的根本精髓仍是一致的) 其後闡述 XP 的書籍如雨後春筍,眾多有經驗的軟體開發者們,提出了從 XP的根本價值與原則,來找出解決實務問題的最佳對策與方法等,有三十本以上之多,而目前中譯本也出版了有五、六本左右,但賣得好像不好,本書在某書局又是只賣 NT$ 99。

從問題的根本找出解決方案

第一章開宗明義就提到:軟體的根本問題在於風險! 諸如無法準時交付、錯蟲太多、需求變更、不合適與不必要的功能、人員流動率 …等。因為看到這些問題,XP 先找出影響軟體製程的四個變數因子,然後提出了四種價值觀,再以此訂出開發的基本原則,然後回歸到簡單的基本面,制訂因應的對策,找出實務的解決方法,然後實踐它!

四個變數因子:成本、規模、時程、品質。 你會發現有趣的一件事,其中的三個因子,成本、規模與時程,幾乎都是被控制在客戶手裡,而開發承包單位大概只能控制品質這個因子而已。而品質這個因子正是與前三個因子為反比,所以,成本越低、規模越大、時程越短,那麼,品質必然會差。這種就是根本性的問題,這些變數因子如果沒有作有效控制,那麼導入如 CMMI 等,也是枉然的 (搞不好還更糟糕,增加了太多高度儀式化的工作)。 Kent Beck 在本書中提到了,他發現到可以先專注在規模變數的控制,也就是把規模收斂,專注在客戶真正想要的,早一點釋放出版本 (Release early),如此也比較容易消弭客戶與開發單位見解上的歧異。

四種價值觀:溝通、簡單、回饋、勇氣。 我覺得這就是群體生活最符合人性的恆常價值了。 團隊開發,不說出話來,如何溝通呢? 如果沒有回饋,如何知道你的問題呢? 沒有勇氣表達出你的觀點與決心,如何持續實踐下去呢? 經常性的溝通、回饋、有勇氣表達,團隊自然會造成一種良性的正回饋環路,而更容易有一致性的共識,而往往,簡單的呈現就會出來了。

當你認知到軟體開發的根本問題與所影響的變數,並有了團隊整體的開發價值觀後,就會比較容易找出開發的根本原則了。諸如,快速的回饋、把簡單視為正常、漸進式的改變、擁抱改變、作有品質的事。

把握住基本原則後,再來才是找出解決實務的方法。本書提出了十二種實務 (當然,具體實踐的作法,是在其它書籍中深入說明的),相當具有學習參考的價值,不過,可不要全盤照抄,國情、人文等因素,有些不一定行得通 (例如,要求客戶駐在承包公司),況且,方法是“How-to”,我們應該是從原則來自行找出方法來的,這才是符合 XP 的精神!

簡單的道理卻難以執行

我覺得 Kent Beck 是生活的大師,他把許多生活的哲理帶入了軟體領域來,書中也提到,他媽媽教導他開車時,不是讓車子一直保持在「正確」的方向,而是時時保持專注,這裡修正一點、那裡修正一點。嘿,這正是漸進修正的最根本道理啊。所以書中的副標題為何叫做“擁抱改變”? 因為,軟體開發中的每一件事物都會改變,而問題不在於改變本身,而是在於無法應付改變。

是的,我非常認同 XP 的智慧,不過我也不是 XP 的狂熱份子,我會動態找 How-to,所以例如,“測試先行 (XP 十二項實務之一)”,是我會主張在客戶單位堅持要導入的,而且是以使用案例(加上測試案例)作為功能測試的單位—而這就不是 XP 的方法了。 XP 是建議以 “Story board (或稱為使用者陳述)” 來作為需求的功能點,不過,我覺得使用案例實在很好用,沒必要完全拋掉 UML。 (XP 這點比較奇怪一點,幾乎不見 UML 的影子,甚至連圖形的設計表達都很少)

XP 的道理相當單純,但「執行面」可是很難執行。這在本書第二十四章有特別說明之。Kent Beck 提及,導入的難處,主要還是情感上的問題—特別是恐懼感作祟。我很認同! 所以,我從來不與客戶說我要協助你們導入某某方法論,通常就是以誘導的方式,不知不覺的融入,然後把它當成是一種習慣,團隊成員久而久之就會以為理所當然如此。

對了,為什麼簡單的道理反而不容易執行? 因為,人類往往有兩種天生的傾向:一、對於我們所碰觸的任何事物,通常會弄得過度複雜,基於這個原因,二、我們往往不能看到事物最明顯的一面。

{iThome 書評—3} 使用案例寫作實務中譯本

使用案例寫作實務中譯本
— Writing Effective Use Cases 使用案例寫作實務中譯本 — Writing Effective Use Cases
———————————–
作者/Alistair Cockburn/著
譯者/趙光正/譯
出版社/碁峰出版
ISBN/9867727681

內容簡介
完整討論使用案例的關鍵部分,包括參與者、關係人、設計範圍、情節等等。提供完整的使用案例寫作指導,包括寫作步驟與推薦格式。提供一大堆省時有效的使用案例寫作技巧。提供有用的使用案例範例,並且說明範例適用的時機。

這本書的好處就是實例超多,一般的書中對使用案例的介紹都很簡單,或者範例不足,讀一些原則如果沒有範例配合,有時候還真的像在隔靴搔癢。

這本書提出兩個概念:1.把使用案例依照設計範圍(design scope)或者系統範圍(the extent of the system )分為三個層次(第三章)1.Enterprise (business use case) 2.System(system use case) 3.Subsystem(component use case) 2.依照使用案例所達成的目的(goal )分為三層(第五章)1.Summary goal 2.User Goals 3. Subfunctionas 當你在畫使用案例時,思緒先粗再細,就我自己的經驗,高層次的使用案例,數量不會太多,容易控制,也比較能夠用巨觀看事情。管理大量的使用案例時,除了使用高層次的使用案例外,通常也會用到很多使用案例間的關係(第九章,第十章),或者把使用案例組織一下成套件(package)管理(第十三章)。 還有,就是一般人會問使用案例是否等於需求?不過本書對這部分著墨稍嫌少了一點(第十六章),還好,它補了一章說明使用案例與整個開發流程的關係(第十七章),裡面提到使用案例 v.s. 系統特性(System Feature),作者蒐集了很多的使用案例格式(第十一章),作者把寫使用案例當成寫作文,所以整本書是在教導你如果寫出一篇篇的短文(使用案例),當然而會有類似教作文的起承轉合(第六章,第七章,第八章)。

前言

使用案例 (Use Case) 是由 Jacobson 在易利信公司做電信系統時,所發明的一種描述系統行為的工具,並隨著 UML 規格的制訂,而成為普遍被用來作為需求捕捉最關鍵的技術。我是認為,使用案例可以說是這十來年來軟體界最了不起的創見! 因為它簡單,使用案例圖,利用棒型人偶 (參與者)表達使用系統的使用者與系統需要外部系統的支援服務,而橢圓形的使用案例即是表達一個個系統所提供的功能服務;然後再以純文字的寫作方式,來描述每一個使用案例的需求陳述,也可以說是參與者與系統之間的互動對話,卻又不致牽涉到系統的實做面 (把系統當黑箱)。簡單的圖形,加上文字敘述,就可以建構出從使用者角度來看系統功能觀點的使用案例模型。

不過很奇怪,使用案例易學難精,沒有把握基本精要與原則,很難把圖給畫好 (不容易界定出系統範圍),更何況是用純文字來寫出需求陳述。耶? 純文字的寫作這麼困難嗎? 是的,它真的不容易,我還常建議需求分析人員,多勤讀「古文觀止」,來充實散文的寫作能力。

我大概看了有五本寫使用案例的書籍了 (均為原文著作),發現到每位作者對使用案例的闡述,歧異還蠻大的,可以說是“各自表述”,而且多少都已經有加入作者本身的觀點,擴展 Jacobson 的使用案例理論。老實說,我對使用案例的技術相當著迷,但學習該技術的前兩年完全不知所云,一點都無法體會出它的本質精髓 (只學會一些使用的功法而已),直到吸收了兩本好書:“Use Case Requirements in Context”,以及本次書評的主角,才慢慢打開心眼。尤以本書,我起碼看了半年以上,讓我對所謂的層次、目標等級、寫作原則與風格等,可說是奠定了相當清晰的基礎功夫了。

腦力激盪的最佳工具—記錄需求、發掘需求

本書不算薄,22 個章節,外加四個附錄,內容分為三大部分—使用案例的主體、相關議題的討論、寫作提示等。一開始閱讀會有些吃力,尤其第一部份,其實內容有些零散。我是建議要隨時翻閱目錄,瞭解自己在閱讀時的主題與焦點所在,若當下無法體會,其實跳過去也無妨。

第一部份最重要的是當然要瞭解使用案例的本質,以及寫使用案例的格式,Cockburn 提供多種寫作的格式供參考,如單欄/兩欄/RUP,甚至利用 Occam 程式語言、圖形呈現的另類寫作風格,相當有意思! 另外最有價值的部分,也是 Cockburn 自創的三個目標等級—白雲、海平面、海平面下,來說明使用案例的精確程度,以及適合的目標層級對象。第二部分算是 FAQ 性質的一些主題性的討論。例如最常見的 CRUD (Create, Read, Update, Delete) 與 可參數化 的使用案例該如何描述比較恰當;開發流程中,使用案例所扮演的角色與其它製程產出的關連性;常見的寫使用案例所發生的錯誤 …等,對於實務已經在應用使用案例開發的人員來說,相當具有參考價值。第三部份是我覺得本書最實用的部分了,尤其第 20 章,單一寫使用案例的相關寫作提示,就足以讓需求分析人員受用無窮了,因為以我所看過太多位 SA 所寫的使用案例,幾乎所犯的錯誤,在本章都有提到。所以只要依循本章所列出的十一個寫作提示,要寫出中規中矩的案例敘述,也就不會是什麼難事了。

有意思的是,即使你寫的是中等程度的使用案例,都還來得比其它種類的需求文件還有用,事實上,只要能具可讀性,對整個專案就會有相當的貢獻;再則,使用案例不僅僅只是記錄需求的工具而已,它更可以成為專案成員的腦力激盪工具,來發掘出新的或潛在性的需求,這更是價值斐然!

順應國內短線專案型態—Use Case First

一般而言,使用案例會成為「物件導向」式專案開發的最佳前導工具,雖然它與物件導向一點都沒有關係。本書在國外的評價相當高,但在國內卻不賣座,這多少與本書完全沒有提到如何將使用案例與系統的結構設計至實做的橋接有關,純粹就是在談使用案例的寫作而已。而事實上,國內 95% 以上的專案都是偏以功能導向的開發為主,至於系統內部的結構分析設計,因為時程的壓縮與抽象基礎的素養不足,往往無法做好。功能會直接影響到專案能否被“做出來”;結構則是影響系統的彈性與穩定度。所以個人是主張“務實一點”,先順應國內短線的專案生態,利用使用案例,快速的給直接 mapping 到實做面。

我在實際輔導的經驗中,效果與接受度相當高;雖然是“Quick”,但可不“Dirty”,兩個配套措施是一定要做的:測試案例到測試程式碼,隨時驗證功能的正確性;分析類別的規劃,以符合 3-tier 的 MVC (Model-View-Control) 框架。系統做的出來,開發能力也有比較提升,老闆也比較願意投入更多資源的情況下,再施以結構重整,慢慢粹取出系統最穩定、共用的那一部份。有了使用案例後,我好像就再也沒擔心過能不能“做”得出來,那根本已經不是問題了。

五顆星級的好書,價值多少?

在 Amazon 評價四顆半星的好書,你猜猜看台灣賣多少錢? NT$ 99,沒錯! 你沒有看錯,國內販售軟體書籍指標的「天瓏書局」竟然將本書折扣到一折半,不到一百元可以買到寫使用案例叢書中最棒的書籍,但,卻仍舊乏人問津,我真的很難以想像,需求分析人員,省一到兩次的便當錢,總該可以吧? 好歹,本書真的可以在工作上幫助你太多太多了。

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal