通过“打断点”找到真相

最近一段时间的工作让小胖对如何解决问题有了进一步的看法，虽然这是工作中得来的，但前面的问题可以泛指所有的问题。

题目中的打断点是程序员们的专业术语，因为开发们写的程序免不了有 bug，也就是问题，可是问题表现出来只是一个现象，一般很难通过表面看到问题是什么。

就如咱们平时在使用软件时候就可能遇到在一些情况下自己明明没有点击返回键啥的，可是软件就莫名其妙的退出了，有的 Android 手机可能还弹窗提示软件崩溃了。

对于咱们用户来说，可能知道这软件出问题了，但是什么导致的这个问题咱不知道。其实即使是做这个软件的人看到这种突如其来的崩溃也很难一眼看到问题的本质是什么，而打断点就是一种帮程序员直击问题本质的方法。

那么打断点是如何帮助程序员找到问题的根源的呢？软件崩溃只是一种现象，而软件能够运行一定是因为我们写的一行行代码在运行，那换言之崩溃就是我们的某一行代码执行的时候出现了问题，所以我们只要找到了运行出问题的那行代码也就定位到了问题。

可是代码那么多行，互相之间的依赖关系可能也不少，即使是同一行代码也可能是在不同的情况下运行的，所以我们需要清晰的捋顺这个关系，并且结合当时用户操作来定位问题。

这个靠我们坐在那里想应该也是可以的，但是难度极大且效率低下，因为不是每个人的空间想象能力、逻辑思维能力都那么强，那有没有一种方式将这个过程可视化呢？将出问题的过程给放大放慢呢？

就好比古代两个剑术高手比武，他俩的剑实在是太快了，快到以至于其中一个一剑封喉了对方，我们都不知道是哪一剑封的喉，但如果我们让着两个人在比武的时候将动作放慢 10 倍呢？因为我们将这个比武的过程放慢了、放大了，所以咱们就可以清晰的找出来是哪一剑了。

对的，打断点做的就是类似的事情，它可以让我们的代码执行速度变慢，并且每一行代码什么时候走，在什么情况下走我们都可以实时的看到，胖友们，我们都这么清晰的看到了这整个过程，那找问题还不是分分钟的事情呀？看到这里的非编程领域的胖友有没有想来解个 bug 的冲动？(坏笑脸)

我们可以看到打断点真的是可以将程序员从表面的崩溃带到背后出问题的根源面前，这真的是一大利器。后来小胖就想这一利器我们是不是也可以用于生活中呢？当然我们没有打断点的工具，但是这种思维方式是真的很有用。

我们总是避免不了遇到各种各样的问题，我们可以选择忽略问题，就如程序员遇到一个 bug 视而不见，可是我们不见不代表 bug 不存在，总会有一天它会给我我们沉重一击，生活中的事情也是如此。

所以解决问题的第一步就是面对问题，如果连问题都不能直面，那还怎么打断点呢？即使现在侥幸逃脱，可是谁又能保证次次逃脱呢？

直面问题可能会让我们很没有面子，或者很痛苦，但是就是要求真，就是要对自己透明，不要自己欺骗自己。相对于解决问题那些面子啥的不重要。

假设有了第一步已经面对了问题，那第二步就是找到问题的根源，因为问题出现的时候总是会给自己戴一个面具，它极具迷惑性，我们得果断的把那面具给撕掉，让其露出其真面目，这个过程就需要打断点了，需要我们尽量的将整个事情给还原，一个个环节的去想，我们没有打断点的工具，但是我们可以写、可以画，这也是可视化的一种。

而到了第三步就发现了问题的真相，才知道这个问题究竟是什么，但这里也只是走到了一半，我们可能会发现被撕下面具的问题比戴上面具时候更加可怕，我们甚至会退缩，解决它也可能会让我们很痛苦，也可能会让我们觉得这问题根本就是死结，根本就没法解决。

还是说说小胖在工作中遇到问题的时候吧，很多次都到了抓耳挠腮的地步，但是小胖坚信一切问题都有它的解决方法，只是方法有好有不好而已，就是这种坚信、这种相信让小胖解决了一个个最初看起来都好难的问题。这里的相信极其重要，因为如果我都不相信我能解决这个问题，那我怎么可能解决这个问题呢？

以上就是小胖想跟大家分享的自己关于解决问题的一些想法，胖友你关于此有什么想说的欢迎后台留言。胖友们，周末愉快。