【程式人】消失的程式碼

【程式人】不需『口才』的工作？ << 前情

最近在 bbs 上看到一篇求助程式碼消失的文章，見發問者的描述，看起來主因是不當的使用方式讓原本可以輕易用版本控制系統搞定的事變得一團混亂。

看到他的慌亂，讓我想起開始以寫 code 獲得主要收入的第一年。大家都有這樣菜鳥的時期，不過後來職業生涯會怎麼發展卻有相當大的差距。我想我是幸運的人，潛移默化中獲得一些幫得上自己的習慣。

剛進入公司時，被指派的是解 Bug 的任務，同事由 Issue Tracker 上選擇一些在我程度上足以搞定的任務。我快速地找到了程式，改了一些判斷條件，解了 Bug 請同事來審視。同事隨口問了一句：『原因是什麼？』。當時是傻住的，沒有想過原因？但問題似乎被解決了。

同事開啟 Issue Tracker 再看了一次 Issue 對問題的描述，一步一步地由可能發生問題的程式入口（因為當時是以 WebWork、Spring、Hibernate 實作 Web Application，所以由某個 URL 開始，找到對應的 Action），用 Debugger 設了停駐點，用二分逼進，或用經驗推測縮小問題的範圍。由 Action 追到 Service 追到 Dao，將程式不符合預期的行為在這三者之間慢慢將目標縮小。距今已經有五六年了，我也忘了實際的 Bug 內容與原因是什麼。不過這段經驗帶給了我很大的震撼，它可以說我是由『素人』轉換成『職人』的重要激素。

首先來談談心境，遇到問題時，或被交待陌生的任務時，情緒會一下子衝上來，可能是害怕、焦慮、生氣，得先讓負面的情緒緩一緩。這是能夠練習的，後來漸漸習慣以『好奇心』來取代這些負面的情緒。程式會這麼動，或是會這樣壞掉是有原因的，試著對眼前所現的窘境或怪異感到好奇。用 Debugger、Unit Test Tool 或 Trace Code 去探究它為和是這麼動的。網路上有句名言『程式是照你寫的跑，不是照你想的跑』相當富有趣味，也如同提醒以撰寫程式維生的我們，有時候寫出來的與想的是有落差的。你可以對現象好奇，也可以對自己的過去在『呆』什麼感到好奇。

使用具有邏輯的順序處理問題。問題不需要立即被處理，要先拋開 Bug 需要『立刻、馬上』被解決的念頭。第一時間要先『理解問題』，看清問題的原因後，才能知道提出的解法是不是針對 root cause，還是單純治標不治本。這個順序是違悖人性的，第一時間能問題被解掉了能釋放不少壓力，就像發問的版友最需要的是找回他的程式碼。不過，這並不是針對主因與成因的處理順序。同事展現的行為與態度都在育教我得看清問題的源頭，由這源頭的答案我們能獲得更多經驗與警愓。

實際上要做的事很簡單，就是設法 reproduce，這也是為什麼一個 Bug 被標能 reproducable 或 cannot reproduce 的命運大不同（當 QA 發來一個 reproducable 的 Bug 時，記得感謝他們）。能輕易 reproducable 的問題，才能透過工具反複觀察它的改變，並縮小問題的空間，獲得精確的問題陳述，到這一步我們幾乎可以直指問題是怎麼產生的。

越是當開發越久，更覺得當年的『原因是什麼？』寓意深遠。因為不知道原因時，我可能只是掩蓋問題，或是碰巧歪打正著，或是真的寫出了對的解法。不過這些都與理解問題後再來解決有相當大的差異，因為知道根源後我能有更多選擇。選擇的面向很廣，列出可以選擇改變最小的解法，或選擇相容其他協作物件的解法，或是藉由這個機會整頓設計上的缺陷，讓後續的維護者不容易寫錯。

在 bbs 的討論串內，我好幾回提起了他應該要試著 reproduce，雖然不是讓他找回消失的程式碼的方法，但卻是讓他真的弄清怎麼把程式碼弄丟的方法。這過程可以讓肇事者推敲出程式是在哪個步驟間消失的，最後獲得更精準的『錯誤行為』

感謝那篇文章讓我回想起這份『財富』，雖然無法確定苦主是否習得版本控制的用法，還是習得無助。期待他有一天試著沉澱情緒，運用邏輯、探索問題的步驟，透過 reproduce 將錯誤重現。

工程師的思維，即處事的紀律。它改變了我的生活，也改變了我的人生。

後續 >> 【程式人】轉折 — 程式能不能寫一輩子？