我的程式碼真的沒有bug，稍等，先試試小黃鴨除錯法
今天測試同學為了趕進度，加班去測試我的功能。
因為我的程式碼都寫完了，也沒有陪測的必要，所以就沒去了~
下午第一個問題提過來，根據經驗，這個應該是測試的邏輯問題，最後他自己也發現了。
過了一會，提了第二個問題，說是本該命中條件進入某個等級的，沒有進入，跳到下個等級了。
擁有幾年開發經驗的我，此時當然不會說“我的程式碼沒有bug，你再試一遍”。說出這句話的成本近乎為0，但是臉要是打起來，那是真的疼啊~~~
腦海中快速思考下，發現不是靠腦海中演練就能給出答案的，於是乖乖的，掀開電腦蓋，指紋解鎖，連線VPN，檢視日誌，一氣呵成。
因為這個需求指標巨多，流程相對較長，所以我已經在程式碼的關鍵節點列印了資料日誌。
所以，想要的資訊，日誌都是有的。只是，仔細看了下日誌的資料，又認真的比對了測試同學給出的測試資料。講道理，這確實應該命中。
可是事實就是沒有命中，於是開始排查。
檢視配置中心
因為指標多，每個指標都有閾值，首先第一反應當時是別人的鍋，所以我不放心的看了看是不是測試同學調整的引數閾值有問題，看完後，我有點愧疚，這不是測試同學的問題，指標都對上了。
但是還是不死心，是不是沒有按照我給他說的要點選熱載入選項，導致指標沒生效。想到這裡，我有點小激動，沒錯，我又可以表面輕描淡寫，實則內心激動的告訴他真相：你這個是配置忘記勾選了吧（怎麼回事，又是你的問題）
想歸想，想要趾高氣昂就要有底氣，要底氣就得拿證據。
我們的配置中心做的就是這麼貼心，每一次操作都可以檢視歷史記錄。趕緊點一下，然後截個圖，甩給他。
等等，這個，沒想到啊，測試同學居然這麼嚴謹，選項勾選了。
emmm
調整策略
從日誌來看，測試的資料沒有問題。
從配置中心來看，配置也勾上了。
測試排除嫌疑，真相只有一個，是我的問題（自己打自己臉，下手可以輕點）。
雖然家裡連上了VPN，也可以看日誌、釋出專案，但是本地啟動服務不好使，UT也跑不通。
那隻能看程式碼了，要知道，近朱者赤近墨者黑，找別人缺點，那是章口就萊，一萊一個準。
找自己的問題？首先得否定自己，知道自己原來也是有瑕疵的，這是多麼難的事兒，但是我做到了！
為了給測試同學一個交代，我開始老老實實的研讀自己的程式碼，企圖一眼就發現自己的不足~（太南了
失策了
涉及測試點的程式碼邏輯也不復雜。大概過程是這樣的
上游併發呼叫獲取各個指標的當前值 -> 在規則層過濾 -> 如果命中兩個規則條件則視為命中，否則未命中
於是，按照測試同學提供的兩個指標以及提供的測試資料比對兩個規則的閾值。
從日誌來看，上游的資料是沒有問題的，從資料比對來說，應該是比對通過了，但是沒有命中。
於是開始仔細檢查這兩個規則相關的程式碼，以防出現，手抖把"!="寫成"=="的情況。
很遺憾，在我認為比較關鍵的地方檢視後，發現我的程式碼就是這麼嚴謹，找不出任何破綻。
為了不讓測試同學hang在我這個執行緒上划水、摸魚，我得先釋放鎖：“程式碼看著沒啥問題，你先測試其他邏輯，我再看看。”
小黃鴨救了我
我心裡清楚，雖然我有一點散光，但是眼睛還沒瞎。
所以即使再比對十遍八遍，肯定也還是找不到bug。
是時候換一種思路了。
上面說了，上游程式碼排除嫌疑，涉事程式碼本身排除嫌疑，當然，測試同學也排除嫌疑，更別說下游程式碼，下游完全不知情啊。
仔細想想，兩個規則之前還有有其他程式碼的，雖然也是一個規則。我決定擦亮雙眼，人肉找bug。
把自己當做一臺沒有感情的機器，一遍讀這我寫的工整簡潔的程式碼，一遍計算程式碼的結果，再到排除嫌疑。
上游賦值沒有問題！ 變數初始化和結果返回沒有問題！ 第一個規則沒有問題！
第一個規則沒有問題！
其他初始變數賦值和返回沒有問題！
然後開始過第一個規則和第二個規則之間的中間規則程式碼。
在方法返回的時候好像沒有返回期望的值啊？！
沒錯，我把本來應該不管命中與否都要返回的一個變數值，只在命中的條件裡賦值返回了。如果沒有命中這個規則，則沒有賦值，那實際上返回的是這個變數的型別預設值，也就是0，歸零了！
趾高氣昂只會遲到，但永遠都不會缺席。
我告知測試同學，我應該知道原因了，我修復下，一會再試下，後面的“英雄事蹟”就不多介紹了。
總結盤點
雖然不是什麼大問題，也不是什麼線上大事故。
只是想表達，幾乎沒有人敢說自己寫的程式碼0bug，寫完就可以上線。曾經有跟我這麼承諾和標榜的人，最終都是難逃翻車和打臉的命運。
有問題，理性分析最重要，從涉及bug的方方面面，包括經手的人和程式碼本身，都有可能出問題。
有時候，如果發現是自己的問題，但是又遲遲找不到原因，不要一個人悶著頭苦苦思索，找個同事來幫你一起找。有時候就在你準備讓別人一起來看看，你開始描述問題的詭異之處，還沒說完，你就突然知道了原因。不知道你遇到過沒有，反正我有。
今天回過頭想想，哪些被我叫來的人其實就是工具人，他們和小黃鴨無異。
什麼是小黃鴨和小黃鴨除錯法呢，參見百度詞條
此概念是參照於一個來自《程式設計師修煉之道》書中的一個故事。傳說中程式大師隨身攜帶一隻小黃鴨，在除錯程式碼的時候會在桌上放上這隻小黃鴨，然後詳細地向鴨子解釋每行程式碼 。 許多程式設計師都有過向別人（甚至可能向完全不會程式設計的人）提問及解釋程式設計問題，就在解釋的過程中擊中了問題的解決方案。一邊闡述程式碼的意圖一邊觀察它實際上的意圖並做除錯，這兩者之間的任何不協調會變得很明顯，並且更容易發現自己的錯誤。如果沒有玩具小鴨子也可以考慮向其它東西傾訴，比如桌上的花花草草，鍵盤滑鼠。
類似這樣
或者這樣
找不到鴨子，找同事也一樣~
如果您覺得閱讀本文對您有幫助，請點一下“推薦”按鈕，您的“推薦”將是我最大的寫作動力！如果您想持續關注我的文章，請掃描二維碼，關注JackieZheng的微信公眾號，我會將我的文章推送給您，並和您一起分享我日常閱讀過的優質文章。
