重構、重新架構、再設計與重寫的區別
在稍早的文章評論裡,Jon Eaves 表達了把重構做為動詞過度使用的憂慮。尤其是重構(refactoring)【注1】和重新架構(rearchitecting)之間的界線非常模糊,重構被用作在你回頭做第二遍的、任何行為的標籤。你明白嗎?Jon 是對的。
被 Martin Fowler 定義的重構,是一個非常具體的術語,以數學上等同的具體術語為基礎【注2】。重構是關於小的、“行為保留”的增加的、安全步驟。重構不是在應用程式裡回頭去“填充空白”的藉口。
讓我們給出一些具體的例子來說明什麼不是重構,下面的行為都不被視作重構:
- “優化”(又稱作增加)錯誤處理。
- 增加日誌
- 勉強塞滿另一個功能
- 提高測試覆蓋率(雖然它非常接近重構了)
- 當老闆不在的時候,玩掃雷遊戲
重構是“優化現有程式碼的設計”。在本文,優化意味著使之更加易於理解和/或更加靈活。下面的行為都被視作重構:
- 把臃腫的方法拆分成較小的、功能集中的方法。
- 重新命名變數和引數,使之更有意義。
- 把功能從一個類移到另一個類(更加適當)。
- 基於一個類的方法,產生一個介面,然後讓這個類實現該新介面。
注意,我說的這些可以是重構的行為。決定它們是否屬於重構的大部分因素在於你是如何去做的。重申:重構行為,是小而安全的步驟,最好是可逆的步驟。如果你不得不考慮它是否可以執行,那麼它就不再是重構行為了。
那麼如何區別重構與重新架構或再設計呢?重構是在鍵盤上完成的,接觸真正的程式碼。而重新架構,最好是在白板上(或最近的酒吧)完成的。重新架構涉及了較大的願景,考慮下一週/月/年的規劃。重構是你用來幫助自己達成目標的技巧之一。
再設計(Redisigning)是一個術語,覆蓋了任何時候你正在重新考慮的設計決定。由於敲程式碼是設計行為,甚至到了打字階段,再設計肯定 包含重構。畢竟,如果你不稍微再設計,就不太容易提高設計。然而,在通常情況,“再設計”意味著放棄老的解決方案,提出新的解決方案,或多或少地從頭開 始。如果你在白板上做再設計,可能是沒問題的,與重新架構的舉動類似,你仍然可以通過重構達成目標。如果你在鍵盤上完成再設計,這就不是重構了。
重寫(Re-writing)類似再設計,不過它只是在鍵盤上完成。重寫通常是受到了頭痛的傷害,但是它常常讓你丟掉惰性而到達一個更好的地方。類似拍賣和搬到了印度班加羅爾。
在實戰中,會遇到混合的情況。重構應該是一個開發人員使用的日常程式的一部分,當你這樣看的時候,界線會變得模糊。比如:
- 注意,你需要在業務邏輯裡為第二種部件增加支援,這是一個設計行為。
- 從現有部件抽出一個新的介面類,在此過程中重新命名現有部件,這是一個重構的行為。
- 用新介面代替部件類的所有適合的引用,是一個重構行為。
- 開發第二個部件,增加到應用程式裡,是一個設計行為。
如果你最初開發了兩個部件,後來才注意到公用的情況,該怎麼辦?好的,這是重構行為,可能要集中在以多型取代條件式的重構上。但是從外部看,這可能看起來非常像重寫;必定(相對地)大量程式碼要消除掉。但是,不管你用什麼方式削減,寫第二個部件就不是一個重構行為。
重構更傾向於保持程式碼簡單、靈活,而不是做對事情。做對事情經常涉及到新增新程式碼,或再設計應用程式的大塊功能。使其靈活只是為了使其更加容易。這樣說的話,重構最好被看做是一項賦能(enabling)行為。
如你所知,如果我寫這篇文章不是在深夜,或許本文會更加連貫:) 如果你想更多瞭解重構,去看看 Fowler 的書。
- 注1:程式碼重構(英語:Code refactoring)指對軟體程式碼做任何更動以增加可讀性或者簡化結構而不影響輸出結果。http://zh.wikipedia.org/wiki/%E4%BB%A3%E7%A0%81%E9%87%8D%E6%9E%84
- 注2:重構這個術語是從數字與多項式的因式分解類比而來[1]。如,x2 − 1 可以被分解為 (x + 1)(x − 1), 這樣揭示了前面的形式不可見的內部結構(如兩個根 +1 和−1)。同樣,在軟體重構中,在可見結構上的改變通常會揭示原始碼中“隱藏”的內部結構。http://zh.wikipedia.org/wiki/%E4%BB%A3%E7%A0%81%E9%87%8D%E6%9E%84
原文:Software is too expensive to build cheaply…. 來自: labazhou
相關文章
- 重建模與重構的區別
- Java—重寫與過載的區別Java
- 超融合架構與傳統IT架構的區別架構
- X86架構與ARM架構的區別:架構
- 【架構與設計】常見微服務分層架構的區別和落地實踐架構微服務
- 重構改善既有的程式碼設計(重構原則)
- 我的Android重構之旅:架構篇Android架構
- 重構-改善既有程式碼的設計(六)–重新組織函式函式
- 分散式重複提交問題架構設計思路分散式架構
- 抽取思維(重構設計)
- 告訴你架構師與程式設計師的區別在哪裡架構程式設計師
- 唯品會架構師是如何實現架構重構的架構
- b/s架構和c/s架構(重點)架構
- 方法重置和重寫的區別
- 過載和重寫的區別
- Feed流系統重構-架構篇架構
- 軟體架構, 軟體框架,設計模式的區別架構框架設計模式
- “整潔架構”和商家前端的重構之路架構前端
- 區塊鏈架構設計區塊鏈架構
- SOA架構和微服務架構的區別架構微服務
- 架構師,別再扯淡了!架構
- 《重構——改善既有程式碼的設計》感想
- C++中過載、重寫、重定義的區別C++
- 重構:改善既有程式碼的設計(第二版讀書筆記) - 重構、壞程式碼、寫好程式碼筆記
- 利用WMRouter 重新架構設計業務模式架構模式
- 分散式架構和微服務架構的區別分散式架構微服務
- H5架構和原生架構的區別H5架構
- 使用Lambdas重構工廠設計模式設計模式
- 重構 - 設計API的擴充套件機制API套件
- iOS-APP重構之路(二) Model的設計iOSAPP
- 物件導向重寫(override)與過載(overload)區別物件IDE
- 程式碼重構與單元測試——“提取方法”重構(三)
- 架構團隊如何重構內部系統架構
- 重構
- 架構設計之架構的演變架構
- 程式碼重構之法——方法重構分析
- FE.BASE-前端設計模式、編碼與重構筆記前端設計模式筆記
- 系統重構的道與術
- 架構設計 | 介面冪等性原則,防重複提交Token管理架構