BUG修复是程序员在实际工作中主要的工作内容之一。而整个BUG修复过程中又以定位问题最为重要。相对来说大部分情况下修改代码花费的时间可能只是整个BUG修复的三分之一或者四分之一。大量的时间需要花费在理解issue内容，定位问题原因上。对于定位软件问题原因，根据工作中的经历。我个人总结了一套方法论。
望闻问切是中医用语。其中望，指观气色；闻，指听声息；问；指询问症状；切；指摸脉象。合称四诊。古代中医通过望闻问切来定位病因并给出相应的治病方略。在BUG修复过程中也可以用类似的一个方法论来明细BUG修复过程，提高工作效率。不过顺序可能稍有调整，应该是“闻”，“问”，“望”，“切”。
“闻”（听闻）：
仔细阅读产品或者测试提出的issue，理解issue含义。需要归纳的点有：环境（代码版本，使用环境等），时间（测试时间），重现次数，操作步骤（详细的，但是提出issue的人理解的操作步骤不一定真的就是产生BUG原因的步骤，后面关于这块还会再讲到），预期结果，实际结果。
“问”（问询）：
如果在issue中没有获取到“闻”，想要的结果。需要自己主动联系问题提出人根据缺少的访问主动发问，收集问题症状。
“望”（观察）:
根据收集到的问题症状，查看相应的错误信息，找到报错代码。并从代码运行层面试图还原问题现场。在脑内模拟代码运行过程，定位可能出现问题的代码。并获得完整的复现步骤（如上面提到的，测试或者产品的提到的问题步骤或问题不一定是问题本身，有可能只是问题的表象。开发人员需要通过代码层面思考来找到问题发生的真正原因和步骤，这样才能从根本上解决问题）。
“切”（调试）:
望这一步结束后理论上应该已经知道问题发生的详细原因了，只需要对对象啊代码进行调整即可。但实际工作中也会发生单纯通过看代码无法定位问题原因的情况。那么就需要使用最终绝招了。“切”，切有两种方式，在情况允许的情况下最好使用debug模式，利用断点的方式一步步跟踪代码路径。如果不能debug，就要使用“log大法”。在代码中加入大量的能代表分支走向的log。去定位问题。实际上很难通过一次增加log就能精确定位到问题。如果不行就多加几次。
经过程序员版的“望闻问切”。问题的原因已经明晰，接下来就是相对好解决的编码阶段啦。