程序员的踩坑经验总结（二）：如何用巧力解决问题

昨天写完如何把Bug的偶现变必现，后面想了想，好像没过瘾！再细细考虑了这些年的踩坑经历，有几个方法很是值得一提。

 

四两拨千斤

我印象中，用这种方法解决过好几个问题。这个会颇有成就感，曾经在微信上表达过喜悦之情（见后面截图）。总的说来，不要从正面来解决冲突，从侧面加小量代码，改变正规思路，就能够解决一个大问题。

这里能够举一个较近的例子。年初，回放的视频动态变化频繁的时候，在启动的前2-3秒会感受明显的慢，过了这个时间点就正常了。这种慢就至关于慢放的感受。在视频动态不明显，即比较静态的时候，是感受不到的。咱们行业大部分是后面这种视频，测试模拟视频源也换成了菜市场门口的了：）

总之，这能够说是性能优化的问题或者说平滑过渡的问题。通常性能优化的问题，能够日后一点，对一个软件系统来讲，稳定性最重要！如今有时间了，年初疫情之时，正好能够思考下。

怎么改？从回放机制来讲，并无大问题，由于后面立刻能达到正常速度。真正缘由是由于前几秒秒没有参照物。具体是这样的，回放的速度虽然有个默认值，可是能够根据计算前面几秒的速度是偏快仍是偏慢来进行微调！而刚启动的时候只能根据默认值来进行控制速度了。机制没问题吧，考虑仍是比较充分的吧。可是如今问题也要解决，既然机制没问题，也就不能动。可是这个开始几秒的速度也是机制的一部分。这里就产生了矛盾，开始有冲突了，左右不是！难道就由于这1-3秒改下机制，退一步，改下前几秒的机制呀！很差改，懂视频的知道，1秒有25帧呢，2秒有50帧，改前面这50次？明显不合理。并且计算机处理的速度更快，纳秒级处理一次数据了。边看代码边思考，后面想到了之前作过一个项目音频的淡入淡出，人为的让开始和最后几秒渐变的方法。那就反过来了，从快渐变到正常速度！方法有了，在哪一个位置改？之前的代码已是一个总体。又回到了前面的问题，改机制不可取，几秒钟几十帧好屡次循环呢！看代码，速度有个时间相关参数，又有方法了：加函数传参数就能够了！后面写代码，十来行！固然，既然要作到平滑，就须要通过大量测试，来作微调！

最后，还能够提供另外一种思路，客户端来修改。例如客户端能够推迟半秒钟解码播放，这个问题也许就更容易了。

  

围点打援

在我印象中，用这种方法解决过一两个问题。也是不要从正面来解决冲突。用这个方法，每每是缘由比较复杂，不易搞定。正面改动又太大。能够考虑从外面多处着手，多处的小改动，最终达到解决问题的方法。我记得当时的感觉是，跟建房子同样，须要外面的支架支撑，即从多处着力。因此这种方法能够解决问题，可是算不上一种上乘的方法。但最终仍是能解决问题，主要是不须要改动原有的机制。

问题过去时间有点久远，之后应该有机会碰到，再做补充！

 

以上两种方法，看似不一样甚至有点对立，实际又是一致的：

1.都是少改动，尽可能减小修改代码的量即不动原有机制而能达到一样的效果。

2.在对相关原理以及对做者的原意要有充分了解的基础上。

3.具体问题具体分析，突破思惟定势。

4.用巧劲，而不是用蛮力。

固然，若是要能用得上巧力，前提是设计的架构没有大问题。保证稳定性是基本的，解耦也是基本要求，最好还能考虑可扩展性和可维护性。例如第一个案例加个函数传个参数没有多大影响。

 

 

最后，咱们再来看看曾经的（当时的）喜悦心情，有图有真相：）

　　　　 

　　　　 

我想说，应该还有更早的Bug，不搜索了：）。说实话应该上Bugfree搜，好了，不作评价，不展开了哈。

但是我又忍不住多说一句，Bug也是分质量的，即Bug也分好坏的。上面的Bug固然是好的，那什么Bug是很差的。有的Bug就是食之无味、丢之惋惜的那种吧，让你啼笑皆非的是还把Bug级别定的很高。让我不得不又提及HW的经历，可能大家都烦了，我本身都烦，好汉不提当年勇，不是吗？当时做为测试，提Bug是有很是专业的培训的。有些约束，记得最清楚的两条。

1.提Bug必定要找开发人员定位，由于当时环境及其重要，同时要和开发人员确认是否是问题，只有开发人员默许了，才能提Bug。

2.Bug的级别仍是掌握在测试人员手中，可是对Bug如何划分级别有专题培训。并且Bug流程须要通过主管审核，必定是流程上主管经过了，才能走到开发人员那里。若是级别总是把握错了，那你就遭殃了，谈话去吧。

固然这和HW的绩效考核也有关系，一个高级别的Bug，对测试人员来讲是很是有利的，而对开发人员来讲倒是至关不利的！

 

 

后续对踩坑经历还有专题介绍：内存泄露和死锁，敬请期待。