怎么维护前同事的代码一？

随着工作时间的增加，越来发现大多时候不再做新功能，而是维护前同事的已有功能。开始总报着天真的态度，“这些已有功能应该是完美的，不需要自己的深入理解，更不需要另外考虑实现方案。”

 

可是最近出现了一个严重bug——在一定的操作条件下，死机！因为赶着出版本，一下子很紧张。

 

1，从测试了解bug出现的环境：产生一个很大的图像（超过10M吧），再进行高倍数的放大，出现死机。

这个路径测试也一般很难走到，所以到临出版本才“意外”发现，大家都很紧张。

 

2，赶紧联上调试器，让测试来重现一把，死了！从死机位置看到是死在delete处。

 

3，很容易就怀疑是内存访问溢出导致，因为只有从目标机器才能得到那么大的图像，而凭着自己的经验，没有在目标机器装boundchecker，在delete死机的内存利用调试器增加条件断点。奇怪，没有捕捉到溢出访问，但在delete时还是死机。

 

4，无效指针被delete？从代码上分析，这个指针的分配和释放看不出任何问题。但从调试器认真的看，还是可以看出，这个指针是错误的指针。那么为什么这个指针会变成错误的指针呢？

 

5，了解这个指针的分配释放过程：预分配一定的空间，当需要的空间大于已分配的空间时delete后重新分配。死机时正是要重新分配前的delete过程。

 

6，问题原因：因为上一次delete后，重新分配因为需要的内存过大而失败，下一次又来delete已经失效的指针。

 

回到标题的“怎么维护前同事的代码”

 

这个问题已经有解决办法：放大时不要直接处理那么大的原始图像，因为显示大小总是有限的，即使放大多少，显示的还是那么一块。即每次放大只处理需要显示的那小块图像数据，即提高了速度，也降低了内存使用。但是这个处理方案对于目前的版本已经来得太迟，暂时只能处理调死机的问题，方案的更改要等到下一个版本来处理了。

 

如果早点理解当前的方案，想到更好的方案进行更改，那就不会出现现在这种情况了。所以维护代码要积极的维护，深刻理解需维护的代码。