提升程式設計效率的大緻可以分三類：任務拆解（Tasking To Action）、使用高效的開發工具/架構、關注高效的工程實踐。
其中任務拆解，我們在【實戰TDD（2）：Tasking To Action】(視訊版) 中介紹了過了。
開發效率的工具/架構也才不但湧現，例如：Spring Boot、Spring Cloud、Elasticsearch 、Intellij IDEA 等為開發提供了不同領域的高效工具。
工程實踐的也涉及到很多，比如：TDD、重構、Clean Code 等。
在過往的工作經曆中，發現很多開發僅僅關注工具對開發效率的提升，當談及如何寫好代碼時卻沒有像工具/架構那樣能夠侃侃而談，究其原因是沒有關注這方面的内容。
本文将聊聊提升程式設計效率的一個利器：重構。
為什麼重構能夠提升開發效率？
主要是以下五方面原因：
- 重構能夠持續守護代碼結構，避免了設計的腐敗。
- 重構能幫助代碼更容易被了解
- 重構能夠提升程式設計速度
- 重構能夠降低 Bug 修複時間。
- 重構能夠提供的更快的應對變化的能力。
01 重構能夠持續守護代碼結構，避免了設計的腐敗。
代碼結構的流失是累積導緻的，越難看懂代碼要表達的意圖，就越難保護代碼中的設計，原本的設計也就流失的越快，設計就會腐敗的越快。
小步重構能夠持續不斷的改善代碼重點問題，将“大泥球”的代碼通過一個個小的重構動作，讓原本的設計而已維護，或者所設重構結構的清晰，讓原本沒有什麼設計的代碼，能夠更清晰的表達短期意圖。
日常工作讓重構不能持續的一個原因就是短期目的。短期目的很重要，讓我們始終聚焦在重要且緊急的任務上，但是問題是“隻是關注短期目的，而忽視長期目的”。我們可以通過技術債來讓 ROI 更高，但是同樣也需要關注長期的 ROI。是以日常工作中，我們可以借助可視化等手段，維持重構的習慣，避免讓原本花過心思的代碼變得别人嘴中腐敗的代碼。
02 重構能夠幫助代碼更容易的被了解
就如同重構的定義：在不改其行為的情況下，改善其内部結構，進而提高可了解性、降低維護成本。
我們都知道，重構的結果産生的代碼，具有良好的可讀性，并且與業務上下文相呼應。
其實，重構的過程，也能夠讓代碼更容易被了解，也更容易了解原本的泥球代碼的意圖。一邊讀代碼，一邊講發現的代碼的壞味道消除掉，讀完了代碼也有了更加清晰的代碼的結果。
《重構》一書中有這樣一句話：
Ralph Johnson 把"早期重構" 描述為”擦玻璃窗戶上的污垢，是你能夠看的更遠”。
03 重構能夠提升程式設計速度
一個人 / 團隊并不是隻寫一個方法，一個類，一個接口就結束了。而是要在一個項目中經曆幾周、幾個月、甚至幾年。項目過程中持續的重構能夠持續不斷的改善代碼的設計，并使之幹淨。團隊中并不會因為某段代碼晦澀難懂而不敢修改、不願修改（因為需要花費大量的時間去做一件産出很低的事情，但是很難做）。
相信很多團隊都遇到遺留的代碼，而那些到處散布着壞味道的代碼，正是因為這樣的代碼讓開發效率低下，甚至停步不前。
重構能夠提升程式設計速度，并不難證明。通過幾個疊代的産出的結果就可以輕松的證明，對比一下沒有重構的團隊、有部分重構的團隊、持續重構的團隊在幾個疊代後的産出結果，就會發現，持續重構的團隊産出的内容每個疊代的結果都是相對穩定的，而沒有重構的産出結構會越來越少，甚至無法響應業務提出的需求。
在遇到的開發者中有的人甚至對重構持反對看法，甚至更加偏激。問題往往是出現不清楚重構的技巧、重構的手法、重構工具的使用，和重構的實際。了解這些知識能夠讓重構事半功倍。
重構也不提倡偏激的“純重構，為了重構而重構”，面對現實工作中任務的輕重緩急，重構也有自己的原則，例如“事不過三，三則重構“。
04 重構能夠降低 Bug 修複時間
試想一下在一大坨代碼中找一個bug并修複容易，還是在結構清晰，意圖明确的代碼中定位bug 并修複的成本高。
相信絕大部分情況都是後者。重構的結果就可能是生成一些小的方法，職責單一的類，層次結構相同的代碼，在這樣的代碼中不用的擔心不了解而不敢改動，看懂了代碼即可修改。每個 bug 的上下文範圍都小，修改後的代碼影響範圍也小。總的修複時間當然小。
05 重構能夠提供的更快的應對變化的能力
現在工作中經常聽到的一句話就是”擁抱變化“。開發者如何擁抱變化？加班加點？隻能說是精神可嘉，但是方法不對。
重構産出了持續演進的代碼設計，并消除日常代碼中的壞味道，那麼當新的需求到來，或者原油的需求需要進行更新調整，原來重構的結構能夠幫助團隊提升需求的變化的響應能力。
也是複雜的業務，清晰的代碼設計所帶來的複用和響應的能力的表現也就越強。