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

Robert C. Martin, Micah Martin 著、鄧輝、孫鳴 譯、陳錦輝 審校

立即出貨 (庫存 > 10)

  • 9789864342099 b1
  • 9789864342099 b2
  • 9789864342099 b3
  • 9789864342099 b4
  • 9789864342099 b5
  • 9789864342099 b6
  • 9789864342099 b12
  • 9789864342099 b7
  • 9789864342099 b8
  • 9789864342099 b9
  • 9789864342099 b17
  • 9789864342099 b18
  • 9789864342099 b10
  • 9789864342099 b11
  • 9789864342099 b13
  • 9789864342099 b14
  • 9789864342099 b15
  • 9789864342099 b16
  • 9789864342099 b19
  • 9789864342099 b20
9789864342099 b1

買這商品的人也買了...

產品描述

~~~《名家名著》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之父,設計模式先驅

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

作者簡介

Robert C. Martin:

人稱Uncle Bob,程式設計經驗超過40年,Agile Software(敏捷軟體開發)的提倡者之一。創立Object Mentor,這是一間專注於C ++、Java物件導向、模式、UML、敏捷方法學和極限程式設計的顧問諮詢公司。
在這些領域,作者撰寫了相當多的名著,並獲得有IT奧斯卡獎之稱──Jolt震撼年度大獎。本書為該得獎作品的C#版。該得獎年度,Jolt僅頒布通用類、技術類各一本著作得獎,通用類由本書原版獲得大獎,而技術類書籍則由另一本廣為人知的《Thinking in Java(第三版)》獲得。

Micah Martin:Robert C. Martin之子,他也是一位敏捷軟體專家,本書的C#程式碼主要是由他幫忙改寫,並包含了許多.NET平台上的特性。

目錄大綱

關於本書
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 什麼是軟體