大多数事物的本源还是相同的。折半就算这种方式吧。每次处理一半，来缩小范围。快速查找是种折半的思想。调试问题的时候，也可以这样的。如果能一下找到问题所在就在好不过了，但是，能这么做的人太少了，都是传说中的大牛。我还差点。调试就跟踪过程，找到问题。问题的定位过程基本是调试过程中最耗费的时间的过程，这个过程的准确性，效率行，直接影响工作效率。效率高了，就可以学习啊，休息啊,总之其他的东西就好了，就是马太效应啊。要是不高的话，加班啊 ，其他的不好的东西也就来了，其他的方面也会不顺的。调试过程中，一步一步的进行，固然好，但是效率不高。每次可以注释掉一半的代码进行调试，就很快的缩小范围了，范围缩小了，逻辑啊 ，就清晰了，代码也就好理解了。修改BUG的准确行就提高了，也不容易引入新BUg，当然要测试好。折半真是好方法。对代码理解多了，就方便重构了。其实出问题的地方就是不好理解，既然不好理解，就可以重构了。重构是中可以减慢代码腐烂的好实践。
据统计，大部分代码BUG都在20% 的地方，而且BUG一般都是接连出现的，这样，基本这般3次就够确定范围了。修改的同时，在重构下，就最好了。代码质量提高了，也清晰了，对以后的修改也是有好处的