R04 支援專案所見(2)──不是我寫的不知道

當系統發現問題或需要修改時，如果那時原來的開發人員不在難免會另外找人先瞭解問題，並希望他嘗試去解決。但是一開始總是會先聽到“那不是我寫的，不知道耶”這句話。在急迫時我也會被指定去解決比較困難的幾個問題，在剛進入專案幫忙時真的是什麼都不知道，那句話也不知在腦中盤旋幾次了，不過當然不能說出來，只能按部就班地抽絲剝繭下去找出問題的發生點。

一開始會先去問發生狀況的部分是要達成什麼功能，也就是先問出大致的需求內容；接著會問如何操作才會發生異常的狀況以便重現問題；然後確認正常狀況應該是什麼，以比較對與錯之間的差異是什麼。資訊收集後再來就是用除錯模式驗證程式碼，但是在此之前還要知道流程與程式的對應在哪裡，先弄懂程式上的架構才能追進程式的流程逐步檢查。

即使公司的專案已經先行提供通用的主要架構，但是在可以客製化撰寫程式的地方，每個人寫的程式碼都有自己的風格，物件的擺放也依自己的想法；公司目前沒有提供標準的設計方法論可遵循，以至於產出的過程與結果都依個人喜好而有所不同。由此可見，要追查一個陌生的問題難度著實不低。

更困難的是，客戶重視解決問題的同時要記錄系統對應修改了哪些程式，有哪些功能流程走過修改的地方而且可能造什麼影響；另外也會問是否有其他情況會在其他模組裡造成類似的錯誤。在時程急迫且修改者對修改部分不甚瞭解時，如果只改看起來是問題的地方就會時常漏東漏西的；一旦修改問題時發生其他side effect的機率偏高時，客戶對系統品質的信任自然會越來越低。