2017年3月8日 星期三

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

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

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

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

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

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

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

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

沒有留言: