摘要：業(yè)務(wù)開(kāi)發(fā)中的調(diào)試方法總結(jié)這段時(shí)間，接觸了單元測(cè)試，同時(shí)業(yè)務(wù)中遇到了一些需要排錯(cuò)調(diào)試的情況，就把自己的經(jīng)驗(yàn)做個(gè)小結(jié)。但是如果你的業(yè)務(wù)經(jīng)常變化，但是變化的部分并不會(huì)影響單元測(cè)試，那這種情況下的單元測(cè)試性?xún)r(jià)比就很高。

這段時(shí)間，接觸了單元測(cè)試，同時(shí)業(yè)務(wù)中遇到了一些需要排錯(cuò)調(diào)試的情況，就把自己的經(jīng)驗(yàn)做個(gè)小結(jié)。

狼叔說(shuō)，常見(jiàn)的三種調(diào)試的境界

初級(jí): 打log

中級(jí): 打斷點(diǎn)

高級(jí): 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)

工作2年，這三種調(diào)試方法也算都接觸過(guò)了，當(dāng)然這是狼叔的看法，在我看來(lái)這幾種調(diào)試方式，就說(shuō)一下我認(rèn)為他們各自的適用場(chǎng)景,

第一種 打log

使用場(chǎng)景:

你完全了解這段程序的運(yùn)行過(guò)程，只是對(duì)某一個(gè)環(huán)節(jié)的運(yùn)行情況時(shí)，打印log

學(xué)習(xí)新知識(shí)時(shí)，通過(guò)打印的方式看看，他們是什么

這是最簡(jiǎn)單方便的調(diào)試方式，

缺點(diǎn)就是如果你不停的打印，再查看結(jié)果，是比較浪費(fèi)時(shí)間的。

而且如果你根本不知道程序的運(yùn)行方式，打log的方式就很低效了

第二種 打斷點(diǎn)

使用場(chǎng)景:

你想不清楚程序的運(yùn)行過(guò)程時(shí)，適合打幾個(gè)斷點(diǎn)

比如說(shuō)有一段復(fù)雜的異步操作、循環(huán)、遞歸，你完全不知道它運(yùn)行到某一個(gè)階段，是什么值，也搞不清楚他們的前后順序。

這時(shí)候打幾個(gè)斷點(diǎn)，不僅僅是多打幾個(gè)log，你還可以清楚的看到程序運(yùn)行的過(guò)程，前進(jìn)入哪里，進(jìn)入時(shí)的值是多少，都可以方便的看到。

第三種 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)

使用場(chǎng)景:

大多數(shù)場(chǎng)景都可以用，唯一的缺點(diǎn)可能就是比較費(fèi)時(shí)。

是否寫(xiě)單元測(cè)試可能更多還是要結(jié)合業(yè)務(wù)場(chǎng)景。

如果你的業(yè)務(wù)一旦變化，就會(huì)導(dǎo)致單元測(cè)試失效，而你的這部分業(yè)務(wù)又經(jīng)常變化，可能就不適合了。

但是如果你的業(yè)務(wù)經(jīng)常變化，但是變化的部分并不會(huì)影響單元測(cè)試，那這種情況下的單元測(cè)試性?xún)r(jià)比就很高。

你可以盡情的修改和優(yōu)化代碼，而不用擔(dān)心自己的代碼邏輯出現(xiàn)重大bug，畢竟有測(cè)試幫你檢查。

但是也要注意測(cè)試驅(qū)動(dòng)開(kāi)發(fā)，也無(wú)法保證測(cè)試通過(guò)，業(yè)務(wù)就一定沒(méi)問(wèn)題，畢竟業(yè)務(wù)往往是很復(fù)雜的，這涉及到代碼測(cè)試覆蓋率，就算測(cè)試覆蓋率100%也不代表沒(méi)有bug，只能說(shuō)所有代碼都被測(cè)試過(guò)一遍了

你看，其實(shí)這3種調(diào)試方式真的不分高低，比如你在寫(xiě)單元測(cè)試時(shí)，出現(xiàn)了問(wèn)題，還是要打log來(lái)檢查嘛，總不能為測(cè)試代碼再寫(xiě)一套測(cè)試吧。

將三種業(yè)務(wù)開(kāi)發(fā)中遇到一些“奇葩”問(wèn)題時(shí)的思路。

所謂的“奇葩”問(wèn)題，有時(shí)候真的是自己眼拙，或者自己排查的地方?jīng)]錯(cuò)，關(guān)注點(diǎn)錯(cuò)了，而你盯著那段真的正確的代碼，自然怎么檢查也查不出問(wèn)題。

