.

~~~《名家名著》03  V.S. 《無瑕的程式碼》03~~~

小記者︰能說說你對《無瑕的程式碼──敏捷完整版》的讀後心得嗎？
工程師︰自從讀了這本《敏捷完整版》之後，我再也不怕面對那些慣老闆、慣客戶了。而且客戶滿意度、專案完成度都一百分呢！

這本書是《無瑕的程式碼》系列書的第三冊，也是《名家名著》系列書的第三冊。主題是「敏捷開發」，而重點仍舊是回歸到「如何撰寫出好的程式碼」。

什麼是「敏捷開發（Agile Development）」呢？簡單來說，它是軟體開發的一套方法，特點是只要透過這套方法，就能使你的專案更敏捷。

我們為何非得要讓專案變得敏捷呢？原因無他，就是因為我們有慣老闆、還有慣客戶。也就是說，對於現今的市場環境而言，專案不夠敏捷是不行的。這一點，相信所有的軟體工程師都無法否認吧！

可是你可能會反駁說，各行各業都有慣老闆和慣客戶啊（至少在台灣是這樣），為什麼軟體業就要一套特別的方式來應付他們呢？這就是要回歸到一個最根本的問題，「什麼是軟體？」，或者更精確地說「什麼是軟體設計？」，而這個問題和所有的軟體工程師（或程式設計師）習習相關，因為這是工作的本質。

各式各樣的工程有著所謂的程序，例如橋樑工程師會先進行結構分析，他們會建立電腦模型並進行模擬，接著他們會建立比例模型，並在風洞中或用其他一些方法進行測試。當這些程序都完成了，才會將設計圖交給橋樑的建造工人去建造出真實的橋樑。

以上是橋樑工程的開發程序，那麼軟體開發的程序呢？在很久很久以前（真的是很久很久以前了），軟體開發也發展出了所謂的程序，也就是瀑布型開發程序。在瀑布型開發中，系統分析師會依照需求與規畫，畫出所謂軟體的設計圖（例如UML圖），然後由「程序員」根據這些圖去寫出程式碼，最後建置（build）成可使用的軟體。

依照瀑布型開發程序開發出來的軟體，客戶只能選擇要用，還是不要用。不要用的話，是否有其他選擇？如果沒有，那麼客戶即便不滿意，也就只能將就著用（只是邊用邊罵而已）。當然，這是指套裝軟體的開發而言。

用一個例子來做比方，數十年前，台灣只有國道一號的日子，一位民眾想要開車從彰化到新竹，就只能有一個選擇，即便他不滿意苗栗那段高爬坡會折損車輛壽命，他也別無選擇。但當國道三號建造完畢後，他就有了第二個選擇，因此他會選擇他喜歡的國道來行使。建造國道的總經費是昂貴的（無論是時間還是金錢），但最貴的部分是在於建造部分，而非設計部份。所以國道並不多。競爭者很少。但這種商業模式在軟體業是行不通的。

若用早期的瀑布型開發程序來對比於國道建設，真正的建造部分，其實就是軟體建置（build）的部分，這部分只要一台電腦，一個編譯器，一個連結器，還有一點點的時間就完成了。所以代價是極低的。或許有人會說，不對，建造的部分應該也要包含按照UML圖去Coding的人工與時間成本。所以這部分的代價應該也是昂貴的。

這種說法表面上看似合理，但有多少程式碼是完全依照UML圖編寫的呢？在撰寫程式碼的過程中是否會修改原有的UML設計呢？早期這類情況並不嚴重，但晚期因為客戶的挑剔，這種情況早就屢見不鮮，甚至任何軟體工程師在開發專案時，心中早有預期會出現需求發生變化的情況。

國道的建造工人是無權修改設計圖的，他只能「按圖施工」。而程序員卻去修改了設計圖，這將使得設計圖無法作為最終產品的設計文件。因此，在這種情況下，最終產品的設計文件其實只有一份是準確的，這份文件就是「程式碼」。同時，在這種情況下，程序員應該已經不再只是「程序員」或「碼農」了，因為他參與了設計，換句話說，他應該稱之為程式「設計師」或軟體「工程師」。（在敏捷開發中，並不只有那些繪製UML圖的才叫做設計人員，正確地說，繪製UML圖的人常常也是負責寫程式的人）。

好的，如果你已經承認「寫程式」也算是「設計」的一環，那麼軟體建置（build）的成本（也就是軟體的建造成本，而非設計成本），應該是無庸置疑的低廉了。這也就是為什麼，客戶說，那邊改成XXX顏色，可以嗎？你會很乾脆地回答，當然沒問題，然後五分鐘內就給客戶看改完之後的結果。想一想，如果要改的是一整段國道護欄的顏色，相信沒有客戶敢做這樣要求，因為他們能預期到，這會花很多很多的錢。

