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

昨天写完如何把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，对测试人员来说是非常有利的，而对开发人员来说却是相当不利的！

 

 

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