陰險的Bug，沈重的一擊

這張圖中隱藏著一隻邪惡的Bug，讓三日不Coding手就會癢的我，罕見地度過十餘小時萬念俱灰，了無生趣的職業生涯低潮，連多年來累積的自信都差點毁於一旦... 只有orz能代表我此刻的心情~~~
這陣子在寫一隻Window Form程式串接一個已存在的後台系統，目的要取代現行功能、效率不甚理想的終端程式。由於已有別人寫好的程式做為模仿對象，手上有詳細的協定文件(但沒有Sample Code)，而通訊用Library可提供詳細的Log。本以為應該沒啥大問題，卻發現新寫的程式始終得不到Server端的正常回應。
於是分別把老程式與新Code的Log拿來比了又比，甚至還用Ethereal抓了封包，Follow TCP Stream將完整的傳輸內容Dump下來，用UltraEdit開成上下視窗一行一行比對，明明我的傳送內容與老程式完全相同，為何會被Server識破，就是不給我正確的回應??
排除了傳送內容有異的假設，我開始朝一些細微且可能性不高的機車細節推敲，例如: 送出各訊息間的Delay間隔、傳接用的Thread別...等等，由這些看似吹毛求疵的舉動，自己都可以感覺到，此時已經站在喪心病狂的臨界點了，距離拿鍵盤敲頭自殘大概也不遠了。
忽然一個念頭閃過，決定冷靜下來，回頭再仔細思考一次，最大的問題應該還是在於送出的訊息內容有誤! 於是我重新抓了正常與異常的Log，用UltraEdit一個字元一個字元比對，看起來仍然是完全相同的。害怕會是不可見的字元(例如: Tab, \n)之類惹的禍，於是叫出了UltraEdit的二進位比對功能。這才看到，原來要送出01，我卻誤打為O1(字母O跟數字1，這是個離譜的打字錯誤，打字時被鬼附身是我想到比較合理的解釋)，而在UltraEdit、VS.NET中，0與O看起來幾乎是完全相同的，也是我比對了數十次卻一直未能發現的理由。
送錯了訊息內容，但Server未回應內容有錯，卻選擇了沈默不回應；UltraEdit與Visual Studio編輯環境的字型設定讓0與O二者難以用肉眼識別；過快跳離了最有可能的原因(錯送內容導致結果不同)，太早鑽研罕見的狀況... 一連串的巧合，讓這個小小的Bug快速長成巨獸，給了Coding老鳥難以承受的沈重一擊。
不過，這樣的經驗，也讓我回頭檢討自己習以為常的Coding、Debugging Style是否流於過度自信，造成在某些狀況下陰溝裡翻船。謝謝這個Bug給自以為是的老骨頭一個謙卑自省的機會，重新學會用敬畏的心去面對技術議題。
PS: 忽然回想起當年擁有的第一部電腦，Intel 8088 4.77MHz的Acer PC，初學電腦的我，看著滿是綠色字母的單色CRT，老對零中間多的那一撇很感冒，抱怨為何硬要跟平常看的印刷字母不一樣。今天的我，特別想念那些有一撇的零...