Debug 

大概是两个月之前，有一次看他们调试硬件BUG，找了一个晚上，才堪堪锁定原因，中间沈德同有一句话，我感觉特别有道理，深以为然。

原句我已记得不是很清楚，大概的意思是：如果板子出了问题，又无法快速锁定问题来源的话，如果想要快速解决，只有将自己的刻板印象推翻，假设每一个部分都是有问题的，然后驻点排查，因为许多时候，我们在主观上认知到的问题的来源，往往不是正确的，或者说是不是主要的，或者只是问题的一部分。如果我们把问题锁定在这一个点上，当解决了这个点的问题，但是整体依旧是不能用的时候，我们回怀疑是不是这个点解决的有问题，然后很容易陷入思维的死循环中出不来。

硬件的问题和软件的问题是不同的，但是解决思路，我想至少从代码层面来说，是相似的。

对于软件问题的定位来说，由于出色的Debug工具，往往简单的问题可以得到快速的解决。但是因为软件的实现太过于容易，所以逻辑嵌套要远远多与硬件。

但是对于一些棘手的问题时，比如多个原因造成的，或者是多个环节共同影响造成的，或者是输入不规范造成的，或者干脆就是一些历史遗留环节和一些只有看了源码才能明白的实现细节。

通常代码问题的修改，并不复杂，通常就是一个点，几行或者是改个符号，就能解决，真正很麻烦的，往往是如何定位到这个问题点。

通常C#,python,这种解释器型的语言，在异常出现的时候，会给予比较全面的提示，就可以根据系统的提示去查找，然后通过百度就可以解决。

但是这个对于C++来说，就很难通过这样的逻辑去定位，之前遇到了一个多线程的问题，不稳定复现，找了一个晚上，最后发现是有一个在多线程中用了一个非线程安全的函数。

这样基本上就只能依靠经验去定位问题，二分法猜测问题的来源，或者是和原有的版本比较修改的地方，这同样也是使用版本管理的理由之一，可以根据修改用更少的时间定位问题的来源。

至于更多的东西，实用性感觉太少了，有些bug 甚至是不需要解决的，比如，如果多天稳定复现，但是在刚开始的时候，运行正常，这种问题，如果用户场景是每天都会重启，那么解决的必要性就不是很高。

等等。