程序员每天都会debug，debug也有技巧，有些人de的快，有些人de的慢，甚至de不出来，需要总结一下。
感性的来讲，碰到一个程序问题，一般的思考步骤是怎样的？
首先需要了解问题是什么，从最直接的可能性出发进行分析。如果是自己碰到的问题这一点应该比较清楚，如果是别人发现的问题，并且已经有一些分析，却找不到答案，那么别人的分析最好完全忽略，因为他的分析是没有用的，只能了解他分析过程中得到的实际情况，从头分析。这时候，一定要先搞清楚问题是什么，然后思考会导致这个问题的直接原因有哪些，进而逐个分析排除。碰到比较诡异的问题时，一般人容易到处怀疑，实际上很容易误入歧途，浪费时间。一定要先分析最直接的可能，甚至验证那些已经认为是正确的证据的准确性，也不要先怀疑一些乱七八糟的问题，比如操作系统异常了，第三方库有什么bug，如果自己都说不明白的原因不要轻易怀疑，自己能想到的可能，用实验去求证。总之切忌胡乱怀疑。
其次需要善用对照实验。大系统的问题不能依赖大系统去解决，一定要拆解出小问题，然后对小问题进行实验验证。小问题的实验验证其实有点像单元测试，单元测试如果很充分，通常能够避免很多后期的bug，实在没有躲过的，可能是单测没有考虑到的case，这种时候增加单测，做一些小实验，既可以有效的发现问题，也可以补充单元测试用例，为后期的迭代作保障。有些时候也不需要重新构造实验，可以直接基于现有的系统，通过配置的方式屏蔽掉纷杂的干扰因素，找到产生问题的最小集，降低问题的复杂度，同时在这种实验的过程中也能发现引入问题的可能因素。帮助定位问题。
最后，如果这些方法都还找不到，那确实是非常棘手的问题了，需要时间来攻克。将问题放一放，看看能否再次发生，总结多次发生的共性，将这些信息综合起来，复盘前两步的分析。或者补一补相关的知识，有些时候问题无法进一步深入的分析，可能是受认知水平的局限导致的。这种认知既包括对相应模块的了解程度，也包括对系统的了解，所以走读代码，查阅系统知识，也许能带来一些思路。
其实Debug是十分有趣的事情，也是综合实力的展现时机。在一个公司里面，写代码的往往不比能解决问题的“救火队员”有价值。功力深厚的人才能更快的找到bug，因为他们有很多非常solid的经验和认知，可以帮助他们排除更多不可能的选项。Debug的方式方法其实不局限于程序，任何一个“系统”，不管是机械的、电子的、数字的、人文的等等，分析问题的方法是相通的。就像“新冠病毒”疫情，这是社会的bug，怎么找到这个bug，想必整个社会其实也在采用类似的解法。这不禁让我想了解一些非程序层面的东西，比如辩证法、建筑工程、社会学等等，也许能从中找到解决问题更高层面的抽象方法。
