文章来源：公众号findyi
好几个读者问：如何成为厉害的程序员?编码能力如何成长。回答完后，有些心得也给大家分享下。
其实程序员最关键的技能远不止编码能力，架构思维、底层知识的深度等等，同样很重要。
在这些能力中，最容易被人忽视却很重要的能力是：debug能力。甚至我认为：debug能力远比编码能力更重要。很简答，大家可以观察下自己的团队，最优秀的程序员一定会承担很多疑难症的排查和解决。
曾经在360带几十人技术团队，同时研发几条业务线。参与过的产品，日活过千万的有一款，过百万的有三款。
这个过程中各种稀奇古怪的bug见过不少，也一一解决了(不然估计就要滚蛋)。
分享下我的debug经验，希望对大家有用：
1.日志Log尽可能详尽
编程领域流传着一句话：必现的bug，都不是bug。
因为好复现，就容易解决，代码一直跟下去，或者看看堆栈信息，很快能定位问题。
真正困难的是偶现bug，甚至那种概率千分之几，但后果严重的bug。解决他们就需要详细的日志Log，尤其是关键点上的信息，非常重要。
2.google要用好
程序员+google=好的程序员，这句话真的没错，很多技术bug，当你毫无头绪之际不妨google下，可能不少人遇见过。
当然，最关键的是搜索的关键字，这取决于你对bug现象的描述，越言简意赅搜索到的信息反而越多。
3.排除法
这个方法说实话不提倡，但很多时候实在束手无策之际不妨用用，用法也很简单，当你不确定哪一块新增代码引入问题，就尝试注释一部分代码看看程序是否OK。
不行再换另一部分代码注释掉，很快你就可以缩小bug的查找范围，进而定位问题。
4.模拟用户环境
可以采用一些工具来模拟前端或者后端，制造假数据、假操作。有了这些工具之后，把你怀疑可能出问题的情况模拟一遍，观察是否会出问题。
其次，遇见一些极端情况，比如怀疑是多线程/多进程死锁，那不妨在某个进程/线程写个死循环看看bug是不是就出现了，当然做这种操作千万千万别给忘记了，提交了，那就完犊子了。
5.记录曾经解决过的bug，并简历索引
其实很多bug会变着花样反复出现，俗话说好记性不如烂笔头，把解决过的问题记录下来，并且做好索引，下次遇见可能相同的问题，先检索一遍，搞不好就找到答案了。
6.多看官方文档
特别是引用了第三方代码或者是开源代码导致的问题，官方文档对应的部分反复看看，可能问题就解决了。
7.引入工具，放大问题
比如很多线程注入的工具，你开启后，但凡是一点点依赖线程顺序的bug都会从偶现变为必现。
这个相当于主动把代码运行环境变成地狱模式，比如你的一个线程的结果依赖于另一个线程的输出，但你忘记加同步代码了，不过大部分情况另一个线程运行都飞快，但有些机器就不好使了。
这个时候加入这种工具，它直接让某些情况下另一个线程运行速度变慢(我猜大概率是加了个sleep(1000))，结果你的程序就崩溃了，崩溃堆栈直接打开，迅速定位，问题解决!
8. 制作工具，针对某些bug编写一些调试辅助工具。
比如，某些系统没有完善的崩溃报告，虽然也有dump，但是分析出来的callstack经常不准。完全可以为解决崩溃问题编写了个工具，自动扫描代码，在每个函数入口和出口插入log，以此来定位崩溃点。
以上8点，都是在实战血淋淋的过程中总结出来的，希望对大家有帮助。
最后，特别推荐一个分享C/C++和算法的优质内容，学习交流，技术探讨，面试指导，简历修改...还有超多源码素材等学习资料，零基础的视频等着你！
还没关注的小伙伴，可以长按关注一下：
标签：厉害,bug,程序员,满足,线程,解决,工具,代码 来源： https://blog.csdn.net/Hsuesh/article/details/115332741
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。