簡單設計的五句話

今天上午的一個收穫吧，聽老人家講的Kent Beck簡單設計的五句話。並且昨天老人家還介紹我看了《重構》那本書，結合上下文的話，今天這五句話仍是頗有點意思的。

話很少說，五句話擺出來：一、測試；二、重用性；三、設計意圖明確；四、避免多餘實體；五、以上各條，按重要順序排列。

而後拓展一下這五句話，否則看起來太簡單了，有點寒酸呀。

首先，測試。測試是重構的前提，是簡單設計的前提，就是說不出多重要的重要。爲何呢，能夠說有了測試，有了完備的測試，才能放心的去重構你的code設計，提升的是confidence level。並且補充一個，昨天老人家跟我說，TDD，就是要先寫測試，再寫開發，若是你的方法須要其餘類或者service的協助，則mock起來；雖然有的狀況下，好比修改代碼或者作spike，會先寫出code，再添加測試，但仍然，寫測試的時候，only keep in mind的是業務，絕對不是實現。孩子，記得哦，業務和實現必定要分開，就好像martin fowler說的兩頂帽子，當年寫code的時候帶着一頂帽子，作重構的時候要帶着另外一頂帽子，帶着code帽子的時候就必定不修改原有代碼，只添加新功能；帶着refactor帽子的時候，就專一於refactor，對code的修改。同理，業務和實現也是兩頂帽子。

 

第二，重用性。重用性就是爲了不重複代碼，由於代碼越少，後來人對代碼進行修改的時候就越容易理解，也越容易修改。另外一方面，爲了更容易重用代碼，就要用到單一職責的原則啦，這樣的code才容易重用。duplicate code雖然對於編譯器沒有什麼影響，或者對於效率也不會產生太大影響，可是嘛，code老是要修改的，不論是需求的變化，仍是避免代碼腐壞，因此重用對編譯器能夠沒有什麼感受，可是對修改代碼的咱們，就頗有feel啦。

 

第三，設計意圖明確。這個也是爲了後來人的，讓人一看你的code就會很清晰你究竟想要作什麼。這個包括code的設計，接口的設計，也包括最直觀的變量方法命名，這個就是可讀性啦，並且想起來很重要的一件事，你去作一件事情的時候，作事情的時間必定比你提早想清楚這件事情的時間長的多。想清楚。

 

第四，避免多餘的實體。這個嘛，什麼是多餘的實體呢，老人家也給了他多年經驗的總結，很給力的兩條：第1、無重用，若是一個方法只在一個地方須要，那麼就暫時沒有必要將其提取到一個類中，而是做爲私有方法存在於當前類；第2、無修改，若是一個方法可能有多種規則，須要變化，則也應該提取。舉個例子吧，有一個processor類須要對數據進行process，可是在process以前須要作validation，那麼這個validation若是隻在這一個地方用到的話，就能夠做爲private validate方法存在，可是若是有其餘類也須要validation，那麼就能夠提取validator類，或者不一樣地方採起不一樣的validation規則，那麼能夠定義validator接口，有不一樣的實現方式，在用到validate的類中經過composition引入validation，而且經過spring依賴注入將選用的某種validator實現類注入進去。這個也是使用接口以及使用spring DI的好處啦，能夠達到loose couple哦。

 

第五，以上各條按重要順序排列。就是再次強調，測試，必定要有儘量高覆蓋的測試；必定避免duplicate code而且堅守單一職責原則；注意你的思惟必定要是清晰的，而且把這種清晰體如今code中；對了，想起來昨天老人家跟我說的另一點，在寫code的時候，必定要體現業務邏輯，用業務邏輯把實現細節包裹起來。

 

其實，還有不少想寫的，可是考慮到單一職責原則，一篇博客只談一個主題（不過貌似我中間沒有收住，仍是多說了一些其餘東西）。由於我發現，敏捷不僅是一種編碼的東東，也是一種生活方式，重構也同樣。不少思想，能夠做爲生活方式。不只僅是更快捷高效的編碼，也是更快捷高效的生活！加油加油