1.引子
我們知道單元測試、重構、code review是日常開發中的一部分，都很重要。但是在實踐中，許多團隊都忽略了這一部分，尤其是對於業務開發同學來說，項目進度一趕，自然就選擇性忽視了。我自己也一直在從事業務方面的開發，深有感觸！
很多時候，我們連單元測試都做的不夠充分，更別說重構、code review了。於是一步一步地，大多數業務開發同學就都成了拷貝粘貼代碼的CURD BOY！會覺得業務開發沒有技術含量。但其實我們知道技術是爲業務服務的，只有技術與業務有機結合起來，才能獲得完美的作品。
那麼今天，我結合我個人開發方面的一些經驗，重點給你分享一些我對重構方面的一些思考。拋磚引玉大家共同交流學習！
2.重構
2.1.什麼是重構
關於重構，我們先來看一下定義，軟件設計大師Martin Flower（就是把微服務整火起來的這位）是這麼說的：重構是指對軟件內部結構的改善，其目的是在不改變軟件外在行爲的情況下，使軟件系統更容易理解，且更容易維護。
從定義上來看，着重是說不改變軟件的外在行爲，即軟件提供的服務與能力不變，在這個基礎上，提升軟件作品的品質，比如可讀性、維護性更好，即重構的本質可以理解爲讓軟件系統代碼質量，持續處於一種可控的範圍，不至於太過腐化而難以維護。
從某種意義上來說，我們可以把重構分爲大型重構，與小型重構。大型重構主要指軟件架構層面的重構，比如說系統、模塊、代碼結構、類之間的交互關係的重構；小型重構主要指代碼細節方面的重構，比如說類、方法、成員變量的重構。
你看這就是說的重構，重點是我們需要如何去重構？以及什麼時候重構呢？我們接着往下看。
2.2.如何、什麼時候重構
原於去年我們團隊的主要任務，重構了某核心系統，在這方面有一些體會，當時我們是把一個單體應用，進行了服務化的重構，屬於架構層面的大型重構。
重構前系統是基於傳統ssm架構的單塊應用，系統在業務量、併發量、數據量、業務複雜度上都比較高，且源代碼體量比較大，好幾百兆。在這個背景下，進行的微服務化重構，重構後根據業務特徵拆分了五大業務域，近20個微服務。
結合這裏，我重點想給你分享重構過程中的一些思考。
在架構層面，對於大型重構，要求會比較高，需要有計劃，分階段、里程碑式謹慎的進行，這其中還涉及到設計思想、設計原則、設計模式的應用。比如面向對象，高內聚、低耦合，基於接口而非實現編程設計思想；比如SOLID、DRY、LOD設計原則；比如工廠、策略、觀察者等設計模式。
在編碼實現階段，我們需要持續進行小型重構，比如類的設計是否合理，函數、成員變量是否合理等。
契合小結標題，我們回答瞭如何重構，即大型重構需要有計劃、分階段進行，且需要綜合應用設計思想、設計原則、設計模式；那麼小型重構，我們需要在編寫代碼實現的時候，考慮類、函數、成員變量是否合理，對於小型重構，更多的是需要編碼規範進行支撐，編碼規範我們將在下一篇文章來分享。
那麼什麼時候重構呢？我們說重構是一個持續的過程，尤其像小型重構，在編寫實現代碼的過程中，需要持續保持代碼質量在一個可控的範圍。千萬不要面向離職編寫代碼，程序員都不容易，何苦相互爲難對吧。
關於重構，除了技能技巧，我更加想要分享給你的是要有重構的意識，我們應該做一個持續有追求，對代碼質量有潔癖。
2.3.爲重構保駕護航
很多開發同學經常會說，每每看到維護項目中前人留下的糟糕代碼，很多時候都有重構的衝動，最後愣是沒敢下手，怕改出問題！一個怕字，說出了大家的心聲對吧。
想改，改好了沒功勞，改出了問題要背鍋！這就比較麻煩了，涉及到如何爲重構保駕護航的問題。針對這個問題，我想要分享給你的答案是：單元測試。
不論是開發新需求任務，還是重構已有的代碼，我們都應該要有單元測試。當然關於單元測試，很多團隊落實得都不好，我們團隊也沒有做好。很多後端開發同學，都是開發好接口，通過像postman這樣的工具，簡單調一下接口調通後，就直接發佈到測試環境，等測試同學測試發現問題後再進行修改。
這也是爲什麼線上bug多，代碼質量不好的原因。事實上，單元測試這個事情，於後端開發同學來說，做好是非常有收穫的，有時候，我們可以通過測試反向來驗證代碼質量問題。比如說一個方法，難以給它編寫單元測試用例，那麼我們就可以思考該方法的設計實現是否不合理了，是否依賴過多，或者說不滿足單一職責、接口隔離原則等。
最後，這篇文章我們就分享到這裏了，期望給你帶來一下關於重構的思考。