如何維持軟體專案的可維護性？

最近半年，有時常在猶豫一些問題，最常遇到的，就是前些時候寫好的一段程式碼，現在必須在上頭追加一些新的功能，然後就感覺到「唔，當初沒有計畫要追加這個功能，所以結構不太適合這麼做」，或者是「當初時程有點趕，寫起來有點凌亂」等等，可能有著各種原因讓自己覺得之前寫好的程式碼有點髒。但現在新功能的時程也不是很長，如果去動了舊的程式碼，時程可能變得很緊湊，那該怎麼辦呢？

是否該重構程式碼，常常是每個程式設計師都會遇到的問題。不過我自己的狀況的話，我的選擇通常是「是的！現在、立刻、馬上開始重構」。為什麼呢？假設我現在覺得這段一百行的程式碼有點髒亂，現在沒什麼時間去重構它，但我必須追加新的功能。因此我在裡面放了一個新的方法，然後在原有的一百行程式碼中多寫一行呼叫新方法的程式碼，接著把新功能的三十行程式碼寫在新方法裡。看起來我避免了重構的問題，也在盡可能不更動既有程式碼的情況下，追加了新的程式碼上去，一切看起來都很完美。

那問題在哪裡呢？問題在於，寫新功能我有兩種選擇，一種是沿用舊的（有點髒亂的）寫法，另一種則是用比較好比較乾淨的新寫法。想像一下，這次的新功能寫完的半年後，我又有另一個新功能要寫了，而且我早就忘了之前寫了什麼，這時會發生什麼事？

1. 這次沿用舊寫法寫新功能：真是太好了，現在我面對的是一百三十行有點髒亂的程式碼。日復一日，我永遠不會有機會重構它，因為下一次我的代價比這次更高了，這次我沒有重構它，下次我更不會想要重構它。
2. 這次改成新寫法寫新功能：事情變得更棒，專案裡竟然有兩種不同風格的程式碼！這比統一用有點髒亂的寫法還糟糕，因為我可能根本看不懂兩種不同風格的寫法為什麼會這樣寫。而且當初我面對的是「一百行有點髒亂的程式碼」，現在我面對的是「一百行有點髒亂的程式碼，再加上另外三十行不知道為什麼風格完全不同的程式碼」。

無論我做了什麼選擇，我現在不重構，下次只會讓我自己更痛苦，因為程式碼更亂更無法維護。若每次我都選擇把痛苦留到下次，那麼專案最終只有唯一一種結果：變成一個連我自己也不想去碰它的程式碼。

因此，無論什麼狀況，當看到程式碼開始有點失去控制時，現在就開始重構吧。儘管會讓現在的臉變灰（時程可能因此延後），也好過未來直接變黑臉。

PS. 純粹紀錄一下最近半年常在思考的問題，也許再過幾年回過頭來，會有另一些不同的看法，到時還可以回來看看以前在想什麼 XD。