首發公衆號《andyqian》,期待你的關注!程序員
程序員在職業生涯中,不可避免的就是接手老項目,重構歷史項目。事實證實,不管是老項目仍是新項目都會遇到這種狀況,不信你去看看一週前本身寫的代碼,是否是有很大的改進空間?對於新入行的朋友們也要作好準備,之後也或多或少會面對這樣的狀況。在面對這樣的狀況時,無論你接手前是多麼不肯意,接手後怎麼破口大罵,甚至有過無數次想放棄的念頭。但問題始終擺在那,始終須要面對。在最近一段時間裏,一直在進行項目重構方面的工做,項目不大,但在重構過程當中,依然有一些感覺,想借此機會分享出來。不過,如今去看看已經重構過的代碼,依然有很大的改進空間。數據結構
在介紹重構方法以前,下面幾個原則是很是重要的,甚至在重構時都是須要時刻緊記。不然在重構過程當中,必定會讓你十分痛苦,甚至會多幾回想放棄的念頭。性能
以最小單元爲重構點。也就是說:不要一上來看這不順眼,看那也不順眼,改了一通,到最後項目都運行不起來。單元測試
對於重構後的方法,功能點,必定要驗證經過後再重構下一個。該寫的單元測試一個也不能少。測試
對外提供的接口,不管是Rest接口仍是RPC接口,用冗餘的方式進行重構,意思是說:對已經對外提供的接口,在保證正確的前提下,內部怎麼重構均可以,但不要修改對外的數據結構。或者採用升級接口版本的形式,將老接口標記爲過期,老接口與新接口並存運行的形式。spa
之因此將其放至首位,由於我以爲這是在動代碼以前最重要的步驟。理清楚這個服務的職責,主要流程,關鍵步驟,關鍵狀態的轉換是很是重要的。若是以前有設計文檔描述了這些內容就再好不過了。咱們只須要對照着設計文檔先對系統有個宏觀的印象,再對照着文檔與代碼進行一步步查看一遍,這一遍並不須要很仔細,最主要是對涉及到的對象,數據流向有初步印象便可。若是沒有任何文檔,或者文檔已經和代碼徹底不匹配時,咱們也只能硬着頭皮經過代碼來還原文檔了。這時咱們能夠先經過代碼的執行流程,畫時序圖理清楚服務內部交互的方式,能夠經過畫類圖理清楚類與類之間的關係,能夠經過畫流程圖來理清楚數據的走向。讓比較具體的代碼形式轉換爲更抽象化的文檔形式。首先我必須認可,這是一個很是痛苦的過程,但這算的上是一個有效的辦法。同時這也是我作的不夠的地方,接到任務後一心想着鑽進代碼改這改那,卻忽視了這最重要的步驟。.net
經過上一步,對咱們須要重構的項目基本有了清晰的輪廓。到這一步,咱們最主要的職責是找出事件入口並體驗。這裏指的事件是指暴露形式,如:Rest接口,RPC服務,定時任務等形式。咱們只有體驗了流程,才能找出代碼中的壞味道。若是對項目徹底不熟悉或者只知其一;不知其二的強烈推薦用debug的模式一步一步看看代碼的執行過程,避免發生重構後形成服務不可用的慘案。這時若是遇到以爲須要重構的點,能夠先記錄下來,直到debug完成後。這時記錄下來的點,就是你須要重構的地方。若是你發現,重構完這些點都足以從新寫了,那麼,剛纔的那一遍debug對你理解流程以及注意事項是有幫助的。debug
完成前兩步後,咱們都應該對流程,數據流向都很是熟悉了。如今來修改代碼再合適不過,但在修改前,我依然建議你們用冗餘的方式進行修改。也就是說:此時咱們還不要急着刪除原來的代碼,建議從新起一個單獨新的內部方法,進行編寫,單元測試,在入口修改成重構後的方法,再進行集成測試,驗證,直至上線。重構代碼線上驗證經過後,再刪除老代碼也何嘗不可。咱們在軟件開發時,崇尚「小步快跑,快速迭代」的迭代思惟,一樣的,我建議重構也應該是這樣的,不建議修改了很是多或所有重構完成再進行驗證,這樣不管驗證時間仍是驗證範圍都是不可接受的。設計
寫單元測試是一個神奇而無味的工做,神奇在於它能挖掘出不少低級,甚至想抽本身巴掌的錯誤,無味在於你們認爲這是一項毫無技術難度的苦差事。卻不知在重構項目時,單元測試也發揮了及其重要的做用,咱們能夠經過單元測試來熟悉項目,熟悉流程,熟悉每個方法,熟悉每一個數據的走向。在重構完成後,咱們也應該編寫單元測試進行驗證,在代碼修改後,咱們也應該對單元測試進行修改,進行驗證,保證代碼與單元測試是一一對應且同步的。3d
固然,重構過程當中,除了單元測試外,也須要本身進行功能性測試,更須要測試同窗的功能測試,邊界測試,性能測試等等。總之,重構過程,是一個合做的過程。
其實不論重構項目,仍是入職新公司熟悉項目,均可以使用上面的方法進行實踐。經過上面這些步驟,基本上能對項目加深影響,可以讓本身對項目有個更深層次的理解。如今回顧看看本身前一個月,前一週的代碼都有不少須要修改,值得精進的地方。嗯,代碼須要迭代,系統須要重構,你我也需精進!
嗯,嘮叨了這麼多,也算是對最近重構工做的覆盤吧!
相關閱讀:
《軟件之路》
掃碼關注,一塊兒進步
我的博客: http://www.andyqian.com