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