※ 引述《eori (浮光掠影)》之銘言：
: 進來公司一個多月，被指派說要去修改一個系統。 該系統已經用了10年以上，文件寥寥
: 可數，代碼改得亂七八糟，註解只有幾行。我這個職位兩年內換了五個人，其他同事只知
: 道大概，問細節就說去看code。老闆一直認為這個系統很簡單，搞不懂為什麼沒人懂。請
: 問大家有沒有相似經驗，後來又是怎麼解決，可以給我當作參考，謝謝。
這種情形大概不會少遇到，除了自己公司開發的換了很多手的以外，也有那種外包給別的
公司做後來沒有再繼續維護後就放在那擺爛的系統。接到這種案子心情真的是會蠻差的，
去問別人都會叫你去看Code，去年我也接到幾個(公司維護擺爛說他不會，事實上他可能
真的不會，因為他上次跟流程人員說 Win10 不相容 .Net Framework 沒辦法安裝，搞到
流程來找我求助...這又是另一個故事了)
總之接到這種案子怎麼辦？
我的經驗是：
1. 先判斷是不是你非做不可？
別人都可以不做，都可以說不會，那為什麼我就必須會必須做？每個人職位不同都有
自己該做的工作，你本來的工作做不完，被推一個坑，延誤到你自己的時程，誰會幫
你？如果修不好還要被嗆被酸，有夠倒楣。如果是別人隨便推到你身上而不是必要的
那你先把自己的事做完再來看要不要幫忙，建議是不要節外生枝，說很忙沒空，之後
再說就好。去年我就是這樣嗆維護的，本來就他的事，我身上三個開發案還叫我去幫
他看，他自己在那跟客戶吹牛他什麼都會，還在try-catch裡寫遞迴這種東西我哪敢
碰。
2. 如果非做不可：
如果老闆已經發下命令要你做，先爭取時間。第一這個東西本來不是我寫的，你要我
研究一定要時間(不管是要維護還是直接重作)；第二你現在要我做這個，那我本來的
專案進度怎麼辦？我沒辦法兼顧，看是你要協調別人來幫我還是先暫停其他案子，不
然我沒辦法做。
再來實作方面，Trace Code一定是必要的，但幫助可能不大。舉我的例子來說，去年
我得到PM同意暫停手上案子後，去協助維護改以前的工具，跟你一樣文檔沒有註解沒
有。結果維護真的是來亂的，跟我講說看 Code 就會了什麼也不講。我問他你說看
Code就會，那表示Code的邏輯是對的囉？Code是對的為什麼要改？他說將來Data
Source的格式可能會變更，我說喔那會變成什麼樣子？他說不知道。我問他那你要我
改哪？這個工具是幹嘛的我都不知道，你說現在可以正常運行而且運行結果是對的，
那改什麼？你說將來會改但改成什麼樣不知道，那你要我怎麼改？然後這件事就不了
了之了。
事實上同樣的情況也適用在你碰到的情形上，我建議你在看Code前先了解一下這個系
統到底是幹嘛的，問題點在哪(沒有想改善的點那是要改什麼？)把你需要處理的業務
邏輯都整理清楚。我們工程師是為了解決某個特定問題而去寫程式寫系統，而不是寫
好系統來看我們能達到什麼解決什麼問題，這樣有點本末倒置，很可能一開始問題根
本不存在反而多花很多功夫。現在老闆要你改，表示他覺得這個系統有問題，那就是
Code本身可能就有問題。如果你什麼都不清楚，光從有問題的邏輯中就能推敲出正確
的邏輯應該是怎樣，那老闆該換你當了。當你看到你覺得很奇怪的Code時，你根本無
法確定前人為什麼這樣寫？到底是有特殊要求還是單純寫錯，或者是當時的需求已不
適用於現在，你也會不知道從何改起。
隨著時間過去，中間又經手過很多人修改，系統一定越來越龐大也越來越難改，如果
你能搞清楚這個系統到底是要幹嘛的，問題點在哪，改善後要達到怎樣的效果，邏輯
和數據該怎麼流動而終於要開始改了的時候，再來依照你Trace Code的結果決定是要
重作還是修改前人的Code。一般而言如果我判斷重作大概幾周至一個月內能做完的話
我就會直接重作了，反正有爭取到時間；要是系統實在過於龐大非短期單人能完成，
那你只好硬著頭皮去改以前的Code。要是你能了解這個系統的業務邏輯，那應該也有
助你找到比較可能出錯的地方。不過原則上來講還是建議跟老闆提看看要不要發包或
開新專案專門重作這個系統，畢竟一個系統搞到大家都敬而遠之，也代表他的維護成
本是相當高昂的，是不是還要這樣繼續下去，還是應該另外再做一個，這其實是可以
討論的。
當然如果夠油條，這些事其實能讓你殺很多時間，就像我前公司的維護一樣哈。