调试经验总结

1. 在调试代码时，了解代码的含义往往能够帮助我们定位问题。欲速则不达。。。
2. 找出哪个变量出了问题，比如nw1的选择状态，然后通过监视变量的方式，去查看该变量的值。可能出现的误区，只是简单的打断点，虽然都是同样的变量名，但不能很快定位到发生问题的那个对象。
3. 解决bug时，要先找到问题出现的原因，只有了解了原因才能够较快的解决掉。我有一个不太好的习惯，看到旧版本ok，新版本不行，就热衷于去对比代码的不同，或者单步找不同。代码可能很多都变了，而且不知道原因，看到的都是表现，导致时间都花在了刀背上了。保持耐心，调bug不只是解决问题，更重要的是理解代码，这样一份时间就做了两份工作。
4. 在调试时，要看具体是哪个对象的，比如打印或者查看断点时，要看准对象的地址，而不要把不同对象的值混为一谈。
5. 一个思维定势:假如要看一个自定义容器类对象的元素是如何添加进去的,不要全局搜索这个类,这样是比较傻的.而要选择寻找该类下面的Add函数,因为想要添加元素,需要调用添加函数.
6. 看代码不仅要看纵向的堆栈调用,也要看横向的顺序执行.当不知道断点后发生了什么,那就在外层的主逻辑上打断点,然后看这里发生了什么.
7. 通常的代码形式:当前项目的.h,.cpp文件可以直接使用,而其他项目的代码则是通过库的方式来使用的.比如当前项目事先配置好别的库的路径和名称,在当前项目include进来库对应的头文件,就可以使用其中的函数了.如果库所在的项目发生了改变,需要重新编译库,然后当前项目才能够正确的使用,否则可能会报"undefined reference to…"的问题.
8. 遇到未见过的问题,优先按照问题提示去搜索,而非按照自己的推测去搜索.
9. 遇到直接崩溃但没有堆栈信息时,断点调试的方法不太可取,因为需要小心翼翼地去尝试.此时更适合采用打印的方式,比如通过”##########1###########”的方式来打印位置,比较容易确定崩溃位置.如果调试时代码执行的顺序和预料的不一致时，也可以如此操作。
10. 打印和调试的选择，如果要批量查看变量，并且需要多次，推荐使用打印。
11. 调代码前要花时间理解下逻辑,而非自以为很快的跳到下一个断点,而中间发生了什么却不得而知. 这是自己经常不注意的地方,当你都不知道它是什么逻辑的时候,如何能够快速定位到问题呢
12. 注意手动点击跳到函数位置不一定是准确的，IDE联想可能不准，此时断点来核对下。
13. 多处有要关注的变量,选择值发生改变的位置去打印.这种情况下不太适合用断点,因为很容易看晕。
14. 界面上出现的状态不正确时，优先考虑是否是刷新功能是否正确。
15. undefined reference就是那个方法的实现没找到。
16. QtCretor断点调试支持16进制写法，也支持&&操作。
17. 假如要查看对象obj的m_attr1发生改变的位置，可以通过查看obj哪里发生赋值或者m_attr1在哪里发生赋值，也要留意以引用类型返回的操作。
18. 如果要复用别人的代码，最好整体拿过来，如果感觉有些命名不太规范，后来整体refactor。如果提前改了变量名，可能和他的代码对照时，不太好比较。
19. 遇到CString赋值崩溃的问题,一开始一直聚焦在CString上,后来发现其类对象地址有问题,最后定位到是include和库不一致,崩溃。
20. 发现软件刷新几次之后，重复的内容越来越多。 -》 逆向思维：为何会重复？ 因为该删除的没有删除掉。-》找到删除的地方
21. 调试时,打断点有条件尽量加条件,想清楚要看哪个变量的值.比如如同一类当前对象异常,而下一个对象ok,在看函数时,要追踪异常对象的地址,而非无差别的看变量
22. 关键代码还是需要耐着性子看，不然想当然会给自己徒增工作量。哪些是关键代码呢？比如和文件生成，转化有关的地方。