|
|
本文是從 Code Refurbishment 這篇文章翻譯而來。
我們這個行業里有大量的專業術語被使用。不幸的是，我們并沒有對每個術語表達的究竟是什么意思達成共識。我經常聽到人們誤用“重構(Refactoring)”這個詞，導致這種編程方法在很多企業里變成可怕的事情而被拒絕采用。怕什么？據我的觀察，大部分都是因為錯誤的使用了這個術語。
我認為，因為沒有對專業術語的使用嚴加管理，致使整個行業的發展受到連累。如果一個化學家對另一個化學家說“我們準備做滴定(titration)試驗”，所有人都清楚的知道是要干什么。我相信計算機科學仍然是一門非常不成熟的科學。如果這個科學能夠成熟起來，我們對專業術語的使用就會更加精確和有章法，這樣我們的交流就會更加的精確和有效。
重構對于代碼質量和可讀性的改進是一種非常有效的技術方法。精確的描述：它是一種為了將來的維護和理解而對代碼進行改進的一種限制性的修改行為。一個好的例子：把重復的代碼提煉成一個方法，所有出現了這重復代碼的地方都使用這個方法來代替，以此消除重復。重構是在上世紀90年代早期被第一次提出來討論的概念，1999年代Martin Fowler的大作《重構》出版之后成為業界普遍接受的技術方法。
重構會導致代碼的內部結構發生一些小的變化。這些變化原則上不會對外部產生任何影響。規范的單元測試只從外部來檢查代碼的行為，是不會發現這些代碼是被重構過的。如果代碼的結構變化時導致了代碼的對外行為發生變化，那這不是重構。
可是，為什么我們的企業的相關人士當聽到這么簡單而且有用的“重構”技術時會裹足不前呢？我認為這是因為程序員實際上說的是一種更加復雜、成本更高的結構調整技術，因為沒有一個合適的術語來表示，就把它叫做“重構”了。重構里的結構調整通常不是代碼的推倒重寫，很多的現有代碼都要重用。人們對此害怕的原因是，他們不知道水有多深，一旦掉進去將要付出多少時間，而且懷疑這種行為能帶來多少的好處。
上面說的結構上發生重大變化的例子讓我想起來一個新業主接管一個飯店或酒吧后會做的事情。新主人通常會對飯店進行重新裝修，讓它看起來更有吸引力，更舒適。飯店建筑的大部分都會被保留和重用，這比完全重建會減少大量的成本。依我的經驗，當程序員使用“重構”這個術語時，他們真正的意思是，代碼庫中的某些模塊或有邊界的上下文內容需要進行重大的修整。如果我們把這個術語定義清楚，讓相關人員知道它的目的和意義，那我們就能對項目進行更好的計劃和管理了。
這些代碼的修整活動必須在之初有清晰的目標，所有的變動必須按照要求進行測試。例如，當我們對業務有了新的認識后，會發現代碼沒有真正的反映出業務模型。這種認識經過一段時間后不斷的積累，代碼開始不再滿足業務需求。如果使用領域驅動設計(Domain Driven Design)，業務模型的本質會被看的更清楚。當對業務有了新的理解后，代碼需要大調整來適應新需求。如果為了趕工期，隨意在需要的地方進行代碼修改，代碼的發展會偏離精煉出的設計模型。各處的修改相互不關聯，慢慢積累，雖然可以運行，但也帶來了不好的副作用。這就需要代碼重構。重構的過程中，測試的目的就是要檢查這些重大的程序結構調整是否仍然完全的滿足改進后的業務設計說明。
對于核心業務將來的發展，或者降低一個關鍵的模塊為應對產品的需求偶爾做出的升級的風險，代碼的修整是十分有必要的。
我好奇其他人也是否相似的在開發中出現的這些現象，你覺得對這些概念進行重新定義有意義嗎?
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
