重構 Cringely

Robert Cringely 最近的一篇文章 批評重構，最近在重構社群中引起了一陣騷動。Phlip 在 重構郵件清單 上總結了回應，以異常克制的方式表示「...他聽起來像是一個『懷疑論者』，寫著自己無意閱讀的書籍評論。」

當然，Cringely 對重構的了解程度尚不清楚，儘管他肯定理解了關於重構是行為保留轉換過程的重點。他所做的，是強調重構被不當使用的許多方式。

一個誤用是重構不會變更的程式碼。重構的重點在於改善現有程式碼的設計。設計良好的程式碼的價值在於它更容易變更。因此，您重構預期未來會變更的程式碼。重構穩定的程式碼沒有意義。

另一個例子是一個重構團隊進入其他團隊的程式碼並重構它。這是「服務」的一種，我會付費避免。程式設計師應該只重構自己的程式碼，而不是在其他東西中亂搞。XP 團隊使用集體程式碼擁有權，鼓勵任何人重構團隊程式碼庫中的任何程式碼，但這僅適用於該團隊的程式碼。一個團隊在不告訴任何人的情況下到處重構其他團隊的程式碼的想法，絕對不是我會推薦的事情。

最後，他抱怨重構被用於涵蓋任何形式的程式碼變更。與其他人一樣，我 100% 同意他的看法。長期以來，我的一大抱怨就是人們將重構用作重組某事物的同義詞。重構是一個非常特殊的過程，它使用一系列小的語意保留轉換來變更程式碼庫。這是一個非常特殊且有紀律的過程。還有其他方法可以重組程式碼，無論是有益還是無益，這些都不是重構。

總的來說，聽起來我同意 Cringely 所說的大部分內容。這是真的，郵件清單上的評論也是如此。總的來說，這種煩惱來自於一種感覺，即 Cringely 在急於指出流行趨勢時，錯誤地描述了重構。

我肯定與 Cringely 分道揚鑣的地方，是他認為 80% 的重構都是浪費時間，軟體經理應該停止重構以節省資金。重構的重點在於改善設計使變更事物變得更容易，因此重構會提高生產力。當然，程式設計師需要判斷重構工作是否會得到回報，而這不是您可以輕鬆量化的東西。但我一次又一次地看到人們浪費時間處理設計不良的程式碼，而這些修補程式只會讓情況變得更糟。重構是一種擺脫這種特定死亡螺旋的方法 - 這就是我認為它是一種如此有價值的技術的原因。