讀 Martin Fowler設計已死？總結

 1 Planned and Evolutionary Design

 Evolutionary :code and fix bug ,會陷入越修改bug越多的情況

 Planned:按照需求分析，概要設計，詳細設計，編碼，單元測試，內建測試，版本測試，版本釋出的步驟進行開發軟體 

 結論：喜歡 planned design。因為我了解 planned design 的缺點，而且正在尋找更好的方法。

2 The Enabling Practices of XP

XP是改進的演進式設計 (evolutionary design) 而不是 planned design。

改進之處是加入一些有效的實作技巧：Testing ， Continuous Integration，Refactoring 。

3 The Value of Simplicity

XP 大聲疾呼的兩個口号是 "Do The Simplest Thing that Could Possibly Work"(隻做最簡單可以正常運作的設計) 和 "You Aren't Going to Need It"(就是 YAGNI - 你将不會需要它)。兩項都是XP實務中簡單設計的表現形式。

結論：除非到了往後的階段有所需要，否則你不會浪費精神去增加新的功能。即使不會多花成本，你也不會這樣做，因為就算現在加入這些功能并不增加成本，但是卻會增加将來做修改時的成本。總之，你可以在套用 XP 時明智的遵守這樣的方法，或是采取一種能降低成本的類似的方法

4 What on Earth is Simplicity Anyway

Kent 對簡單系統訂了四個評量标準，依序是 (最重要排最前面)：

通過所有測試。

呈現所有的意圖。－－－簡單明了的程式代碼

避免重複。

最少數量的類别或方法。

結論：Bob 大叔 (Robert Martin)的建議是不要太在意什麼是最簡單的設計。畢竟後來你可以，應該，也會再重構。願意在最後重構，比知道如何做簡單的設計重要得多。

5 Does Refactoring Violate YAGNI?

結論：YAGNI 的觀點是不要增加一些現階段不需要的複雜功能，這也是簡單設計這項技巧的部份精神。重構也是為了滿足盡可能保持系統的簡單性這個需要，是以當你覺得可以讓系統變得更簡單的時候，就進行重構

6 Patterns and XP

我對于采用 XP 的人使用 patterns 的建議：

花點時間學習 patterns。

留意使用 patterns 的時機 (但是别太早)。

留意如何先以最簡單的方式使用 patterns，然後再慢慢增加複雜度。

如果用了一種 pattern 卻覺得沒有多大幫助－不用怕，再次把它去掉。

我認為XP應該要更加強調學習 patterns。我不确定它要怎麼和 XP 的實務技巧搭配，不過相信 Kent 會想出辦法來的。

7 Growing an Architecture

結論：建議從評估架構可能的樣子開始。假如你看到将會有多個使用者使用到大量的資料，一開始就直接使用資料庫。若你看到很複雜的商業邏輯，就套用 domain model。你會懷疑是否偏離簡單的特性，這當然不是 YAGNI 的精神。是以你要有所準備，在發現所使用的結構沒有幫助時盡快簡化你的結構。

8 UML and XP

結論：

藍圖的用途是在開始撰寫程式代碼之前探讨設計内容。印象中總是覺得這樣的動作在 XP 是不合法的，但并不是這樣。很多人都說如果你遇到棘手的問題，就值得先做些設計。但是當你進行設計時：

保持簡短。

不要做得太詳細(隻挑重要的做)。

把結果當作是草圖，而不是定案。

變更設計不代表一定要更改藍圖。畫這些藍圖來幫助你了解設計，然後就把圖扔開，這麼做是非常合理的。這些圖能夠幫上忙就有它的價值了。它們不必永遠存在，最有用的 UML 圖形也不會是收藏品

9 On Metaphor (關於隱喻)

結論：人們常批評 XP 乃是基于覺得一個系統實在是至少需要一個大概的設計。XP 專家則以 "就是 metaphor 啊！" 來響應。但是我還是沒有看到一個對于 metaphor 令人信服的解釋。這是 XP 的缺憾，必須由 XP 專家來理出頭緒。

10 Do you wanna be an Architect when you grow up?

設計本身的角色來說，我不覺得 XP 不重視經驗或好的設計。事實上多位 XP 的提倡者 - Kent Back、Bob Martin、當然還有 Ward Cunningham - 都是我進而學習設計的對象。然而這也代表着他們的角色從大家既有的印象中開始轉變成為技術上司者

知道 XP 的人就能夠了解我描述的是 XP "教練" 的清楚角色。的确，在 XP 玩的文字遊戲中提到上司技術就是在描繪 "教練" 這個角色。其意義是很清楚的：在 XP 技術的上司特質是透過教導程式員和幫助他們做決定而呈現。這是一種需要良好人際管理和技術并重的技巧。Jack Bolles 在 XP2000 說：孤單的大師有點機會了，合作和教導是成功的關鍵。

在XP的Architect 扮演者教練的角色。而不是純粹的軟體的設計。他指導team中的其他人，解決他人遇到的問題

11 Things that are difficult to refactor in

我們能用 refactoring 來處理所有設計方面的決定嗎？或者，有些問題太普遍而且難以在将來加入設計中？此時，XP 的正統做法是所有需求都可以輕易的在需要的時候增加，是以 YAGNI 總是能夠适用。我猜是不是有例外？有一個不錯的，被讨論到的例子是軟體的國際化。這是不是一種現在應該立即進行，否則以後再加入時會覺得痛苦的事情

結論作者與Kent有分歧

So is Design Dead?

當然不是了，沒什麼原因，隻是設計的本質已經改變。XP 的設計追求以下的技巧：

持續保持清爽的程式代碼，越簡單越好。

重構的技巧，是以當你覺得必要的時候都可以有信心的動手。

具有 patterns 的知識：不隻是照它的解法，更要感覺何時可以應用，或是如何導入 patterns。

知道如何将設計說給必要的人了解[譯注8]，用程式代碼、或是圖形、或上述所有的工具：交談。