如果你認同 簡單設計的價值觀，我相信 解析簡單設計原則 對你來說很容易理解並接受，它不像物件導向設計原則（比如：solid）那麼晦澀難懂，它給你指明了一條明朗可通行的道路。即便如此，前進的道路依然不是一帆風順，尤其對於新手來說，怎麼將這些已經很接地氣的原則更高效地落地，從而創造更大的價值，本文我將分享幫助我們落地簡單設計的三板斧：tdd、重構和整潔**。
假如讓你去建造一幅巨大的廣告牌，你會怎麼做？從大框架來看，首先要打牢地基，再使用結實支柱做支撐，最後在頂部掛上廣告牌。地基和支柱是幫助完成目標的必備條件。那麼，如何實現簡單設計的核心價值？我們可以以簡單設計價值觀、簡單設計原則做為地基，並通過打造tdd、重構 和 整潔** 三大支柱來支撐起簡單設計的 「廣告牌」：
作為極限程式設計的一項實踐，測試驅動開發經過被大量的開發者證明是一項具有實用價值的實踐。從廣義上講，tdd不限於開發人員在編碼的過程中先寫測試用例，然後驅動出**實現，就連我們拿起乙個待實現的使用者故事[1]，在腦海中開始構思如何去驗收這個功能，也是乙個tdd的過程，只不過這個t存在於你的大腦中，沒有被視覺化出來且不能復用。
test driven development
test driven design
task driven development
test driven development
測試驅動開發，它是tdd在操作層面的落地方式，也是最普適的含義。它遵循乙個基本流程：寫測試 -> 執行測試（紅） -> 寫實現 —> 執行測試（綠）。在tdd中融入重構步驟之後，它的乙個具體詳細的完整流程如圖所示：
test driven design
編碼如藝術，優秀的程式設計師即是一名設計師，也是一位藝術家作為一名用**改變世界的程式設計師，我們應該試圖將自己的設計思想融入到**中，讓**充滿生氣和靈性，從而遠離機械式的殭屍**。在解析簡單設計原則 一文中我談到設計不足和設計過度時所催生三類問題：
難以修改
難以測試
難以閱讀
tdd能讓我們在編寫測試的時候就開始思考即將實現的功能**的可測試性。試想如果我們在編寫測試階段就舉步維艱，此時不得不逼著自己去思考如何讓api能夠利於測試。這個過程主要面臨了兩方面的挑戰：
視角切換。從使用者視角出發，將腦海中的隱性驗收測試落地到**層面。
api設計。如何讓api更加職責清晰、內聚，從而更加有利於測試。
這些挑戰對開發人員的設計思維提出了較高的要求，所以也能理解不少新手在起步階段頗為痛苦，以至於他們會覺得tdd降低了開發速度，對它的價值產生了懷疑。
從我個人經驗以及身邊一些大牛身上總結出乙個結論：掌握tdd最好的捷徑是刻意練習。所以如果你剛起步，不要氣餒，找一些kata勤加練習[2]
task driven development
任務驅動開發，強調的是將大任務拆解成小任務。人的大腦在處理足夠簡單的問題的時候（比如1+2-3+4-5 = ？），能夠快速給出方案。然而，面對較為複雜的問題的時候（比如2-1*5*3/2+2-3/2-2/1*5+4-5 = ？），大腦難免捉會襟見肘，此時就有必要借助一些輔助工具來做到事半功倍。
任務驅動的方式會用到乙個思維工具 – tasking[3]。在練習tdd時，建議你將待完成的任務進行分解，然後將分解後的子任務視覺化出來。視覺化的好處之一是它可以作為溝通的工具，去收集反饋，進而完善自己的思路。任務拆解之後的好處是，待實現的功能更加小而單一，有利於編寫測試。
tasking同樣需要刻意練習，它對分析性思維提出了一定的挑戰，練習分析性思維的四步法：
定義問題 - 清楚定義問題
分解問題 - 將問題進行分解
關聯問題 - 通過輸入和輸出尋找子問題的關聯關係
限界問題 - 識別出子問題的邊界，明確假設和結果
重構，它是極限程式設計中的一項實踐，martin flower在 《重構：改善既有**設計》
[5] 一書中對重構進行了全面的定義。它提倡我們對**最佳實踐充滿敬畏之心，在不改變軟體行為的前提下去修改**，不斷改善**的設計，提公升軟體的響應力。
作為程式設計師，我們經常在修改**，在修改之前，建議你先問自己四個問題：
軟體已經工作，還需要修改這段**？ - 軟體可工作，可能有壞味道
如何識別這段**浮現出的壞味道？ - 換味道是什麼
針對壞味道，我們應該怎麼修改？ - 怎麼去壞味道
修改完之後，如何確保功能沒有發生變化？ - 軟體可工作，壞味道變少
四個問題環環相扣的，始於目標，終於目標。你若能給出答案，並形成閉環，便實現了重構的核心價值。通常最難回答的是最後乙個問題，以至於遲遲不敢下手，導致軟體逐漸惡化。所以重構提倡重構要在測試的保護下進行，人工測試亦或自動化測試，只要能給出正確的答案。
重構是一門手藝活，在日常編碼中，你應該始終保持警惕，積極思考上述四個問題，另外輔以大量的刻意練習[5]，同時我強烈推薦你以*《重構：改善既有**設計》*[6] 這本書作為起點。
結合tdd，重構大有用武之地，測試先行保駕護航，重構演奏，方能唱出悠久的歌聲。然而重構到什麼程度？讓整潔**來回答這個問題。
盡量不重複
盡量揭示意圖
盡量簡單的
小到變數命名，大到類互動設計，我們應該在意識中不斷強化對以上三點的認知，在實踐中養成良好的編碼習慣。
robert c在*《**整潔之道》[6] 一書中提供了很多案例，另外《編寫可讀**的藝術》*[6] 也是乙個很好的開始。理論結合實踐，在日常開發中，建議你在團隊中組織code review[7]，它是乙個難得的學習提公升機會。
tdd、重構和整潔**並不能直接讓我們設計出來的**就天生符合簡單設計。tdd帶我們開了乙個頭，一旦開始了，在過程中不斷地審視自己的**，並通過重構來讓**變得整潔：
使用者故事是極限程式設計中的乙個實踐，請參閱 我在thoughtworks中的敏捷實踐
有關tasking更多解讀，歡迎閱讀thoughtworks仝鍵老師的 像機器一樣思考系列文章
關於重構的練習，歡迎以 glidedrose 案例作為開始
關於程式設計方面的書籍，歡迎從我的github programming-books 庫中獲取
posted by 袁慎建@thoughtworks
銷售三板斧
1 扎好馬步 把產品知識背的滾瓜爛熟，隨時考核 長期 制定懲罰措施，基本本沒紮好，不能去見客戶。2提煉話術摸著石頭過河，對客戶可能問到的各種可能提煉出行之有效的話術，熟讀於心，隨時考核 長期 模擬測試。3 多見客戶，不斷調頻，鍛鍊在實際壓力環境下的發揮能力 產品專注 兒多母苦，要鎖定高利潤 值的產品...
成功CRM的三板斧
沒有人不知道crm專案規劃的重要性，但如何成功地完成crm專案規劃就仁者見仁 智者見智了.經過了一段時間的考驗和沉澱之後，crm專案實施的總體效果如何，如何更成功地完成企業的crm專案，需要深層次地總結。不同的行業 不同的企業規模和企業性質對crm顯然有不同的需求，因此在企業確定需要crm的同時，一...
DevOps的三板斧 Strace
話說這些天電視上正在熱映 隋唐英雄 雖然我並沒有看，但是對當年田連元老先生的評書聯播 隋唐演義 卻是記憶猶新，特別是故事裡面講到的程咬金的三板斧 拍蒜瓣 戳腳指甲蓋 胡椒麵，每每聽來總是讓人忍俊不禁，不過這些貌似無厘頭的招數在實戰中卻往往有出奇制勝的效果，由此可以見簡單實用永遠都是硬道理，在當前這個...