改Bug总结

【1】屏蔽取舍法

屏蔽取舍，即所谓与问题无关的前后“语境”完全可以忽略，首先屏蔽掉，再根据问题复现路径查看问题发生的区间，然后逐近锁定“病灶”，确定需要修改的目标。

【2】追溯原形法

追溯原形，即需要修改的区间已经找到，但是看似没有“病症”，那么怎么办呢？向父类或基类追溯，或许这个问题是历史遗留问题，不过在衍生物表现出了不正常而已。

【3】缩小范围法

缩小范围法，即利用弹提示框的方式找到了问题可能发生的区间，再要往“祖坟上刨一层”，就需要更加的缩小范围。针对于发布版更耐用。

【4】模式设别法

模式识别法，即实在找不到问题，代码也看得云里雾里（维护代码未必都是自己所写）的时候，想想是不是“作者”当初运用了某种设计模式，但运用的不“科学”从而导致了问题的发生。

【5】细节攻克法

细节攻克，即已经把问题锁定到了某个函数，甚至某个语句，这个时候需要专注细节，分析逻辑，调整语句内部的业务处理不合理地方，从而达到对问题的修正。

【6】示例独析法

示例独析，即问题已经明确，但是工程中的上下文语境不便于处理和测试问题，那么就需要单独再做个例子，从而进行模拟和分析问题的症结，然后找到处理问题的突破口。

【7】心想事成法

心想事成，即程序的思想其实很重要的。关键时刻，程序员还是需要思考，深入的用心想想问题应该如何处理更合宜或更有效，达到事半功倍的最佳效果。而不是盲目的下手。

【8】寻人启示法

寻人启示，即每个人都会有思维惯性的时候，当自己实在觉得没法下手，或者不知道该如何处理问题时，要及时的向周围的人寻求指点。或许，当自己在给别人描述问题症结的时候，自己就会一点一点豁然开朗了（有过这个经历，呵呵~）。

【9】换位思考法

所谓换位思考法，举个很简单的打电话示例。如果A打给B没有声音，那么，考虑B打给A有没有声音？能不能把A和B的话机对调一下再试一次？或者，有条件的话，给A或B换其他的话机试试。

 

Good Good Study, Day Day Up. 

顺序  选择  循环  总结