你需要的不是重構，而是理清商務邏輯

首先說明我轉這篇文章，不是因為這篇文章說得完全正確，而是對想做重構的人一個很有用的提醒，重構應該根據業務進行重構！

================================================================================

最近我遇到了一位以前公司的同事。他提到了數年前我在那個公司曾經開發過的項目。他說這個項目現在已經變成了“職業殺手”。基本上，任何接觸過這個“職業殺手”項目的人最終都會離開這個公司。如果公司想讓名下的程式員人數>0，唯一的辦法就是花數月時間完全重構這個系統。

對於這事我有兩點要說。首先，在我離開這個公司前，這個系統的單元測試覆蓋率已經達到了85%，所以，不要責備我。第二，這麼大規模的重構？肯定會出問題。

每一個系統裡都至少有一個成為人民公敵、讓所有人害怕的組件。它承載了太多的任務，它擁有太多狀態，太多的其它組件調用它。當時間到了償還技術債務的時候，人人都會把目光投向這個組件。然而，如果你對這個組件只有一個不全面的理解，你放下所有工作來完全重構它，那你成功的幾率會很小。這個組件，就就它表現出來的令人恐怖的程度和複雜相比，它的實際情況會比你想象更複雜，更恐怖。

你認為這個組件是如何發展成這樣一個不幸的狀態的？是因為公司僱用了一個笨蛋，讓他肆無忌憚的往系統裡增加複雜度？或是因為這個組件最初設計的太抽象，由於多年來需求的變更，它的責任範圍不斷的擴大？(出於個人的自尊，我寧願相信這個“職業殺手”屬於後者)。十有八九，這個組件變成如今這個恐怖的狀態，都有由“聰明人”的一些“好意”造成的。如果你決定做一次大的重構，你實際是欠下了另一筆技術債務留給後人。

為了能真正的徹底償還這筆債務，你需要去分解這個系統的複雜度。你需要花時間尋找所有調用這個組件的用戶端。你需要花時間跟你的同事交流，瞭解這個這個組件的曆史和它是如何被使用的。你需要簡化這個組件的周邊環境，看看它是如何運作的。每周，你都需要花更多的時間來更清楚的瞭解這個組件的業務。只要有足夠長的時間跨度，你最終能理清所有複雜的問題。

從實際方法上說，這個問題應該怎麼辦？與其現在花3個整月的時間做一次完全的重構，不如先用一個季度的時間做清理工作。最後還是要重寫，但有了3個月的計劃準備，你有了時間去分析和設計。你有了時間來理清業務。