關於重構：方式和時機

每個程式設計師都應該有過這樣的心理活動：“這段程式碼太爛了，我要重構一把”。然後接下來幾天甚至幾個禮拜水深火熱，因為：

1。 明明只是改了幾個class，結果整個專案都不對勁了。

2。 越改越多，好幾天都做不完，影響釋出。

3。 改動產生了很多副作用，測試同學壓力很大。

所以很多老鳥對重構又愛又怕，不做吧，專案越來越難維護；做吧，進度和質量都不能放鬆，畢竟“正事”還得繼續。而且，做得再好也很難體現效益，卻很容易出現紕漏。所以，重構風險極大而收益一般。

這也是為什麼大多數 leader，tester 們都不太看好程式設計師做重構，搞得不好，要麼專案廢了，畢竟穩定壓倒一切。

其實重構本是一件好事，也是軟體開發中必不可少的階段。因為經歷過一段時間的緊張迭代，軟體中必然會出現各種因為趕進度或者不規範操作遺留下來的問題檔案和程式碼，如果不及時的清理，後續一定會造成更多的開銷。比如：

1。 不再使用的 function，dead condition。

2。 各種姿勢 copy & paste 的程式碼。

3。 不再合適的模組劃分。

以及，落後的技術棧。

其實無論基於什麼原因，程式設計師重構的熱情總是無休無止。但只有熱情還不夠，還得注意細節。我總結了幾條：

1。 深入理解已有程式碼

重構出現問題，很大一部分原因是對已有程式碼瞭解不夠，重構後的功能自然不對應。所以，務必先保證自己已經洞若觀火，否則不要動手。

2。 從小處開始

不要一上來就想著改變整體的架構，這很容易讓整個專案變得不穩定。最好是小範圍實踐，逐步替換。

3。 驗證和測試。

還有最重要的，時機。儘量選擇進度寬鬆的時期，其他時期儘量不做或者只做小規模重構，保證完成時間可控。因為重構期間專案不穩定，如果剛好碰上釋出，就感人了。

（完）