09｜TDD中的驅動（2）：重構發(fā)揮了什么作用？
從“驅動”的角度講须妻，TDD 并不是一種編碼技術仔蝌，它無法驅動你寫出你不會實現的代碼。TDD 是一種架構技術荒吏，它能通過測試與重構敛惊，驅動單元的劃分以及功能的歸屬，因而是一種更為落地的架構軟件的方式绰更。
在 TDD 中瞧挤，重構是和測試一樣重要的驅動力，驅使我們得到更好的架構和更清晰的代碼結構儡湾，因而熟練掌握幾種常用的重構手法特恬，也是十分必要的。
語義化的查找替換（Semantic Find and Replace）
首先要介紹的重構手法是提取方法（Extract Method）和內聯方法（Inline Method）徐钠。這是最重要的兩種重構手法癌刽，它們相當于查找（Find）/ 替換（Replace）。所不同的是，這種查找替換是語義化的：在不破壞現在代碼結構的前提下显拜，完成查找替換衡奥。
方法替換實現步驟
- Extract Method
- 舊方法delegate給新方法
- Inline Method
通過提取 / 合并單元進行重架構（Extract and Merge Units）
在提取方法的基礎上，我們可以進一步將提取出的行為從當前對象中分離出去远荠，也就是提取對象（Extract Object）杰赛。
通過這些重構手法，我們對類結構進行了調整矮台，也就是模塊的重劃分和功能的重分配乏屯。這就是對已有代碼的重架構（Re-architecture）。
到此為止瘦赫，我們介紹了重構的基本手法辰晕。通過這一組操作，我們可以完成對于代碼的修改确虱，以及對于架構的調整含友。這些手法如此基礎，應該被看作修改代碼的基本功校辩，而不是重構：談不上什么消除壞味道窘问，就是高效修改代碼而已。
使用多態(tài)替換條件
組合使用這些基礎手法宜咒，我們就可以進行一些更大規(guī)模的重構惠赫。比如我們之前在 Args 例子中展示過的使用多態(tài)替換條件分支。
我們消除了壞味道并強化了開放封閉原則（Open-Closed Principle故黑，OCP）：新增的類型解析不需要修改 Args 的實現儿咱，可以通過擴展 OptionParser 接口實現。對修改封閉场晶，對擴展開放混埠。
這種架構改進方法叫做重構到模式（Refactoring to Patterns），即：將架構上的壞味道替換為設計模式（Design Pattern）诗轻。這是一種更有效的架構軟件的方法钳宪，用公認的好設計（模式）替換了公認的不好的設計（壞味道），還能滿足功能的需求扳炬，必然能是更好的架構（而不用虛無縹緲地歸結于“品味”或“經驗”）吏颖。
對于 TDD，行業(yè)中存在這樣一種困惑：從功能測試出發(fā)鞠柄，逐步完成軟件開發(fā)侦高，這或許沒問題嫉柴。但架構怎么辦厌杜？實際上，紅 / 綠 / 重構循環(huán)中的重構就是解決架構問題的。只不過架構并不是預先設計的（Upfront Design）夯尽，而是在完成功能的前提下演進而來的瞧壮，因而也稱演進式設計（Evlutionary Design）。
通過重構到模式演進式地獲得架構匙握，是一種實效主義編碼架構風格（Pragmatic Coding Architect）咆槽。這是習慣了預先設計的 PPT 架構師們不曾體驗過的經歷，因而不被理解也是很正常的了圈纺。
順便說一句秦忿，Joshua Kerievsky 在 2004 年寫過一本書，就叫 Refactoring to Patterns 蛾娶。這本書的價值遠被低估了灯谣，是關于軟件架構非常重要的著作！
此外蛔琅，如果無法借助自動化重構工具高效修改代碼胎许，那么 TDD 帶來的效率將會大打折扣。而無法支持這幾個核心手法的 IDE罗售，也不足以支撐 TDD 的實施辜窑。（VSCode對重構的支持并不友好，所以考慮采用JetBrains的系列工具寨躁。學會使用IDE完成這些重構穆碎。）
