改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一下真个修复过程，看看方案是否完善，有没有更好的建议