{iThome 書評—8} Object-Oriented Analysis and Design

Object-Oriented Analysis and Design with Applications
Object-Oriented Analysis and Design with Applications 2nd Edition
———————————–
作者/Grady Booch 著
出版社/Addison-Wesley Professional
ISBN/0805353402

*** 參考之前對本書的「好書分享***

前言

曾有讀者反應,前幾期中譯本書評,我只就針對原文書籍的內容部分做介紹,卻沒有提及到翻譯的水準。基本上,我是很欽佩這些譯者們的用心,這是吃力不一定討好的工作。再者,我當然是有過濾過才會做介紹的,個人所介紹前幾期中譯本翻譯的品質,我覺得可以說都是在水準之上,讀者們應該是可以放心的 。不過,現在是該來介紹原文著作的時候了,畢竟要從事專業軟體設計職這一行,不看原文可是不行的。

本書是 UML 三巨頭之一 Grady Booch 作為在物件導向分析/設計 最具代表的經典著作,本次我所介紹的書評為第二版,而今年暌違 13 年之久又增訂了第三版,主要新增的內容是將塑模語言改為 UML2.0,並深入探討整個生命週期的一個階段。不過在第一部份的概念篇則與前兩版內容一樣。

軟體的複雜是與生所俱來的 (The inherent Complexity of Software)

本書內容分為三大部分:第一部份為概念 (Concepts),包括複雜度的闡述與觀察、物件模型的建構、類別與物件的區別、分類;第二部分為方法論 (Methodology),包括塑模的語法 (這裡主要揭露出類別圖、狀態機圖、物件互動圖)、巨觀 (Macro)與微觀 (Micro)的開發流程、專案的管理與規劃等;第三部分為案例分析,包括天氣監控、Client/Server 庫存追蹤、AI 人工智慧,甚至 Framework 等系統的分析與設計,以及簡單程式碼的展現。

第一部份的概念篇價值是最高的,Booch 在闡述軟體複雜本質的這一部份,實在是精彩。藉由 PC 硬體產業與大自然植物行光合作用的例子,來解釋其它領域是如何應對複雜度。這就帶出了物件第一個哲理:封裝 (Encapsulation)是解決軟體複雜度的根本。而封裝往往具有階層性,藉由其特性將混沌的表象帶往有機的次序,呈現出簡單的結構。將這些其它領域,包括大自然帶給我們的智慧,來解決在軟體複雜系統的方法與技巧,即為所謂的物件導向分析與設計。

本書更意思的另一部份是它的插圖,尤其是那隻肥貓,逗趣極了。Booch 怎麼介紹抽象 (Abstraction)呢? 插圖上有兩位貴婦人,一個看到的是毛茸茸肥成圓團的寵物貓;另一個則是看到這隻肥貓的骨架與器官組織。這就隱含了軟體開發各種不同角色的人員,往往會有不同的觀點,有需求面的外部觀點,也有結構面的內部觀點。但,觀點仍須保持一致,才能維繫其本質的調和。這讓我想到金鋼經的一句話:「凡所有相,皆屬虛妄,見諸相非相,即見如來。」不要執著在單一的觀點上,運用抽象的本能,當能看到蘊藏於諸多表象背後的那一隻貓 (如來)了。

本書中對於物件導向基礎的概念,揭露出了 抽象、封裝、模組性 (modularity)、階層性 (hierarchy)等。而在物件與類別這一篇,也是花了好多文字來說明什麼是物件、什麼又是類別,兩者之間的關係又是如何 …等。這一章節絕對是奠定物件導向最基礎的功夫,一點可馬虎不得,讀者真的得要相當用心思考體會關於物件與類別的區別,類別之間的關係,包括了關連 (association)、聚合 (aggregation)、繼承 (inheritance)等。尤以所謂的繼承,更是讓軟體設計人員混淆,其中似乎牽涉到單一與多重繼承、多型的設計觀念,這些似乎觀念透過程式語言去解釋,往往不容易理解為什麼要這麼設計。

從生活面來解釋物件導向的哲理

看完本書第一部份,我更確定,所有物件導向的觀念均可以從生活面找到解釋,時常保持一棵好奇、觀察的心,將其體悟會的心得,來解釋包括 封裝、介面、繼承、多型等物件導向的關鍵精髓,當你能“自圓其說”,說得還很開心,周遭其他朋友同事等也逐漸能接受你的論點,甚而還會被你影響,認同你的觀點 … 說真的,這樣難道你還會對軟體設計之道充滿無奈挫折嗎? 不覺得軟體設計是時常充滿著驚奇、有樂趣又有成就感的領域嗎? (當然,我也相信,不會只是虛的成就感,包括實質的“回饋”也是會有收穫的)
倒是切勿本末倒置,從程式語言來學習物件導向的觀念,因為那會讓你只是站在“用”的角度來看到物件導向,把它當作技術而已。當你覺得“不好用”、“無法用”時,你就會認為它是一種不適切的技術,無法應用在現實。殊不知,物件導向只是把人類應用在其它領域的成功經驗,以及大自然所蘊含根本的道理,來協助我們面臨在處於經常性變動的軟體系統上,是如何有效地來克服與應對複雜度,至於程式語言,它就只是工具,工具受限於實體的 IT 技術而無法有效表達這些哲理是可能的,但軟體設計人員的角度卻可不能與其同等狹隘。

多型 (Polymorphism)來說,這好像很難解釋? 非得要透過程式語言的撰寫執行才能理解? 非也! 生活面隨處可見用來解釋多型的例子了。就說“椅子”好了,包括 課桌椅、電腦椅、吧台椅、按摩椅等,均能提供給人“坐”的服務 (service)。人就是客戶端 (Client),他可以享受取用到 ”椅子”所提供的服務;而“椅子”其實就是一種抽象 (abstraction) 的概念 (concept),上述各種類型的椅子,則是具體 (concrete)呈現的物件。而這也可以用來解釋“一般化 (椅子)—特殊化 (各類型具體的椅子)”,均有提供“坐”的服務,但“坐”的方式卻也不太一樣。更甚之,從“坐”的服務,又能衍生出椅子應該有提供“可坐性”這樣的介面,只要能實現 (implement) “可坐性”的介面 (interface),都可以是椅子的一種。所以,如此說來,“大石頭”因為可以讓人坐著,所以它也能算是椅子,但是,它可不是從椅子所繼承 (inheritance)而來的。這樣的觀察與體會,又會讓你知道,“多型”不是只有從“繼承”這樣的角度來看待之。諸多種種物件導向的哲理,處處就存在於你的生活周遭面,信手拈來皆可解釋之,而且充滿樂趣,這豈是只能透過程式語言如此狹隘的觀點才能去做說明呢?

本書的基礎理論相當紮實,各種概念的解釋,都相當的清楚,可說是無懈可擊。但美中不足之處,是沒有整理得很清楚,可以說要稍微有一些底子,才能釐出這些概念之間的關連性。不過你會發現到,本書的文字敘述還真是多,字也挺小的,真要初看原文書籍的讀者可會是很大的煎熬。還好的一點是,有豐富的插圖讓你時時會心一笑,不至於太過沈悶。

{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 提及,導入的難處,主要還是情感上的問題—特別是恐懼感作祟。我很認同! 所以,我從來不與客戶說我要協助你們導入某某方法論,通常就是以誘導的方式,不知不覺的融入,然後把它當成是一種習慣,團隊成員久而久之就會以為理所當然如此。

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

軟體思維顧問

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

Personal