為什麼要重構程式碼？以及程式碼重構的實用方法

2021-06-10 15:51:00

在不改變軟體本身功能的前提下，要讓它內部結構趨於完善。

重構所帶來的的影響範圍的大小也是要做判斷的。

系統級重構：

系統內部程式碼越來越複雜，業務呼叫鏈路也交錯，難以正常的維護；

新的功能上線要付出代價很大；

造成需要重構的原因：

我見過一個公司是因為初創的時候沒有組建自己的技術團隊，app第一版是外包公司做的。後期隨著業務增加，新的功能和需求要來的時候，也是新技術總監最難的時候。

主要是因為編碼之前缺乏有效的設計，小公司在考慮成本的時候，直接在原有的功能上堆加，外加缺乏一個程式碼質量監督的機制。

其實這個很好理解，大型重構是頂層程式碼重構，整個系統和模組還有程式碼結構重構。就跟知乎將Python用Go語言重構一樣。

大型重構的時候需要我們有一定的設計思想、原則和模式的理解。這類重構要改動的程式碼非常多。

小型重構：主要是對程式碼細節把控，針對類、函數、變數等程式碼級別的重構。比如一個模組的所有命名和註釋的重構，這都算小型重構

這樣小型的重構可以降低企業的測試成本。可以在日常開發中逐一模組進行重構。

單一職責原則：就是一個類只負責一個職責，不互相依賴。但是切勿拆分的太細了，反而會降低內聚性，也會造成程式碼過多過亂，影響後面的維護性。

開放-關閉原則：在新增一個新的功能的時候原本是在已有的程式碼上擴展，現在是不在已有的程式碼上完成。

里氏替換原則：子類物件能夠替換程式中父類物件出現的任何地方，保證原來程式的邏輯行為不變以及正確性不被破壞。

介面隔離原則：一個類對另一個類的依賴建立在最小的介面。

依賴翻轉：高層模組不應該依賴低層，兩者都是依賴抽象，抽象不依賴細節，細節依賴抽象。

迪米特法則：一個物件應該對其它物件保持最少的瞭解。

想要學習重構並不是很簡單，畢竟理論基礎是一回事，不同企業面臨的實際情況不同。