所以說，建造軟體的花費是很少的，大多數的錢都是花費在「設計」上的。但對於其他工程就不一樣了，設計花費的錢相對於建造花費的錢來說，低廉了許多。

也就是軟體的這種特殊性，導致了客戶（更有可能的是上司）常常想要東改改、西改改，需求常常在變化。在現今這個快速變化的世界裡，慣客戶與慣老闆們為了競爭優勢（他們心中的競爭優勢），提出需求的變化根本是家常便飯。

在確定了「需求會變化」、甚至是「會頻繁地變化」這個軟體工程師一定得面對的事實後，軟體工程師該怎麼辦呢？有一群大師級的軟體工程師，開始發明了一系列因應的對策，包含設計模式、極限程式設計、測試驅動開發等等的技藝，還總結了一些物件導向的設計原則。這些都有助於應付變化。最終，這些人集合起來成立了一個「敏捷聯盟」，取名為敏捷（Agile），意思是軟體開發者及軟體本身應該如何敏捷地應付需求的變化，當中牽涉到的範圍極廣，從成員的組織到程式碼的組織都必須敏捷起來，這是門現代軟體設計的顯學，國外大廠早已採用多年。

Robert C. Marti...

關於本書

Section I 敏捷開發
Chapter 1 敏捷實踐
Chapter 2 極限程式設計概觀
Chapter 3 計畫
Chapter 4 測試
Chapter 5 重構
Chapter 6 一次真實的程式設計場景

Section II 敏捷設計
Chapter 7 什麼是敏捷設計
Chapter 8 SRP：單一職責原則
Chapter 9 OCP：開放－封閉原則
Chapter 10 LSP：Liskov替換原則
Chapter 11 DIP：依賴反向原則
Chapter 12 ISP：介面隔離原則
Chapter 13 寫給C#程式設計師的UML概述
Chapter 14 使用UML
Chapter 15 狀態圖
Chapter 16 物件圖
Chapter 17 使用案例
Chapter 18 循序圖
Chapter 19 類別圖
Chapter 20 咖啡的啟示

Section III 薪水支付案例研究
Chapter 21 COMMAND模式和ACTIVE OBJECT模式：多功能與多任務
Chapter 22 TEMPLATE METHOD模式和STRATEGY模式：繼承和委派
Chapter 23 FACADE模式和MEDIATOR模式
Chapter 24 SINGLETON模式和MONOSTATE模式
Chapter 25 NULL OBJECT模式
Chapter 26 薪水支付案例研究：Iteration 1
Chapter 27 薪水支付案例研究：實作

Section IV 打包薪水支付系統
Chapter 28 包和元件的設計原則
Chapter 29 FACTORY模式
Chapter 30 薪水支付案例研究：包分析
Chapter 31 COMPOSITE模式
Chapter 32 OBSERVER ── 演化為模式
Chapter 33 ABSTRACT SERVER、ADAPTER和BRIDGE模式
Chapter 34 PROXY和GATEWAY模式：管理協力廠商API
Chapter 35 VISITOR模式
Chapter 36 STATE模式
Chapter 37 薪水支付案例研究：資料庫
Chapter 38 薪水支付系統使用者介面：MODEL VIEW PRESENTER

Appendix A 兩間公司
Appendix B 什麼是軟體

本書讚譽

這也許是第一本把敏捷方法、模式和最新的軟體開發基本原則完美結合在一起的圖書。當Bob Martin發言時，我們最好洗耳恭聽。
John Vlissides ──《設計模式》作者

這本書中充滿了對於軟體開發的真知灼見。不管你是想成為一個敏捷開發人員，還是想提升自己的技能，本書都同樣有用。我一直在期盼著這本書，它沒有令我失望。
Erich Gamma ── JUnit之父，《設計模式》作者

我期待這本書已經很久了，關於如何去掌握我們的行業技能，本書作者擁有非常豐富的實際經驗可以傳授。
Martin Fowler ── 軟體開發大師，《重構》作者

前幾天，我找到了記有我對Bob大叔第一印象的備忘錄。上面寫著'優秀的物件思維'。你手中的這本書就是能讓你受益終生的'優秀的物件思維'。
Kent Beck ── 軟體開發大師，JUnit之父，設計模式先驅

讀過無瑕的程式碼，一定要再讀「敏捷完整篇」，否則就是您的損失，它會解答您所有的疑惑。
《博碩文化》、《名家名著》 總編輯 ── 陳錦輝