說起程序猿，總繞不開的一個話題就是bug，估計每個程序猿聽到某某測試跑過來一臉淫笑的告訴你這個功能有個bug的時候，總有種恨不得掐死他的想法。其實程序猿跟bug的關系，感覺有點像父親和兒子的關系，自己制造的bug，哭着也要自己解決，就像自己生的兒子，哪天又犯了錯，就算氣得恨鐵不成鋼，也要教育他幫他改正一樣。好了，扯遠了，按照一般程序猿的心理，bug再正常不過了，解決就是了。可是你想過，解決bug的時間和人力成本嗎？
1、bug從修復到解決的流程
通常情況下，一個bug從發現到解決的流程應該是這幾步：
這其中，發現bug的環節不可控，因為我們不知道什么時候會有bug提出來，我們能做的就是發現bug后用最少的時間和人力成本來解決這個bug（都說技術人員的kpi不好衡量，如果做好了形成了團隊的規范准則，應該也可以算一個績效點，因為可以提高工作效率，至於權重多少，需要配合實際數據來分配）。復現bug環節，簡單的問題很好復現，可能比較耗成本又最容易忽視的環節應該是復現bug了，至於定位bug，修復bug和測試環節，因為天生自帶主角光環，更容易被重視。那么，有沒有辦法盡可能減少這個環節的時間和人力成本呢？
2、為什么不要去復現bug?
1、bug復現可能概率很小
雖然我們在開發過程中遇到的大部分的bug都是能復現的，但並不能保證所有的bug都能100%復現，而且經常出現這種情況：用戶在IE瀏覽器上瀏覽某個網站時，發現某個頁面是一片空白，多刷新幾次，又正常顯示了，這種蛋疼的問題，如果偶爾1,2次出現，可能是網絡原因，但如果經常出現，而且不同的網絡場景，不同的用戶都出現了，你還敢說是網絡的原因嗎？
再舉個后台的例子：某天某個集群（3台服務器）中某個重要的服務突然宕機了，接到告警后趕緊先把服務重啟了，然后查看了core dump的日志，發現程序中並沒有死鎖和阻塞的線程，而且JVM的GC日志也是正常的，吊詭的是沒過多久，另外2台服務器也相繼崩了，於是硬着頭皮，把所有可能的原因排查后重新部署，繼續運行了幾天后，正當你以為這bug已經解決時，突如其來的告警短信又提醒你服務又相繼掛掉了，這時候你是不是要奔潰？
這時候我們要幫助用戶解決他的疑問，就必然要先復現用戶的bug來定位問題，而用戶的問題出現的場景，往往依賴於用戶的操作系統、瀏覽器版本，機器上裝的第三方軟件，網絡環境，執行操作的順序，甚至是用戶打開了多個網站和網頁導致cookie混淆等等多個因素，可能就因為其中某個被我們忽視的因素的差別，就導致bug不能復現，這時候你是不是很絕望？
2、復現bug有可能成本太高
復現bug的成本，主要分為時間成本和人力成本，你需要模擬環境，mock數據，一步步debug找到問題再修復，這整個流程走下來，可能半天時間就沒了，在這過程中，你可能會找用戶或者產品經理詳細了解他們的操作流程，或者造數據時需要請求dba幫忙導入數據，這里都會產生時間成本和人力成本。
3、為什么做好日志記錄？
1、良好的日志規范，能快速有效的定位問題。
做開發最怕的就是線上系統出問題了，輕則留下產品和系統不安全可靠的不好印象，重則影響到公司的收入和口碑。當然了，線上bug總會存在，這很正常，但是我們要做到即使出現了問題，也要能快速定位問題修復，也就是要做到常說的4個9：99.99%，否則年終獎可能要打水漂了。說到打日志，想起了關於程序員寫注釋的一個悖論：程序員最討厭自己的代碼寫注釋，也最討厭別人的代碼不寫注釋。打日志可能覺得很麻煩，但記錄一些關鍵步驟，關鍵參數，對於快速定位問題進行修復時大有裨益的。
2、日志打印真的很耗性能嗎 ?
打日志意味着有磁盤IO,為什么mysql采用B+樹而不是紅黑樹或者AVL樹也是這個原因：為了減少IO次數。除非是一些高並發接口，否則這就是偽命題。一般系統日均QPS上萬都很不錯了，對於大部分公司而言，打日志帶來的性能損耗是可以完全忽略不計的。
3、如何做好日志記錄？
請參考日志聖經：《阿里JAVA手冊之異常日志（異常處理 日志規約 》，不再贅述。
后記：說來慚愧，半年沒寫博客了，曾經自己許下的豪言壯志又食言了，這篇文章從構思到最終成型也是斷斷續續寫了一個月，其中很多原因。自從換了家公司，加班時間至少是上家公司的double time，連周末也成了大小周，累的喲，不過習慣就好，讓自己忙起來可以做更多的事情。19年又開始了，計划周末再復盤下過去的一年，並規划下新的一年，人嘛，夢想還是要有的，要不然跟咸魚有什么區別呢？有想一起交流技術和交朋友的歡迎加我微信：1194426086，希望一起進步。