公司內的工程師總是來來去去
然而系統上線多年難免會有一大堆Legacy Code(遺留程式碼)
也就意謂者已經沒有人非常了解當初程式的設計概念
甚至沒有經過測試、也沒有規格書可以讓接手者維運
但因為系統仍能正常運作
所以通常也不會將其拿掉
(因為若砍掉重練出事的話反而對公司帶來重大的危機
畢竟Legacy Code是穩定的就還有其商業價值在)

我剛進公司時就大膽地跟主管提出要翻新系統的想法
結果立馬被回絕了
他說我們的系統是不容錯的
若今天你寫了一個全新的系統上線沒是那當然最好
但只要一出事沒有人會感謝你(明明原本好好的能用 都被你改壞的
而且也對客戶造成直接影響
想得很簡單 但要做好實在不容易
要經過長時間的測試、耗費大量的人力和時間
(雖然他剛進公司時也曾和我一樣有這種天真的想法)

那麼面對這樣的程式遺留物
我們第一步也只能先做測試
因為先盡量寫出可能呼叫到區段程式碼的測試案例
變得更了解運作的流程
並且在重整程式碼後再用測試案例去確認不影響其他功能
最怕的就是程式的相依性太強
而造成牽一髮而動全身
但太老舊的程式碼效能通常不太好
或是在處理資料上會有許多限制
因此整理它們是必要的

而程式碼的重構又是另外一回事了
一般來說能寫出功能並不難
但要在維持功能正常又要讓大家都看得懂就確實不容易
相信各位資工的研究生都看了不少開放的原始碼或是學長姐的code吧
常常覺得花時間理解還不如重寫比較快
不過很抱歉 老師還是會要你先了解別人的設計
因此今天身為一個開發者
若希望讓專案易於擴充和維護的話
重構幫助很大
主要目的就是增加可讀性
但前提是不影響所有的功能
去讓程式碼變得更清晰易懂
並且更容易找出潛在的問題
其實像是把重複的程式碼用迴圈包起來也算是一種重構
(或是Visual Studio也會很常好心提醒你哪段可以重構)