無瑕的程式碼－敏捷完整篇－物件導向原則、設計模式與 C# 實踐 (Agile principles, patterns, and practices in C#)

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

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Robert C. Martin（Bob大叔）是敏捷聯盟的創始成員之一，也是當中付諸行動並且有所成效的成員之一。他擁有極具說服力的文筆與口才。在這些年中，不斷出書、演講、作為顧問實際前往開發現場指導，並自創「Clean」一詞，其著作還曾獲得Jolt大獎，《Clean Code》一書也成為Amazon該類別最暢銷的著作，這些都對於敏捷開發的推廣有著極重要的貢獻。

根據《Clean Code》內文的說法，《Clean Code》可說是本書的前傳，而本書是完整說明如何實踐敏捷的書籍。如果您也喜歡Bob大叔的著作，如果你也是Clean派的弟子，或者你想實際體驗敏捷開發，那麼你一定不能錯過這本書。

本書的寫作風格是循序漸進，由淺入深的，作者會先提出一個問題，然後分析問題，接著實作它，然後是檢討它，展現出初次實作時的錯誤與失策，接著就展示如何透過作者所主張的技術來解決這些問題。這是一本非常講究實務的實踐書籍。此外，本書主要使用的是C#程式碼，這是由Bob大叔的兒子Micah Martin根據C#與.NET平台的特性重新改寫Jolt得獎著作而來的，改寫幅度包含所有的程式碼與內文，並採用了更容易理解的案例來詳述敏捷開發。如果你平常使用的是其他語言，也不必在意，因為傳播的介質不重要，傳授的內容才是本書的價值所在。

對於一些技術細節，本書果真是大師級的作品，原創性極高，在UML章節中，Bob大叔示範了他如何使用UML（果真和一般人不太一樣），還示範了如何使用UML才能幫助你而非是製造混亂的來源。對於設計模式而言，除了GoF的知名設計模式之外，Bob大叔還在本書中提到幾個他自己常用的設計模式，有些可以視為GoF 23個設計模式的變形，有些則不是，但重點是這些模式都非常好用，可以應用在不同的應用場合，同時Bob大叔也釐清了，某些模式為何不該在哪些場合中使用，他是以效益來看待這件事的，而這也是本書的最大特色：務實。
 

~~~~~~~~~~~~~~本書讚譽~~~~~~~~~~~~~~

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

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

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

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

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