第一部分：重構(gòu)
第二部分：設(shè)計(jì)原則與代碼所有權(quán)
第三部分：進(jìn)化型設(shè)計(jì)
第四部分：靈活性與復(fù)雜性
第五部分：測(cè)試驅(qū)動(dòng)開發(fā)
第六部分：性能與過程調(diào)優(yōu)
可維護(hù)性與效率
比爾：我在丹佛機(jī)場(chǎng)的紅地毯俱樂部（Red Carpet Club）[1]中常常碰到名人。今年夏天我碰到了 Calista Flockhart （卡莉斯塔·弗洛克哈特）[2]， 而去年我碰到了你。我是個(gè)追星族，但是由于害怕哈里森·福特，沒敢跟 Calista 搭訕。不過，你和我倒是坐下來(lái)喝了杯啤酒。記得當(dāng)時(shí)你曾對(duì)我說(shuō)過，應(yīng)該以程序員能讀懂的字符格式來(lái)序列化對(duì)象，而不是以二進(jìn)制代碼格式。當(dāng)我提到字符格式 要比二進(jìn)制碼格式慢時(shí)，你說(shuō)，從效率的角度來(lái)看，二進(jìn)制代碼格式使得軟件更加難以維護(hù)。那么，能否請(qǐng)你談?wù)勱P(guān)于序列化方式的具體案例？一般地說(shuō)，你如何在 可維護(hù)性與效率之間尋找平衡點(diǎn)？
馬丁：效率永遠(yuǎn)是第一位的，前提是你能正確理解它。很多時(shí)候問題在于，人們以為做某些事情是為了效率著想，但他們卻從不使用性能分析器（profiler）。如果你出于效率的考慮而做某件事，但卻不使用性能分析器，那么你所宣稱的根本就不著調(diào)。
序列化所牽扯的問題要多一些。使用二進(jìn)制代碼做序列化的問題之一就是你無(wú)法去查看結(jié)果。當(dāng)你需要存儲(chǔ)序列化的對(duì)象時(shí)，這個(gè)問題就更加突 出。Java 的一個(gè)典型問題就是如果你改變了一個(gè)類，那么就無(wú)法讀取以前所序列化的對(duì)象。類似的，如果一個(gè)客戶端和一臺(tái)服務(wù)器正通過序列化的對(duì)象進(jìn)行通訊，假如一端的 數(shù)據(jù)結(jié)構(gòu)進(jìn)行了更新而另一端沒有，那么整個(gè)通訊就徹底失效了。
有一個(gè)小竅門可以讓你繞開這個(gè)問題。不要序列化對(duì)象本身，而是把數(shù)據(jù)從對(duì)象中提取出來(lái)，放到一個(gè)字典里，然后再序列化那個(gè)字典。這么做會(huì)使你能夠應(yīng)對(duì)一些變化。
比爾：但是，字典是“不明確的”。我們之前剛剛說(shuō)起過這點(diǎn)。
馬丁：的確，字典不是“明確的”。不過，如果你往類里添加一個(gè)字段，并把這個(gè)多出來(lái)的值放到字典里 的話，不會(huì)有什么問題。因此，這是一個(gè)比較強(qiáng)壯的機(jī)制。XML 一般也比較強(qiáng)壯，因?yàn)槟憧梢詫?duì)你所不了解的數(shù)據(jù)視而不見。二進(jìn)制序列化的主要問題就是它的脆弱性。在我的書《企業(yè)應(yīng)用架構(gòu)模式》中，更多地提到了序列化的 方式。例如，在數(shù)據(jù)庫(kù)中傳輸和存儲(chǔ)數(shù)據(jù)時(shí)，就需要考慮介于字符和二進(jìn)制之間的序列化格式。
編寫可性能調(diào)優(yōu)的軟件
比爾：你在《重構(gòu)》一書中寫道：“編寫能快速運(yùn)行的軟件的秘訣就在于先編寫可性能調(diào)優(yōu)的軟件，然后對(duì)執(zhí)行速度進(jìn)行調(diào)優(yōu)。” 我該怎樣編寫可性能調(diào)優(yōu)的軟件呢？
馬丁：只要做到軟件結(jié)構(gòu)合理就可以。
比爾：怎么講？
馬丁：因?yàn)榻Y(jié)構(gòu)合理的軟件可以更容易地進(jìn)行改動(dòng)。
比爾：也就是說(shuō)，這時(shí)候軟件要更容易地進(jìn)行改動(dòng)，不是為了添加新功能，而是為了提升已有功能的性能。
馬丁：結(jié)構(gòu)合理的軟件能夠更容易地進(jìn)行調(diào)優(yōu)。你應(yīng)該首先專心于讓軟件結(jié)構(gòu)合理、設(shè)計(jì)清晰，然后，在性能調(diào)優(yōu)器的引導(dǎo)下，完成性能優(yōu)化過程。
優(yōu)化
馬丁：還有一件事需要牢記：性能優(yōu)化與版本和具體的實(shí)現(xiàn)是密切相關(guān)的。當(dāng)你拿到 Java 的一個(gè)新版本時(shí)，一定要把以前所做的優(yōu)化都撤消，然后重走一遍優(yōu)化過程，以確保那些優(yōu)化手段仍然奏效。通常你會(huì)發(fā)現(xiàn)，你為上一個(gè)版本的虛擬機(jī) （virtual machine）或優(yōu)化型編譯器（optimizing compiler）所做的性能優(yōu)化往往使當(dāng)前的版本變慢，也即，之前的優(yōu)化手段如今往往起到適得其反的作用。
比爾：要記住以前為了提升性能都做了哪些改動(dòng)可不是件容易的事情。
馬丁：你必須這么做——先撤銷，再重新應(yīng)用。我知道這不容易。這就要求你對(duì)優(yōu)化過程中所做的每個(gè)改動(dòng)都要有詳細(xì)的記錄。要知道，舊的優(yōu)化所造成的一些微不足道的性能損失，在新的版本下有時(shí)候可能會(huì)變得非常顯著。
Craig Larman （拉曼 C [3]） 曾經(jīng)講過一個(gè)故事，我到現(xiàn)在都還很喜歡這個(gè)故事。Craig 有一次在 JavaOne 的大會(huì)上做性能優(yōu)化的講座。他提到了兩個(gè)廣為人知的技術(shù)：對(duì)象池（object pooling）和線程池（thread pooling）。對(duì)象池就是重用已有的對(duì)象，而不是每次都創(chuàng)建新的對(duì)象。線程池的原理基本類似。講座結(jié)束后，有兩個(gè)人來(lái)到 Craig 跟前。這兩個(gè)人都是設(shè)計(jì)高性能虛擬機(jī)的。其中一個(gè)虛擬機(jī)是 Hotspot，另一個(gè)好像是 JRocket。一個(gè)人告訴 Craig，線程池的效果不錯(cuò)，但對(duì)象池則使得虛擬機(jī)的運(yùn)行變慢；而另一個(gè)人告訴 Craig 的恰恰相反。
所以，你有可能在一種虛擬機(jī)上優(yōu)化了性能，但拿到另一種虛擬機(jī)上，卻減慢了其運(yùn)行速度。對(duì)此，你要特別小心。對(duì)象池就是一個(gè)很好的例子。 很多人熱衷于對(duì)象池，但起碼有一半的情況下，人們并不去測(cè)量對(duì)象池的效果到底是好是壞。在 Java 的早期日子里，對(duì)象池非常重要，因?yàn)槔厥眨╣arbage collection）功能還不是很完善。但在垃圾回收技術(shù)更新?lián)Q代之后，對(duì)象池的效果就大大降低了，因?yàn)槟切┥嬷芷诤芏痰膶?duì)象可以被低成本地回收。只 有那些生存周期很長(zhǎng)的對(duì)象，才適合使用對(duì)象池技術(shù)，因?yàn)閷?duì)它們進(jìn)行垃圾回收的成本很高。
從這里可以看出，規(guī)則也是在不斷變化的。這就是為什么要對(duì)性能調(diào)優(yōu)很仔細(xì)的原因所在。不要妄想根據(jù)源代碼就能預(yù)測(cè)機(jī)器會(huì)做什么。當(dāng)你與虛擬機(jī)或優(yōu)化型編譯器打交道時(shí)，性能調(diào)優(yōu)是唯一的手段，因?yàn)榫幾g器和虛擬機(jī)所做的事情，遠(yuǎn)遠(yuǎn)超出你的想象。記住，不要預(yù)測(cè)，要實(shí)測(cè)。
模式的意義
比爾：你在《設(shè)計(jì)是否已死》這篇文章中表示：“對(duì)我來(lái)說(shuō)，模式仍然是至關(guān)重要的，”尤其是考慮到極限編程的話。那么今天，模式處于一個(gè)什么樣的地位呢？
馬丁：模式給了我們瞄準(zhǔn)的目標(biāo)。我還會(huì)做一些預(yù)先設(shè)計(jì)。模式就是用來(lái)干這個(gè)的。模式還給了我們以重 構(gòu)的目標(biāo)。我們得以知道我們改進(jìn)的方向。了解模式還有助于我們找到設(shè)計(jì)美感，因?yàn)槟Ｊ街辽俣际且恍┖玫脑O(shè)計(jì)。你可以從它們身上學(xué)到很多。因此，我仍然認(rèn)為 模式起著重要的作用。其實(shí)，很多積極推動(dòng)極限編程運(yùn)動(dòng)的人，本身就活躍在模式社區(qū)里。這兩個(gè)社區(qū)在很大程度上是重疊的。
敏捷宣言
比爾：最后一個(gè)問題，敏捷宣言到底是怎么一回事？
馬丁：哦，那是一群投入到敏捷軟件方法領(lǐng)域的人，聚在一起，彼此印證心得。這個(gè)領(lǐng)域包括極限編 程，scrum，crystal，修錯(cuò)驅(qū)動(dòng)開發(fā)（fix-driven development），和動(dòng)態(tài)系統(tǒng)開發(fā)方法（DSDM）。我們意識(shí)到我們之間有很多共同之處，因此決定把我們所認(rèn)同的寫下來(lái)。我們把這份宣言看作是一 種象征——在這面大旗下匯聚了支持此類方法的人們。在那次聚會(huì)中，我們決定使用“敏捷方法”這個(gè)詞。這份宣言可以作為敏捷軟件開發(fā)的一個(gè)定義。借助這份宣 言，我們共同呼吁，軟件業(yè)的主流應(yīng)該朝著這個(gè)方向前進(jìn)。
比爾：讓我們來(lái)看看四條原則中的一條：“個(gè)人與交互重于過程和工具”。這是什么意思？
馬丁：這條原則大意是說(shuō)，與其借重過程和工具來(lái)加強(qiáng)對(duì)軟件開發(fā)的管理，不如更多地關(guān)注于團(tuán)隊(duì)及其成員，關(guān)注于每個(gè)個(gè)體以及他們之間在個(gè)人層面上的交互。
比爾：你是說(shuō)提升他們的技能么？
馬丁：要遠(yuǎn)比這個(gè)豐富得多。它包括了提升技能；它還包括要竭盡全力使程序員們身心愉悅，從而得以留 住人才；它還意味著更認(rèn)真地對(duì)待個(gè)性沖突，注重人與人的相處，而不是試圖找出某個(gè)完美的軟件開發(fā)過程，然后要求大家都來(lái)遵守這個(gè)過程。我對(duì)這條原則的理解 是，應(yīng)該是團(tuán)隊(duì)選擇適合其的軟件開發(fā)過程，而不是讓團(tuán)隊(duì)來(lái)適應(yīng)指定的開發(fā)過程。
盡管在那次聚會(huì)上，我們中的許多人都津津樂道于自己所采用的開發(fā)過程，并且我們當(dāng)中的幾個(gè)人還是軟件工具銷售商，但我們一致同意，對(duì)于一個(gè)項(xiàng)目的成功來(lái)說(shuō)，軟件開發(fā)過程和工具只是次要的因素，最主要的因素還是團(tuán)隊(duì)，是團(tuán)隊(duì)中的成員，是他們?nèi)诵曰暮献髋c努力。