天天看點

這些解決 Bug 的套路,你都會了不?

最近整理了我原創的 140 篇程式設計經驗和技術文章,歡迎大家閱讀,一起成長!指路:https://t.1yb.co/ARnD

大家好,我是魚皮。

學程式設計的過程中,我們會遇到各式各樣的 Bug,也常常因為它們而感到頭秃。

這些解決 Bug 的套路,你都會了不?

但随着你不斷解決 Bug、積累經驗,就會發現其實解決 Bug 也是有套路的。

今天分享下魚皮自己總結的解決 Bug 套路,幫助大家提高程式設計學習效率,保護頭發。

本文大綱:

這些解決 Bug 的套路,你都會了不?

其實改 Bug 的過程就跟破案是一樣的。

首先,在急着去搜尋問題、上手寫代碼改 Bug 之前,先做這麼幾件事。

就像案發現場找目擊者、搜集證據一樣。

我們要搞清楚 Bug 何時發生?為什麼會發生?在什麼情況下發生?

使用者到底做了什麼操作,才導緻了 Bug ?

是每次都會出現 Bug,還是說點兒背觸發了呢,如果是偶然觸發,是否可複現呢?

不能複現的 Bug,還叫 Bug 麼?

這些解決 Bug 的套路,你都會了不?

這些資訊,都很重要。如果可以的話,最好還能拿到使用者詳細的報錯原因、請求和響應,資訊多了,才能幫助我們更精準地定位和分析問題。

說白了,就是通過手上已有的資訊,搞清楚要把這個 Bug 算在誰的頭上?

舉個例子,假如說使用者突然通路不了你的網站了。這時千萬别自己先擱那傻傻分析和排查一通,而是可以先通路下網站試試。要是你能通路的話,說不定根本就不是 Bug,而是使用者自家的網線斷了!

這些解決 Bug 的套路,你都會了不?

企業開發中往往是多人協作,比如前端和後端、服務提供者和服務調用者,如何判斷是誰寫的 Bug 呢?

一般我們可以通過 接口 的請求參數和響應參數來劃分職責。

比如我是前端,請求你後端的接口,向你發送 "魚皮",你必須要傳回我 "狗頭"。結果最後出現 Bug 時,我一看,我給你發送的是 "魚皮",你卻給我 "魚頭" 了對吧,那顯然是你那邊的 Bug,雨我無瓜。

這些解決 Bug 的套路,你都會了不?

确定是自己的 Bug 後,如果是線上程式出了 Bug,記得先把當時的程式狀态保留下來,比如 dump 記憶體、下載下傳日志,便于後面排查。

就和破案一樣,案發現場的東西千萬不能随便亂碰,要不然可能就缺失了關鍵資訊。

接下來看看如何解決 Bug。

每個人的時間都很寶貴,出了問題時,建議先不要盲目地去問别人,而是自力更生,可以通過以下方式自己解決。

程式除了問題時,最直接的排查方式就是:對程式的報錯、已記錄的錯誤日志進行分析。

比如看到程式報錯 "db connection timeout",顯然就是資料庫連接配接逾時了,這個時候可以先去确認下是不是網絡和資料庫自身的問題,說不定就已經能解決 Bug 了。

俗話說得好,遇事不決問某度,這可能是大家最常用的解決 Bug 手段了。

這些解決 Bug 的套路,你都會了不?

但如今的某度搜尋引擎對程式員不太友好,廣告多、内容過時、點進去後文不對題,這些都會成為你搜尋的障礙。

那大家不妨試試這些技巧:

屏蔽廣告

在搜尋詞後加上 "-advertisement" 可以快速屏蔽搜尋的廣告資訊:

這些解決 Bug 的套路,你都會了不?

站内搜尋

使用 <code>site:域名</code> + 搜尋詞,可以在特定的網站内快速搜尋,像現在大部分 Bug 的解決方案其實都在 CSDN:

這些解決 Bug 的套路,你都會了不?

關鍵詞搜尋

