副標題：敏捷的開發首重的是人與人的共同合作、自我組織良好的團隊。人不是如同組成系統的元件，可以隨意被抽換的。
|
敏捷軟體開發：原則、樣式及實務 Agile Software Development: Principles, Patterns, and Practices ———————————– 作者／Robert C.Martin /著, 林昆穎、吳京子 /譯 出版社／碁峰 ISBN／986-154-148-9 Amazon 評鑑：五顆星 |
內容簡介
暢銷書作者及舉世聞名的軟體開發專家Robert C. Martin展示了當今軟體開發者、專案經理與軟體專案領導者如何解決眼前最具挑戰性的難題。這是既全面又實用的敏捷開發與極致編程的教學，由敏捷開發創始人之一所撰寫。教導軟體開發者和專案經理如何使用敏捷開發的威力，讓軟體專案如期完成又能符合預算。* 使用真實的個案研究來展示如何運用極致編程進行規劃、測試、重整、以及搭檔編程。
* 包括豐富而可復用的C++和JavaTM程式碼。
* 專注於使用統一建模語言（UML）與設計樣式（Design Patterns）來解決以客戶為導向的系統問題。
前言
本書原著在 Amazon 評鑑是極為罕見的五顆星滿分！ 書籍也是少見的厚，有近 700 頁之多。 如此深厚的內容，可不像坊間一堆可拿來當枕頭的所謂 OOP 入門書一般，盡是充斥著圖形設定教學與程式碼，沒啥內容。 套一句 John Vissides (Design Patterns 之一作者)在引言上所推薦的：「這也許是第一本將敏捷方法 (agile methods)、樣式 (patterns)，以及現代軟體開發方法交織成連貫的整體。當 Bob Martin 開口，你最好洗耳恭聽。」 六年！ 是作者在這麼多年來所深刻體會到的軟體設計和開發經驗，而本書也可說是反應了作者自身的學習成果。
本書描述了軟體開發議程的三個主題：設計原則 (principle)、設計樣式(pattern)，與開發實務(practice)。當軟體開發人員面對的是需求快速變動時，如何具備迅速的應變能力，而表現在開發的過程中，即為敏捷性的開發；為了達成敏捷性，所以開發團隊要能有某種程度的共識以及具回饋 (feedback)的實務作法；利用專家與前人所提供的設計原則，使得軟體能具有彈性與易於維護；而如何平衡這些設計原則，所以也會瞭解到在特定一再重覆的問題上應用設計樣式。作者就是嘗試著要把這三種觀念成有一個有效的整體。 我覺得書中最大的特色就是，會藉由許多案例研究來說明與示範如何應用上述三種觀念，而且這些案例並非是最終的完成品而已，而是正在進行中的開發，所以讀者也會看到這些設計者所犯下的錯誤，然後他們又如何發現錯誤，進而改正錯誤。
軟體開發的關鍵在於人，而不是製程
本書的目錄綱要編排，正是反映了上述作者想傳達的三種觀念，所以分為六個篇幅，第一、二篇論及的是軟體開發流程的最佳實務與能符合最佳實務的敏捷設計原則；後四篇則是藉三個案例研討 (薪資、氣象臺、教育測驗服務)，如何應用設計樣式，來解決一些特定的實務問題。再來就是四個附錄。前兩個附錄算是對於 UML 的語法說明；而附錄C (兩家公司的諷斥)，挺特別的寫作方式，每一頁是個別描述兩家公司各自不同的開發方式，一個採需求凍結的瀑布開發、另一個採敏捷的反覆漸增開發。是一篇挺有趣的寓言式寫實故事；附錄D則是摘錄 Jack Reeves 的一篇論文：「原始碼即設計」。我覺得該篇論文真的可以精讀，可以引導與觸發讀者思考，什麼叫做軟體設計。
每一大篇，都可以各自拆開獨立閱讀。軟體開發人員，若想對樣式作個一般性的學習，可以閱讀敏捷的設計原則；而想知道作者是如何應用書中所介紹的設計樣式，則可以參考書內的三個案例研討；而若是專案經理甚或老闆，專心研讀第一篇關於敏捷式的開發流程，絕對會對現實的專案開發與管理的議題上，有很多的體會與啟發。
尤其一開始本書所揭露出來的敏捷軟體開發宣言，我覺得是相當務實地揭露出軟體開發的本質— 流程和技術是影響專案結構的次要原因，人方是關鍵要素。 太多老闆與專案經理們總是常會把他們總是很關心人的永續成長之類的話掛在嘴邊，但是又往往想要創造或導入出一套流程，藉由許多管理工具與各階段的製程產品，用來約束開發人員的活動。而靠一些約束與產出(通常是大量的文件)，但錯誤仍持續不斷發生時，管理人員卻又在某些地方設定更多的約束和產出 …，這種造成負回饋的循環，使得軟體人員過度負荷了龐大笨重的流程，而嚴重妨礙了完成工作的能力，並因而喪失了軟體的創意設計能力。
奉勸許多老闆與專案經理們，不能再自欺欺人了，仔細審思敏捷宣言所揭露出來的價值觀吧：
o 個人及互動勝於流程與工具。
o 可用的軟體勝於詳盡的文件。
o 與客戶合作勝於合約談判。
o 回應變更更勝於墨守計畫。
敏捷開發的主張—程式碼即為設計本身？
本書在“敏捷式的設計”一篇中，所引用自附錄D Jack Reeves 所主張的：「真正能符合工程設計標準的唯一軟體文件就是源碼的列表”。本來我還以為敏捷開發的主張是將程式碼當作是設計的一切，這我當然是無法認同，這可是會給一些程式設計人員藉口，只寫程式卻不需要有其它的設計文件。 我是一直覺得，程式碼既是設計(沒錯)，但同時也是設計最現實有效的產出 (artifacts)。而程式碼的呈現是綜合了包括多個觀點與層面的設計，諸如需求、結構，甚或架構，而這些是需要透過其它如設計圖，突顯出設計的焦點而隱藏了程式碼不必要的細節。還好，後來我很用力地研讀並思考 Reeves 論文的意涵，他應該指的是，程式碼本身就是一種設計。是的，這一點我是相當認同的，還有就是千萬不要認為 “設計就是一組與程式碼分離開來的 UML 圖示。”這麼說好了，我是一直這麼認為： UML 設計圖與程式碼都是設計，是軟體系統的一體兩面。”所以，個人一直主張，設計圖要作少、作精，不要作不必要的文件，且必然要時刻在開發的過程中保持與程式碼的一致性。
對於開發人員而言，要能看得懂本書所介紹的設計樣式，那就要先瞭解本書所揭露的設計原則，書中介紹了五種設計原則—SRP, OCP, LSP, DIP, ISP 等，全名與細節我就略過不提了。其實這些就是所謂物件導向式軟體設計的基本功與思維，諸如物件的責任分派、封裝的設計、相依性的分析、多型與介面的設計等。還有，讀者要瞭解，這些設計原則不是為了協助你把東西做出來，而是讓你消除程式碼的壞味道，設計壞味是一種症狀，是某種可以被主觀而非客觀量測的東西，會讓系統僵化而難以維護。不過適可而止就好，設計原則並非可以在系統中任意地到處噴灑的香水，過度遵從原則會導致不必要的複雜度的設計壞味。
書本雖然厚，討論的主題涵蓋也廣，但是內容還蠻淺顯易懂的，翻譯的品質也是相當不錯。每一個章節前頭又有很棒很炫的插圖，甚至還有作者引以自豪，是其女兒散佈在各章節裝飾性插圖的可愛作品。還有若是像我不是那麼珍惜書本完整性的話，甚至也可以將各篇分開拆下來，這樣外出攜帶時閱讀就不會那麼厚重。 看到如此言之有物的專業書籍，又不難懂，可以說是生命的喜樂之一。
