讓我掉下眼淚的 不止記憶體洩漏

讓我夜夜不眠的 不止你的需求

明天還要改多久 你攥著我的手

讓我感到為難的 是善變的需求

釋出總是在半夜 回滾是永遠的愁

錯誤(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就不敢寫程式碼。

簡單總結

最後的最後，就來做個簡單總結：

1. 遇到問題不要慌，只要能復現，就能修復

2. APP、H5、小程式三端快速定位，找到問題負責人

3. 定位問題介面，找到問題程式碼

   • 如何快速定位問題介面
   • 如何快速定位問題程式碼

4. debug then fix

5. 總結經驗，避免再犯

---

歡迎關注公眾號：

相關推薦