博主最近接了一个大一些的任务，完成任务的过程中不知道解决了多少bug，有的解决不了还得请自己的师傅帮助[哭惹R]。但是收获真的很多，分享调试解决bug的心得。

一.任何任务不论大小，写代码之初都要有模块化思想

博主把这个任务全部完成后才进行的测试验证。遇到问题后就会发现无从下手，因为修改的东西太多，可能很多地方都有问题，bug叠bug导致非常难查找错误🔎。后面反思，我应该学会把这个任务划分模块，完成一块就去测试一块，而不是全部完成再去检验，模块化的写法会更容易帮助我找到bug。

二.打断点➕查看变量值，进阶灵活运用

打断点和查看变量值两种方法是嵌入式工程师debug的两个法宝了，但是我发现我运用的就没有我师傅灵活，原因如下:

1.经验不足，找断点的位置没有我师傅恰当。有时候产品表现出来的现象是一个功能错误，但实际上可能是另一个功能的问题。

目前想到的是，位置可能选不好，但我就多打几个断点，都看看现象，这样总会更好识别真正错误所在

2.打断点和变量值输出没有很好的配合使用。我师傅是一点点往下捋思路，不断进行打断点和输出变量的配合，仔细对比然后确定错误位置。我自己做的时候就太跳跃了，没有形成一个很好的逻辑链路去调试，配合运用也不够灵活

3.自信心不足。因为没有干过这么大的任务，所以总觉得自己做的不够好。

应该在心里大喊几句“老娘是浙大的，就是最棒的就是最棒的”哈哈哈哈，求母校赐予我自信心吧🧎🏻‍♀️

三.要考虑操作系统层面的问题

博主还发现，有很多bug不是自己写的代码逻辑有问题，而是操作系统层面的问题。

比如表现为接收不到数据，屏幕卡住等等，实际上不是这几个功能有问题，而是堆栈溢出了等等。还有的时候，是因为任务调度的顺序导致的bug，先A任务再B任务就没事，先B再A就有问题[哭惹R]。再次感慨，底层的重要性，所以博主一直分享说，建议大家学嵌入式要去学底层，博主自己的秋招项目也是底层相关，这既是面试通过的关键，还是未来完成工作的法宝啊。（长叹）

四.二分法注释法提取法，YYDS

如果修改代码很多无从下手，还有几种方式可以用来降低找bug的难度。就是把代码一分为二，或者部分注释，还可以提取部分功能，分头检验。也是很有用的方式。

又是努力向高级嵌入式工程师迈进的一天!