如何優雅地修改前同事的混亂代碼？

在軟體項目的生命周期中經常會出現開發人員的新老交替，這時項目對於新成員來說就是一堆遺留的代碼。當項目需求發生了變更，他要面臨的挑戰便隨之而來：

1. 不了解項目設計和代碼實現
2. 代碼混亂
3. 缺乏測試代碼

多希望新成員們都能順利通過上面的第一項考驗，可現實情況是許多人都不幸地折在了那裡。

我有個朋友幾年前加入了一家做社交應用的公司。入職當天，老闆給了他一個挑戰自我的機會──希望他在一周內熟悉業務系統的代碼。接著老闆向朋友補充說，維護那套系統的人已經離職。我不清楚朋友是否在老闆期望的時間內熟悉了代碼，但後來他告訴我，那段時間是他職業生涯中最黑暗的時期。

只有對項目設計和代碼實現胸有成竹，才能在其基礎上進行改動。不過，在此我們不討論如何熟悉項目，而是重點來關注「如何修改混亂的代碼」，並且假設當事人已經熟悉了手中的項目。

編程的本質是控制複雜性。 毫無疑問，混亂的代碼增加了複雜性。如果對混亂的代碼置之不理，直接在上面修改或者增加新功能，複雜性往往會與日俱增。因此，當發現項目代碼開始變得混亂時，就應當保持警覺並採取措施，把混亂扼殺在萌芽階段。混亂的代碼是技術債務，即使不碰它也會產生利息。因為隨著時間的推移，你會對這些混亂感覺越來越陌生。為了不讓債務越來越多，你就應該及時去消除技術債務。消除混亂的方法通常有兩種選擇：重構（Refactoring）和重寫（Rewrite）。

重構和重寫的共同目的是讓混亂變得有序。 但它們有一些區別，下面我從幾個方面來對比一下這些區別。這些區別不一定對所有系統都準確，但對大部分軟體項目都是適用的。

• 重構是漸進式的行為，每次只改變局部；而重寫是侵入式的行為，一切都從頭開始；
• 由於重構每次只改變局部，可以更好控制混亂；而重寫一開始就改變整體，更難控制；
• 由於重構更好控制混亂，周期更短；而重寫往往周期更長。

那麼問題來了，當面臨混亂的代碼時，我們應該選擇重構還是重寫？

除非有充足的理由，否則最好不要重寫，因為你幾乎無法肯定會比現在做得更好。另一個重要原因是，重寫往往會花更長的時間。對軟體公司來說，時間尤其寶貴，不過這裡並不是一味地否定重寫，現實世界中也有許多重寫的成功案例。

最後一個問題是缺乏測試。如果項目包含有充分的單元測試，能覆蓋這些混亂的代碼，那麼重寫或重構將會安全很多。因為它至少可以保證改動前後，代碼的外部行為是一致的。

如果說重構是改革，那重寫就是革命。是想來一場循序漸進的改革，還是轟轟烈烈的革命呢？我想應該根據項目的特點，結合開發周期等因素來綜合考慮。

Talk is cheap, just DO IT!

題圖：Econesting

推薦閱讀：