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

這段時間，接觸了單元測試，同時業務中遇到了一些需要排錯調試的情況，就把自己的經驗做個小結。

狼叔說，常見的三種調試的境界

初級: 打log

中級: 打斷點

高級: 測試驅動開發

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

第一種 打log

使用場景:

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

學習新知識時，通過打印的方式看看，他們是什么

這是最簡單方便的調試方式，

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

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

第二種 打斷點

使用場景:

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

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

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

第三種 測試驅動開發

使用場景:

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

是否寫單元測試可能更多還是要結合業務場景。

如果你的業務一旦變化，就會導致單元測試失效，而你的這部分業務又經常變化，可能就不適合了。

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

你可以盡情的修改和優化代碼，而不用擔心自己的代碼邏輯出現重大bug，畢竟有測試幫你檢查。

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

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

將三種業務開發中遇到一些“奇葩”問題時的思路。

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

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

二分法排錯

刪除法排錯

對比排錯

二分法排錯

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

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

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

這樣應該反復幾次就能確定bug在哪里啦。

刪除法排錯

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

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

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

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

對比排錯

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

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

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

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

也就說，定位到問題出現在那一次代碼提交

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

以上是我對于調試、排錯的小經驗，再分享一種思考方式。

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

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

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

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

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

舉一個小例子

在業務中，老板要求我實現一個二維表格，
這個表格的2個表頭，橫向和縱向表頭數量不固定。
說實話，我做過二維表格組件，當時搞的比較麻煩，數據的結構被設計的很麻煩，所以我就想找一個現成組件。

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

我是這樣思考的:

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

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

這也太奇怪了

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

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

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