业务开发中的调试方法总结

摘要：业务开发中的调试方法总结这段时间，接触了单元测试，同时业务中遇到了一些需要排错调试的情况，就把自己的经验做个小结。但是如果你的业务经常变化，但是变化的部分并不会影响单元测试，那这种情况下的单元测试性价比就很高。

这段时间，接触了单元测试，同时业务中遇到了一些需要排错调试的情况，就把自己的经验做个小结。

狼叔说，常见的三种调试的境界

初级: 打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组件库都没见过。

这个时候我就比较郁闷了，想不通为什么这个世界上，大家就都不做二维表格的组件呢？

这也太奇怪了

- 于是我转而思考，为什么大家都不做二维表格，于是猜想是不是大多数的二维表格，是可以转化为一维表格的呢？

答案的确如此，二维表格跟一维表格是类似的，至于表头里数量不固定的问题，可以后端传值给你。然后你循环渲染就好啦。

所以面对没做过的需求，也不用着急，只要是合理的需求，我们好好思考，总归是有办法解决的。