對“重構”適用範圍的思考

來源:互聯網
上載者:User

  《重構》一書寫的非常好,讓我大大開闊了思路,認識到對代碼的修改是一個可量化、可重複的過程,軟體業中最缺乏的好像就是可量化和可重複的過程。

  但是和大多數介紹方法論的書相似,這本書並未對重構的適用範圍進行探討,更沒有對現實中軟體編碼工作中重構的作用和地位做出評價。當然也許這兩個問題太過廣泛,不容易下一個定論。這篇文章希望能對重構適用的範圍和重構在軟體開發過程中的位置進行一番探討,權作拋磚引玉。

  以下是對重構的受限範圍作的一個思考:

  1.對局部代碼的重構與對設計的重構是兩個完全不同的領域。雖然大規模的對代碼進行重構,也會影響到設計,但是這都是間接的影響。直接針對設計的重構包括重構API契約、領域模型、資料庫Schema等“不破不立”的系統關鍵區段。關於如何對設計進行重構,目前還沒有較好的解決方案。

  推論1:不能把針對局部代碼的重構與針對設計的重構混為一談,尤其注意不能同時進行這兩件工作,否則軟體開發可能會迅速地失控。

  2.程式正式發布之前的重構環境與程式發布之後的重構環境完全不同,發布之前,基本上所有東西都可以重構,宏觀的包括總體結構、介面、服務層API、資料庫Schema,微觀的包括一些局部代碼的改良等等。但是程式作為產品正式提供給使用者後,介面與資料庫重構的難度立刻上升。很多時候出於一些非技術原因,這兩種重構根本不可能進行。例如使用者不希望介面有任何的變動,除非介面本身已經不能滿足他的需求。資料庫重構會造成曆史資料與新資料庫Schema的不一致,而遷移資料的風險,通常使用者都不願意接受。

  推論2:產品發布之後,對介面和資料庫Schema(包括實體)的重構非常困難。

  3.根據經驗,如果試圖用重構代替事先設計,會導致重構的代價與時間成比例(甚至是指數)上升,而且通常這時進行重構的代價,比簡單修改Bug的代價更大。對於重構與設計的關係,一種更優的想法如下:在編寫代碼之前,合理的嘗試做出一個好的設計,然後在編碼過程中使用重構來解決餘下的設計錯誤。這裡的關鍵是分配設計與重構的時間比例,以達到最大的投入/產出平衡。

  推論3:重構對預先設計是一個補充,而不是替代。

  4.何時停止重構並沒有一個量化的標準,根據邊際價值遞減規律,無休止的重構會使成本上升。

  推論4:當“編程帽子”可以很容易地戴在頭上時,就沒有必要繼續重構了。如果你仍然看不到如何帶上編程這頂帽子,那麼就繼續重構。

  以下是對適於重構的情況做的一個簡單總結:

  1.改善API內部的設計。

  API發布後,通常很難對其簽名進行重構,此時可以使用重構來改善其內部設計。

  2.代碼複核時,改善局部代碼的品質。

  找到局部代碼的壞味道後,可以使用重構對其進行局部的修正。

  3.添加新功能之前,整理舊的代碼。

  添加新的功能,如果需要複用以前的一些函數或代碼,可以先使用重構使原來的函數或代碼更適於複用,然後再編寫新的代碼。

  4.設計遇到困難時,可以考慮使用重型重構來改良以往的設計,然後再添加新的設計。重型重構包括介面重構、API重構、領域模型重構、資料庫Schema重構,重型重構是有破壞性的,尤其破壞了系統內部和外部的延續性,這與普通的局部重構截然不同,因此使用的時候要格外小心。



相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。