进入项目中时,项目已经是后期了,需要开发的东西很少,反而是bug层出不穷。
所以很多时候都是在处理bug,以前自己开发的时候,出现bug,由于熟知业务逻辑,以及后台代码,所以想想就能大致确定出现问题的地点:是前台?是代码?还是数据库。
但是修改别人的bug,就不是这样了,这些bug神出鬼没,很难一眼看到问题所在。经常需要从前台一路跟踪参数直到数据库,才能找到出现问题的地方。
修改了一些之后,也有了一些想法。
总的来说,发现问题,确定问题要按照
从前到后,由表及里。
也就是先看看前台传递到后台的参数是否是正确的。是否有遗漏,是否有编码问题。
前台没问题,那么第二步,
查看输入数据库的参数,手动执行带参数的sql。
为什么不是接着解决业务逻辑问题,而是直接看输入到数据库的参数是否正确?因为业务逻辑通常很复杂,很难一眼看清全貌,就像改卷子,先看结果对不对,再看解题过程。
其实执行完sql,问题就基本确定了。如果使用业务逻辑输出的参数来执行sql,结果是正确的。那说明程序执行期间出现了问题。代码本身是没有问题的。
如果sql不对,数据库会报错。
如果执行了,没有想要得结果,那么说明问题出在业务逻辑部分。
大部分时候,问题不是出在一个点的,那么就按照这个顺序,递归的执行。不断循环。就能解决问题。
这只是行动中自己的想法。很简陋,再有什么想法,再更新。