使用某度搜尋長句的時候,可以将錯誤資訊中的關鍵詞拆解出來,比如版本号、資料庫類型等,使用空格進行連接配接疊加關鍵詞,可以更加精準搜尋想要的結果,避免連接配接詞的幹擾。

這些解決 Bug 的套路,你都會了不?

限定範圍

打開搜尋工具,可以給搜尋增加限定,比如時間、檔案類型等:

這些解決 Bug 的套路,你都會了不?

當然,其他的搜尋引擎也都有自己的搜尋技巧,大同小異。

此外,大家也可以試試 <code>開發者搜尋</code> ,專門面向程式員的搜尋引擎,純淨很多。而且看起來它的實作方式也很簡單,就隻從開發者相關網站中搜尋内容就行了。

這些解決 Bug 的套路,你都會了不?

當我們使用一些冷門技術或者較新的技術時,國内的搜尋引擎可能很難找到解決方案。

這時不妨打開官方文檔,直接搜尋到和自己問題相關的部分,仔細閱讀一遍,說不定就發現其實是自己文法或參數寫錯了呢?

這些解決 Bug 的套路,你都會了不?

其實,很多 Bug 就是因為閱讀文檔不仔細而産生的!

對于元件庫、SDK、類庫、插件、API 的使用,我其實更傾向于去閱讀官方文檔,比較直接,一針見血。

如果你使用的是開源的項目,那麼可以試着在項目倉庫的 <code>issues</code> 中搜尋答案,尤其是知名項目,用的人很多,你遇到的 Bug 有可能别人也遇到過。

這些解決 Bug 的套路,你都會了不?

如果有解決方案呢可以直接照搬,哪怕沒有解決方案,你也可以試着聯系遇到類似 Bug 的同學,共同探索。

除了依賴沖突、記憶體溢出之類的技術上的 Bug,其實我們工作中更多地是修複業務邏輯上的 Bug。比如做一個支付功能,使用者 A 扣了錢,但是沒有任何反應。

那麼這種情況也别費功夫在網上搜了,因為每個人寫的業務代碼都不一樣,五花八門。不如自己從程式的入口開始,用 Debug 打些斷點、列印一些變量資訊,一行一行慢慢調試就好了。

這些解決 Bug 的套路,你都會了不?

如果你懷疑是某個依賴的類或方法出了問題,也可以直接點進去檢視它的源碼和注釋。

如果自己無法解決問題,我們就隻能向他人求助了。

提問也是有技巧的,想要更快、更準确地獲得答案,就要把你的問題、場景、前因後果、關鍵資訊都提供清楚,還可以利用 <code>PasteBin</code> 之類的工具分享代碼,讓别人更好讀懂。

這些解決 Bug 的套路,你都會了不?

像我每天都會收到上百條私信提問,其中很多同學連自己要問什麼都描述不清楚,比如:我網站為啥無法通路了?

這種問題我怎麼幫你解決呢?這不是耽誤彼此的時間麼?

是以我建議大家去閱讀《提問的智慧》這本免費小書,教你成為一個有智慧的提問者。

位址:https://github.com/tvvocold/How-To-Ask-Questions-The-Smart-Way

想好問什麼之後,找誰問呢?

首先是兩大平台:國内的 <code>CSDN</code> 相對适合初學者;國外的 <code>Stack Overflow</code> ,更活躍、解答人數會更多。

這些解決 Bug 的套路,你都會了不?

如果是開源項目,可以考慮在 GitHub 項目倉庫下自己提一個新的 <code>Issues</code> ,艾特團隊官方人員去解決。

這些解決 Bug 的套路,你都會了不?

如果你用了别人提供的類庫和服務,可以在官方文檔中找到項目的維護者,聯系他們并回報。

此外,你也可以加一些專業人員的好友、加些程式設計交流小隊之類的抱團取暖,都是不錯的。

最後,如果以上方法都解決不了 Bug,那不妨試一試:重新開機 !

重新開機大法好,Bug 逃不了。重新開機還不行,那就解除安裝重裝~

以上就是本期分享,我是魚皮,求個 點贊 ,這将是我持續創作的最大動力,謝謝 🙏