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