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

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

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

初級: 打log

中級: 打斷點

高級: 測試驅(qū)動開發(fā)

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

第一種 打log

使用場景:

你完全了解這段程序的運行過程，只是對某一個環(huán)節(jié)的運行情況時，打印log

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

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

缺點就是如果你不停的打印，再查看結(jié)果，是比較浪費時間的。

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

第二種 打斷點

使用場景:

你想不清楚程序的運行過程時，適合打幾個斷點

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

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

第三種 測試驅(qū)動開發(fā)

使用場景:

大多數(shù)場景都可以用，唯一的缺點可能就是比較費時。

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

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

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

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

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

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

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

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

所以有時候需要用一些小方法來排查

二分法排錯

刪除法排錯

對比排錯

二分法排錯

面對一坨代碼，你也不知道bug出在哪里，甚至都沒報錯，或者你根本不想看這段代碼。

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

因為javascript是自上而下運行的，所以肯定每次都能把錯誤范圍縮小50%

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

刪除法排錯

有時候是不是會出現(xiàn)，我沒動呀，怎么剛才還好好的，現(xiàn)在就不能運行了。

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

不斷的刪除或者注釋，直到不再報錯

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

對比排錯

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

如果刪除法和二分法，都無法定位錯誤，就只能git reset --hard了

回退到絕對沒問題的某一次commit

然后利用二分法，找到某一個commit版本沒問題，而下一commit版本就出bug了

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

然后通過git diff 對于2次提交，究竟改動了哪些代碼。

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

就是面對一個你從來沒有做過的需求，你不知道如何做，你甚至懷疑這個需求能不能做？

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

先分析一下這個需求是不是合情合理，真的對用戶有幫助。

如果合理，那么再想一想，這種需求是否常見？

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

舉一個小例子

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

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

我是這樣思考的:

- 這個需求有沒有意義？我覺得是有的
- 這個需求比較合理，但是否常見？似乎不常見，我從沒見過二維表格組件，比如element-ui或者其他主流ui組件庫都沒見過。

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

這也太奇怪了

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

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

所以面對沒做過的需求，也不用著急，只要是合理的需求，我們好好思考，總歸是有辦法解決的。