Loading

改Bug的经验

如果修复某个Bug花了很长时间,这时候就要问问自己为什么,怎么做才吸取经验教训,在类似的问题上不再出问题,以及采用的方法,使用的工具是否还有改进的地方;

当所有问题都解决之后,一定要梳理下从最初找Bug到最后改Bug的整个过程

定位Bug

  1. 模拟Bug场景:想想什么样的代码才能导致该Bug
  2. 二分法:代码一分为二,每次判断Bug在前面一段还是后面一段
  3. 使用调试工具:IDEA中打断点(多线程断点需要设置suspend为Thread,否则只能串行调试)
  4. 极限测试:用足够多的测试机,设置不同的极限条件进行测试,观察测试结果有什么规律
  5. 小黄鸭调试法:如果已经知道某段代码大概有问题,就可以找个对象(拿个小黄鸭放桌子上-_-)把这段代码对它一行一行的解释,甚至为什么这个地方用数组也要讲清楚。相当于用一种自言自语的方式,自发的梳理问题代码的逻辑,以解决问题

修复Bug

需要注意,在修复之前要理解代码,保证你的操作不会影响到其他部分,不然很容易制造新的Bug

重构

重构是使一些列手法,在不改变最终运行结果的前提下调整

  1. 看整体:检查Bug是否会影响其他支线,回顾所有审查及测试工作,检查整个系统的合并及最终运行情况。最佳的方式是补充所有功能点的测试案例
  2. 改细节:一步一步的重构(复杂代码也可优化结构,使代码更易于理解)
  3. review之前的review:在提交之前,找别人帮你review一下真个修复过程,看看方案是否完善,有没有更好的建议
posted @ 2022-10-03 09:53  fogey  阅读(30)  评论(0编辑  收藏  举报