軟體設計必讀經典(16)增加開發應變力，關鍵在於「以人為本」

《Agile Software Development》是一本相當值得一讀的書，在Amazon的評鑑中，獲得極為罕見的五顆星滿分！頁數也是少見的厚，有近700頁之多。

不過，如此深厚的內容也很實在，可不像坊間一堆OOP（Object-Oriented Programming，物件導向編程）入門書，充斥著圖形設定教學與程式碼，卻沒有內容。套一句John Vlissides（《Design Patterns》作者之一）寫給本書的推薦序：「這也許是第一本書，將敏捷方法（Agile Methods）、樣式（Patterns），以及現代軟體開發方法交織成連貫的整體。當Bob Martin 開口，你最好洗耳恭聽。」

本書主要描述軟體開發議程的3個主題：設計原則（Principle）、設計樣式（Pattern）與開發實務（Practice）。當軟體開發人員面對需求快速變動時，如何在開發的過程中具備迅速的應變能力，這就是所謂的敏捷性開發。為了達成敏捷性，開發團隊要擁有某種程度的共識，以及具回饋（Feedback）的實務作法，並且利用專家與前人所提供的設計原則，使得軟體能具有彈性且易於維護；而且因為需要去平衡這些設計原則，所以也會了解到一些方法，例如在一再重複地特定問題上應用設計樣式。

作者嘗試把這3種觀念融合成為一個有效的整體，藉由案例研究說明與示範如何應用上述觀念，是本書最大特色。而且因為這些案例並非是最終的完成品，而是正在進行中的開發，所以讀者也會看到設計者如何發現錯誤，進而改正的過程。

改善軟體開發的祕訣在於人，而不是製程

本書分為6篇，第一、二篇論及的是軟體開發流程的最佳實務，以及能符合最佳實務的敏捷設計原則；後四篇則是藉由3個案例（薪資、氣象臺、教育測驗服務），探討如何應用設計樣式，解決特定的實務問題。附錄D則摘錄Jack Reeves的一篇論文＜原始碼即設計＞，該篇論文可以精讀，能夠引導與觸發讀者思考什麼叫做軟體設計。

這本書的另一個特色是，每一個篇章都可以拆開獨立閱讀。軟體開發人員若想了解樣式，可以閱讀敏捷的設計原則；想知道作者如何應用書中介紹的設計樣式，則可以參考3個案例研討。我建議專案經理或老闆，可以研讀第一篇關於敏捷式的開發流程，能幫助你對現實的專案開發與管理議題，有所體會與啟發。

本書一開始所揭露的敏捷軟體開發宣言也很重要，作者務實地揭露出軟體開發的本質：流程和技術是影響專案結構的次要原因，人是真正的關鍵要素。太多老闆與專案經理總是常把人的永續成長之類的話掛在嘴邊，但是又往往想要創造或導入一套流程，企圖藉由許多管理工具與各階段的製程產品，去約束開發人員的活動。

設計原則幫你消除程式的壞味道

然而，當有約束與產出（通常是大量的文件），但錯誤仍持續不斷發生時，再加上管理人員又在某些地方設定更多的約束和產出，這樣反而造成負回饋的循環，使得軟體人員負荷過度龐大笨重的流程，嚴重妨礙完成工作的能力，因而喪失軟體創意設計能力。

奉勸老闆與專案經理們，不能再自欺欺人了。仔細審思敏捷宣言所揭露出來的價值觀吧：

● 「個人及互動」勝於「流程與工具」。
● 「可用的軟體」勝於「詳盡的文件」。
● 「與客戶合作」勝於「合約談判」。
● 「回應變更」勝於「墨守計畫」。

對於開發人員而言，要能看得懂本書所介紹的設計樣式，必須先了解本書所揭露的設計原則，書中介紹5種設計原則，包括SRP、OCP、LSP、DIP、ISP等，這些是物件導向式軟體設計的基本功與思維，諸如物件的責任分派、封裝的設計、相依性的分析、多型與介面的設計等。

上述設計原則的用意，不是為了協助你把東西做出來，而是讓你消除程式碼的壞味道。所謂的設計壞味是一種症狀，是某種可以被主觀而非客觀量測的東西，會讓系統僵化而難以維護。然而，設計原則並不是可以在系統中任意噴灑的香水，在使用上還是得適可而止，過度遵從原則，反而會導致不必要的複雜度。

本書雖然很厚、討論的主題範圍廣泛，但是內容淺顯易懂，翻譯的品質也相當不錯。每一個章節前頭又有很棒很炫的插圖，甚至還有作者女兒的可愛插圖作品。你如果像我一樣不是那麼珍惜書本完整性的話，甚至也可以將各篇分開拆下來，外出攜帶時就不會那麼厚重。能夠閱讀如此言之有物、可讀性高的專業書籍，可以說是生命的喜樂之一。

敏捷開發的主張：程式碼即為設計本身？

在＜敏捷式的設計＞一文，作者特別引用附錄D中Jack Reeves所主張的一句話：「真正能符合工程設計標準的唯一軟體文件，就是源碼的列表」。

一開始，我將這句話解讀成：敏捷開發主張將程式碼當作是設計的一切。不過，我實在無法認同這樣的想法，這可是會給一些程式設計人員藉口：只寫程式卻不需要有其他的設計文件。

我一直認定程式碼既是設計，但同時也是設計最現實有效的產出（artifacts）。而程式碼的呈現，是綜合了包括多個觀點與層面的設計，諸如需求、結構甚或架構。這些是需要透過其他如設計圖的做法，才能突顯出設計的焦點，進而隱藏不必要的程式碼細節。

後來，當我再深入研讀並思考Reeves論文的意涵之後，發現他應該指的是：「程式碼本身就是一種設計。」是的，這一點我相當認同，千萬不要認為「設計就是一組與程式碼分離開來的 UML 圖示。」

這麼說好了，我一直認為：「UML設計圖與程式碼都是設計，是軟體系統的一體兩面。」所以，我個人主張，設計圖要作少、作精，不必要的文件不要作，而且，要時刻在開發的過程中，保持與程式碼的一致性。

敏捷軟體開發：原則、樣式及實務（Agile Software Development）

Robert C. Martin /著

碁峰出版

售價：780元

（原文書）Amazon五顆星

《作者簡介》

王克明

台北工專五專部電子科畢業。現於HSDc軟體設計顧問團隊擔任架構師／顧問／講師。興趣為整體架構性的思考與學習、期貨投機操作與閱讀。

熱門新聞