新公司的第一個任務-重構系統(一)

     辭職後想了一段時間，最終仍是換了個城市工做，最近剛上班，陌生的城市仍是有一股孤獨感，麻將一缺三。

 上班後的第一個任務領導就讓我重構一下系統，我下意識就回答重構坑很深，想建議小步按期重構追求慢而穩，後面瞭解了下緣由後也只能上手開始搞了。這套系統代碼量只有不到3W行代碼，不過這套系統的代碼是我見過最糟糕的代碼，十分脆弱，一個UI的類把全部的組件都耦合在一塊兒了，業務邏輯的許多行爲都在UI類中，存在幾千行的函數裏面功能不單一，沒有註釋命名也不清楚，具名變量沒有幾個都是魔數，等等等等，確實能夠說是一份會讓人奔潰的代碼。

 由於重構的任務確實可貴，因此想記錄一下本身重構過程的一些心得以及即將要踩的坑。

 下面說一下目前本身重構的思路：

1、解耦

 重構以前領導要我搞個架構設計給它，其實我認爲重構這套系統不少架構設計須要考慮的東西都不須要，最重要的仍是水平層次的UI、業務邏輯、數據庫以及設備控制解耦以及垂直層次的業務間解耦。這套系統耦合過高，開發成本真的是高，由於都是項目型開發只會修改幾行代碼適應不一樣項目尚未什麼深入認識，前幾天我問一個準備在系統增長功能的同事，是否是加個功能就步履維艱了？他回答是。

 花了點時間把系統的解耦劃分好，大體方向就確認好，也定製了一些重構過程當中的機制。

2、測試保證

 重構仍是要追求慢而穩，改的越多坑越深，很慌。

 部門內部質量保證的機制太少了，沒有靜態代碼檢查工具也沒有單元測試工具，因此重構前就先把單元測試框架給搭建起來，固然關於測試我只打算測試重要的部分，粒度太細的話整個過程成本高效果也不高，測試的目的只保證重構沒出錯。

3、重構工具

 想看看有什麼能夠用得上的重構工具，後面查了下沒什麼合適的就不打算用了。

小結

 前兩天就已經開始重構了，真的不容易，這份代碼太折磨我了，不太重構完一小部分後，代碼一會兒就讓人舒服多了，如今我只指望我運氣能比較好，坑確定在所不免只求坑不要太深。