如何安全的修改原有代码---android mms player调试总结

如何去安全的在别人写的现有代码基础上修改或者添加功能， 尽可能少的引入bug？

修改或添加代码的效果，都必须基于对现有代码的理解程度，理解得到位，改起来就顺利一些， 而如果理解不到位，就容易产生疏漏。

当然对于一个比较大的系统，比如android， 想看懂其中哪一个模块都是不容易的。很难一下子就保证完全理解正确， 那是不是要等确定完全理解正确才下手呢？

从《代码大全》中认为，很多问题都是“险恶”的，你必须首先把这个问题“解决”一遍，以便明确地定义它，然后再次解决该问题，从而形成一个可行的方案。希望把代码完全理解，然后设计、修改，最后一次性就解决问题那是不现实的。

首先，仔细阅读现有代码，在确认比较理解之后，可以开始着手解决问题，提出修改方案，与相关同事讨论，讨论清楚后再下手改代码，同时每次在修改时注意打上标签，方便以后回溯。完成修改后，仔细检查，在脑子里模拟运行几遍，把低级错误排除掉。然后开始验证。

这里要说的是，在解决问题之前准备工作是很重要的，一个错误的方向往往会导致一个错误的结果，对效率的影响还是很大的。多讨论、多思考，在设计时就应该严谨一些。

在验证时，不要仅仅满足于功能看起来完成了，在关键点打上日志或者借助一些调试工具（gdb?），仔细观察运行状态，不放过任何一个看起来无意的异常， 因为它们极有可能在某个临界点崩溃。尽可能的让它由表及里都正确。

事实上，很多时候事情并没有想象中的顺利，在运行调试时，你会发现对代码逻辑原本就有点模糊的理解现在又变成了一团浆糊，调试变成了不断的瞎猜乱试，然后寄期望它突然恢复正常。这时要小心了，继续下去只会产生一个漏洞百出的破烂。 不妨跳出来，再看一看代码，重新理一理思路，等理顺时，对问题的理解又上升了一个台阶。ok，接下来再重新从整体上修改设计，实现，验证。。。这样一个个循环下来，你对问题的理解越来越全面，添加或修改的代码也能更自然的融入原来的体系，安全性也就大大提高了。

解决问题分为几轮：

1. 在现有领域知识背景下，尽可能把问题思考清楚， 然后解决一遍问题。 容许犯错， 渐进式解决问题。

2. 第一步由于知识受限， 你的思考会存在盲点， 现在解决过一遍后， 你会更清楚问题， 在重新从整体上思考一遍问题， 思考清楚，条理化， 再解决一遍问题。

这次的任务是添加彩信手动播放小功能，工作量不大， 收获却也不小，里面有一些经验教训很值得一说。最想说的第一句话是： 靠肉眼看，凭逻辑推是不够的！

调试时有一个问题一直在纠缠我。彩信播放时是按页播放的，每次快进/快退时，需要先停止当前页的播放和媒体元素信息(如播放的音频文件名和图标)的显示，重新加载新位置的彩信页，并更新新页媒体元素（如音频）显示信息，然后继续播放。bug的现象就是在播放含音频的彩信时，拖动播放进度条进行快进/快退，元素信息停止显示，然后就没声音了。 要命是它还不是每次都没有声音， 时有时无。 我的调试方法就是靠肉眼看，凭逻辑推：仔细看代码， 推敲每一处的逻辑， 在可疑的地方修改， 编译后下载到手机上验证看现象是否消失。

可是呢，调试的过程异常不顺利，改代码-重新编译-下载，效率低下我也就忍了，关键是怎么改现象都还是“涛声依旧”，最后能检查的都检查了，能改的都改了，还是一次次失望。。。实在猜不出问题所在，于是下了个结论，系统本身的bug，藏的很深，搞不定。

第二天请来高手帮忙，他根据现象，猜测可能是在哪里调用了停止播放的函数，导致重新加载页不成功。我立即说，不可能，我仔细检查代码了，不可能调到那里去。他依然坚持自己的观点，然后在关键点打上log，并打印相应变量的值，最后告诉我，机器是不会骗人的，调了就是调了，没调就是没调，跑的时候看一下日志就知道了。 由于他也很忙，加上那些日志代码后，就走开了。

我坐在那里，心想怎么可能，逻辑上都推不过去。半信半疑的下载到手机里， 然后一行一行的看日志，晕，还真的调了！根据其他的日志信息，我很快找到了问题所在，一切也就迎刃而解了。

通过这个印象深刻的经验，我得到了以下的关于调试的体会：

1. 在修改bug时，不要急于把现象去掉， 那样可能暂时现象不重现了，但却没有真正解决bug，还会隐藏的更深，迟早还会爆发的。治标更要治本，到处瞎试是没用而且危险的。（写给自己： 通过sleep减少了现象重现几率，但还是没有真正解决问题）

2. 通过bug现象，可以初步猜测问题所在，然后在可疑点处打log，运行中仔细验证你的想法。跟进去看看具体发生了什么，你才能真正成功调试。--大胆假设，仔细验证。

3. （写给自己的）还记得joel 写的 leak of abstraction吗？