所以有時(shí)候需要用一些小方法來(lái)排查

二分法排錯(cuò)

刪除法排錯(cuò)

對(duì)比排錯(cuò)

二分法排錯(cuò)

面對(duì)一坨代碼，你也不知道bug出在哪里，甚至都沒(méi)報(bào)錯(cuò)，或者你根本不想看這段代碼。

你就用二分法，第一行、最后一行、中間一行各自打一個(gè)log

因?yàn)閖avascript是自上而下運(yùn)行的，所以肯定每次都能把錯(cuò)誤范圍縮小50%

這樣應(yīng)該反復(fù)幾次就能確定bug在哪里啦。

刪除法排錯(cuò)

有時(shí)候是不是會(huì)出現(xiàn)，我沒(méi)動(dòng)呀，怎么剛才還好好的，現(xiàn)在就不能運(yùn)行了。

這時(shí)候你可以選擇注釋或者刪除掉一部分代碼，只留下你認(rèn)知里覺(jué)得正確的代碼。

不斷的刪除或者注釋?zhuān)钡讲辉賵?bào)錯(cuò)

那么，上一步還報(bào)錯(cuò)呢，這一端代碼被注釋后，錯(cuò)誤就消失啦，自然也就定位到bug的位置啦。

對(duì)比排錯(cuò)

有時(shí)候你也不知道是哪個(gè)版本出現(xiàn)的bug，似乎上幾次提交就有bug了，而你沒(méi)注意....

如果刪除法和二分法，都無(wú)法定位錯(cuò)誤，就只能git reset --hard了

回退到絕對(duì)沒(méi)問(wèn)題的某一次commit

然后利用二分法，找到某一個(gè)commit版本沒(méi)問(wèn)題，而下一commit版本就出bug了

也就說(shuō)，定位到問(wèn)題出現(xiàn)在那一次代碼提交

然后通過(guò)git diff 對(duì)于2次提交，究竟改動(dòng)了哪些代碼。

以上是我對(duì)于調(diào)試、排錯(cuò)的小經(jīng)驗(yàn)，再分享一種思考方式。

就是面對(duì)一個(gè)你從來(lái)沒(méi)有做過(guò)的需求，你不知道如何做，你甚至懷疑這個(gè)需求能不能做？

這種情況下，我建議只要是聽(tīng)上去比較合理的需求，就不用急著拒絕。

先分析一下這個(gè)需求是不是合情合理，真的對(duì)用戶(hù)有幫助。

如果合理，那么再想一想，這種需求是否常見(jiàn)？

畢竟常見(jiàn)的需求肯定有人做過(guò)，那么你也就不用擔(dān)心能不能做？如何做？之類(lèi)問(wèn)題啦

舉一個(gè)小例子

在業(yè)務(wù)中，老板要求我實(shí)現(xiàn)一個(gè)二維表格，
這個(gè)表格的2個(gè)表頭，橫向和縱向表頭數(shù)量不固定。
說(shuō)實(shí)話，我做過(guò)二維表格組件，當(dāng)時(shí)搞的比較麻煩，數(shù)據(jù)的結(jié)構(gòu)被設(shè)計(jì)的很麻煩，所以我就想找一個(gè)現(xiàn)成組件。

神奇的是，你發(fā)現(xiàn)怎么都找不到一個(gè)二維表格組件，而老板又叫的很急..
這時(shí)候面對(duì)的就是一個(gè)不知道如何做的需求。

我是這樣思考的:

- 這個(gè)需求有沒(méi)有意義？我覺(jué)得是有的
- 這個(gè)需求比較合理，但是否常見(jiàn)？似乎不常見(jiàn)，我從沒(méi)見(jiàn)過(guò)二維表格組件，比如element-ui或者其他主流ui組件庫(kù)都沒(méi)見(jiàn)過(guò)。

這個(gè)時(shí)候我就比較郁悶了，想不通為什么這個(gè)世界上，大家就都不做二維表格的組件呢？

這也太奇怪了

- 于是我轉(zhuǎn)而思考，為什么大家都不做二維表格，于是猜想是不是大多數(shù)的二維表格，是可以轉(zhuǎn)化為一維表格的呢？

答案的確如此，二維表格跟一維表格是類(lèi)似的，至于表頭里數(shù)量不固定的問(wèn)題，可以后端傳值給你。然后你循環(huán)渲染就好啦。

所以面對(duì)沒(méi)做過(guò)的需求，也不用著急，只要是合理的需求，我們好好思考，總歸是有辦法解決的。