讓我掉下眼淚的 不止內存洩漏
讓我夜夜不眠的 不止你的需求
明天還要改多久 你攥著我的手
讓我感到為難的 是善變的需求
發佈總是在半夜 回滾是永遠的愁
錯誤(Bug)隨時的暴漏 困擾著我心頭
作為程序員，以上這些場景你一定都經歷過。今天就來聊聊如何快速定位問題。
先劃重點，下文所寫都是一家之言，本人工作經驗不多，語言表達能力有限，如果寫的不好，還望輕噴。另外，本文所講都是站在Java後端開發者的角度。
背景
下文所講內容，都會圍繞以下幾個真實案例來做舉例分析，先描述一下具體案例：
- 案例1：App首頁白屏。
- 詳細描述：App、H5、小程序首頁都是由同一個後端接口負責提供數據。測試大佬反饋說，App首頁白屏了。
- 案例2：小程序商品會員價顯示不正確。
- 詳細描述：測試大佬反饋，某商品會員價顯示不正確，客戶端展示會員價為0元。為什麼會員價0元是不正確的呢？因為我們在系統中做了限制，會員價必須大於0元。
- 案例3：優惠券領取不了了，彈窗顯示“領取失敗，該優惠券僅限新人領取”！
- 詳細描述：這是一個領取優惠券的功能。用戶可以通過該活動領取優惠券。用戶在領取優惠券時，頁面彈窗提示：”領取失敗，該優惠券僅限新人領取“。同時，測試大佬反饋說，這個賬號就是一個新人賬號，是剛剛註冊的用戶。
- 案例4：某用戶購買的xx評測專欄的評測課無法打開。
- 詳細描述：評測專欄是我司的一個特色專欄，在這個專欄中，有一節評測課。評測課就是讓用戶做在線試題，用戶先進行測試，瞭解自己狀態。測試完成之後，系統會根據用戶的答題情況，向用戶推薦合適的專欄課程表，供用戶學習。
背景交代完畢，那如果是你，在遇到這幾個問題的時候，會怎麼處理呢？
復現問題
當測試大佬反饋問題時，首先要做的就是復現問題。如果問題能復現，好嘛，已經解決一大半了，作為開發，我覺得還是要有這個自信的。能復現的問題，那就一定能修復（修復成本有高低，這個不在本文討論範圍之內哦），實在是找不到Bug代碼，我可以一行一行的調試嘛！所以，遇到問題不用慌，淡定淡定。
那如果問題不能復現呢？怎麼辦？
這個時候，我一般的做法是去查日誌。如果日誌中有錯誤信息，我們便可以根據錯誤信息快速定位到Bug所在的具體代碼。那如果這個時候也沒有錯誤信息呢？嗯...我想想，好像也沒有別的辦法了。問題不能復現，程序沒有報錯，那隻能麻煩測試大佬再多測試一下，看看能不能復現吧。
快速定位
經過上一步驟，我們已經可以讓Bug復現了，那接下來要做的就是快速定位。快速定位？定位什麼呢？
一般公司項目開發，都會分後端開發、前端開發、APP開發，這裡說的快速定位，指的就是要快速定位到是三端中的哪一端出的問題。
那如何快速定位呢？
如果你熟悉這個功能的整體流程，清楚整個功能會經歷哪些步驟、哪些模塊，這對你去快速定位問題是非常有幫助的。當然，也有一些監控工具可以來幫助開發者做快速定位，幫助開發瞭解整個流程。例如：sentry、skywalking等。
舉個慄：
案例1：App首頁白屏。
案例2：小程序商品會員價顯示不正確
這兩個問題反饋過來的時候，我打開app、H5、小程序都看了一下，發現：只有app的首頁白屏了，H5和小程序的首頁都是好的，考慮到App、H5、小程序首頁都是由同一個後端接口負責提供數據，那這個問題大概率是app那邊的問題，於是請app開發同事幫忙定位一下問題。
而app、H5、小程序這三端都出現了商品會員價顯示不正確這個問題，於是我斷定，這大概率是一個後端的邏輯問題。三端都寫錯代碼取錯了會員價這個概率應該不大。
案例4：某用戶購買的xx評測專欄的評測課無法打開。
這是一個產品反饋的線上問題，由測試大佬提到開發這邊的時候，測試大佬當時並不能復現。由於評測課的特殊性，它是需要由用戶做題輸入到系統，系統解析用戶答題情況，然後做系統推薦。
這是一個典型的與用戶行為數據相關的問題，可能只有具有某些特性行為、數據的用戶才會遇到。遇到這種問題，測試也是很難復現的。可以查一下日誌，看看有沒有報錯信息。
當時遇到這個問題的時候，由於項目接入了sentry平臺，開發這邊也是收到了系統異常報錯的郵件提醒，很快速的就找到了原因。
定位接口
好，經過上面幾輪的大致判斷，這大概率就是一個後端Bug了。現在我們需要做的就是，
快速定位到出問題的具體接口。如果移動端，就用Charles抓個包，H5端就直接打開Chrome控制檯。so easy~~ 媽媽再也不用擔心我找不到接口啦~~ 當然了，在實際操作過程中，可能並沒有這麼簡單。前端渲染頁面可能請求了N多個接口。
舉栗子
案例2：小程序商品會員價顯示不正確。
因為app、H5、小程序三端使用的是同一個接口來獲取商品相關信息，我會優先在H5平臺調試，畢竟不用開Charles，方便嘛~~
遇到問題，快速響應和解決才是重點，特別的線上問題。所以有時候這個功能可能不是你開發的，那麼如何在這麼多請求中如何快速定位找個具體接口呢？這就要靠你的經驗和聰明的大腦了。
這裡就分享一個我的經驗吧，不一定適合所有場景。就拿這個案例來說：打開商品詳情頁，打開控制檯。基於我對系統的整體瞭解，我確信一定會有一個接口返回商品的會員價，具體哪個接口我也不知道。
好，這個時候怎麼辦呢？猜接口！當然了，也不是亂猜。獲取商品會員價，那這個接口大概率需要前端傳給後端一個商品id，那商品id在哪裡呢？商品id一般都會出現在當前頁面的URL裡。於是，在控制檯的filter框中（圖中已標紅）輸入商品id。這個時候已經可以過濾掉大部分的請求了。
接下來你要做的，還是猜！看看剩下這些請求地址名稱，猜一下他的作用；看看接口返回的字段名稱，有沒有名稱像“會員價”字段，有沒有返回值和前端顯示的會員價一樣的字段。最後，經過大膽猜想之後，我們要做的就是小心求證，確認我們定位的接口是否正確。
定位代碼
定位到接口之後，我們就可以準備看代碼，修Bug啦！
不知道你有沒有遇到過這樣的情況。打開代碼，一眼望去，這個代碼這麼長，而且之前也不是我寫的，我該怎麼辦呢？下面我們就來講一下如何來快速定位Bug代碼。
舉栗子：
案例2：小程序商品會員價顯示不正確。
經過我們之前一頓猛如虎的操作，終於定位到了問題。
//接口返回數據
{
"price":9900,
"discountPrice":8900,
"vipPrice":0,
}
會員價顯示不正確，也就是"vipPrice":0這個字段有問題。
打開代碼，找到該接口對應Controller，找到該Controller返回的VO，找到VO中的vipPrice字段的setter方法，鼠標右鍵find Usages。恭喜你，這個時候你已經找到了這個vipPrice的值是在哪一行被設置的了，將重點聚焦於此即可，Bug就在這個代碼附近了。看一下這個vipPrice的值是怎麼計算出來的，是不是計算邏輯寫錯了。
如果這個時候，很不幸Controller的VO是通過BeanUtils這些工具類將屬性映射過去的，那麼你運行find Usages可能就找不到屬性是在哪裡被設置的了。唉，寫代碼時用的爽，出問題時淚汪汪。那隻能查這個VO是在哪裡被用到了，然後去代碼裡查了。
案例3：案例3：優惠券領取不了了，彈窗顯示“領取失敗，該優惠券僅限新人領取”！
如果“領取失敗，該優惠券僅限新人領取”這個文案，是你的接口返回給客戶端的，那麼，這個時候你要做的就是，IDEA全局查找這個關鍵詞。
哈哈哈，恭喜你，快速定位了，在PayUserRuleChecker的第51行，是不是很簡單？
修復問題
既然已經定位到具體的代碼了，那麼就可以進行問題修復了。這個時候就要看個人經驗啦，有經驗的程序員可能一眼就能看出來問題。
這裡列舉一些需要注意的點：
- 學會聚焦。整個service方法的邏輯代碼可能很多，但是像”會員價顯示不正確“這種問題，一定是之和計算會員價相關，你只需要聚焦這一塊的邏輯即可。
- 學會debug。有些情況下，即使發現了問題代碼，卻還是發現不了問題（比如說，報錯日誌說第xx行有問題，打開xx行一看，懵，這裡怎麼可能會有問題呢）。這個時候，你應該嘗試去debug代碼，通過運行時debug，分析數據，來發現問題。
如何避免
借用測試大佬的一句話："沒bug是不可能的，這輩子都不可能沒bug的"。
而我們要做的，一是要儘可能的減少Bug，避免問題重複出現；二是要遇到問題，快速修復。千萬不要害怕Bug，更不要擔心出Bug就不敢寫代碼。
簡單總結
最後的最後，就來做個簡單總結：
- 遇到問題不要慌，只要能復現，就能修復
- APP、H5、小程序三端快速定位，找到問題負責人
- 定位問題接口，找到問題代碼
- 如何快速定位問題接口
- 如何快速定位問題代碼
- debug then fix
- 總結經驗，避免再犯
閱讀更多 妖精的雜七雜八 的文章
