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