談談對bug的一點想法，說說作好日誌記錄的重要性

       提及程序猿，總繞不開的一個話題就是bug，估計每一個程序猿聽到某某測試跑過來一臉淫笑的告訴你這個功能有個bug的時候，總有種巴不得掐死他的想法。其實程序猿跟bug的關係，感受有點像父親和兒子的關係，本身製造的bug，哭着也要本身解決，就像本身生的兒子，哪天又犯了錯，就算氣得恨鐵不成鋼，也要教育他幫他改正同樣。好了，扯遠了，按照通常程序猿的心理，bug再正常不過了，解決就是了。但是你想過，解決bug的時間和人力成本嗎？

一、bug從修復到解決的流程

       一般狀況下，一個bug從發現到解決的流程應該是這幾步：    

                                                                                                     

      這其中，發現bug的環節不可控，由於咱們不知道何時會有bug提出來，咱們能作的就是發現bug後用最少的時間和人力成原本解決這個bug（都說技術人員的kpi很差衡量，若是作好了造成了團隊的規範準則，應該也能夠算一個績效點，由於能夠提升工做效率，至於權重多少，須要配合實際數據來分配）。復現bug環節，簡單的問題很好復現，可能比較耗成本又最容易忽視的環節應該是復現bug了，至於定位bug，修復bug和測試環節，由於天生自帶主角光環，更容易被重視。那麼，有沒有辦法儘量減小這個環節的時間和人力成本呢？

二、爲何不要去復現bug?

一、bug復現可能機率很小

      雖然咱們在開發過程當中遇到的大部分的bug都是能復現的，但並不能保證全部的bug都能100%復現，並且常常出現這種狀況：用戶在IE瀏覽器上瀏覽某個網站時，發現某個頁面是一片空白，多刷新幾回，又正常顯示了，這種蛋疼的問題，若是偶爾1,2次出現，多是網絡緣由，但若是常常出現，並且不一樣的網絡場景，不一樣的用戶都出現了，你還敢說是網絡的緣由嗎？

      再舉個後臺的例子：某天某個集羣（3臺服務器）中某個重要的服務忽然宕機了，接到告警後趕忙先把服務重啓了，而後查看了core dump的日誌，發現程序中並無死鎖和阻塞的線程，並且JVM的GC日誌也是正常的，弔詭的是沒過多久，另外2臺服務器也相繼崩了，因而硬着頭皮，把全部可能的緣由排查後從新部署，繼續運行了幾天後，正當你覺得這bug已經解決時，突如其來的告警短信又提醒你服務又相繼掛掉了，這時候你是否是要奔潰？

      這時候咱們要幫助用戶解決他的疑問，就必然要先復現用戶的bug來定位問題，而用戶的問題出現的場景，每每依賴於用戶的操做系統、瀏覽器版本，機器上裝的第三方軟件，網絡環境，執行操做的順序，甚至是用戶打開了多個網站和網頁致使cookie混淆等等多個因素，可能就由於其中某個被咱們忽視的因素的差異，就致使bug不能復現，這時候你是否是很絕望？

二、復現bug有可能成本過高

      復現bug的成本，主要分爲時間成本和人力成本，你須要模擬環境，mock數據，一步步debug找到問題再修復，這整個流程走下來，可能半天時間就沒了，在這過程當中，你可能會找用戶或者產品經理詳細瞭解他們的操做流程，或者造數據時須要請求dba幫忙導入數據，這裏都會產生時間成本和人力成本。

三、爲何作好日誌記錄？

一、良好的日誌規範，能快速有效的定位問題。

      作開發最怕的就是線上系統出問題了，輕則留下產品和系統不安全可靠的很差印象，重則影響到公司的收入和口碑。固然了，線上bug總會存在，這很正常，可是咱們要作到即便出現了問題，也要能快速定位問題修復，也就是要作到常說的4個9：99.99%，不然年終獎可能要打水漂了。說到打日誌，想起了關於程序員寫註釋的一個悖論：程序員最討厭本身的代碼寫註釋，也最討厭別人的代碼不寫註釋。打日誌可能以爲很麻煩，但記錄一些關鍵步驟，關鍵參數，對於快速定位問題進行修復時大有裨益的。

二、日誌打印真的很耗性能嗎 ?

      打日誌意味着有磁盤IO,爲何mysql採用B+樹而不是紅黑樹或者AVL樹也是這個緣由：爲了減小IO次數。除非是一些高併發接口，不然這就是僞命題。通常系統日均QPS上萬都很不錯了，對於大部分公司而言，打日誌帶來的性能損耗是能夠徹底忽略不計的。

三、如何作好日誌記錄？

      請參考日誌聖經：《阿里JAVA手冊之異常日誌（異常處理 日誌規約 》，再也不贅述。

      後記：說來慚愧，半年沒寫博客了，曾經本身許下的豪言壯志又食言了，這篇文章從構思到最終成型也是斷斷續續寫了一個月，其中不少緣由。自從換了家公司，加班時間至少是上家公司的double time，連週末也成了大小周，累的喲，不過習慣就好，讓本身忙起來能夠作更多的事情。19年又開始了，計劃週末再覆盤下過去的一年，並規劃下新的一年，人嘛，夢想仍是要有的，要否則跟鹹魚有什麼區別呢？有想一塊兒交流技術和交朋友的歡迎加我微信：1194426086，但願一塊兒進步。