重写的代价

　　记得有一次与人讨论某个程序的移植工作时，一位程序经理对我说：“最好还是不要重写，一重写就有可能写错。”这两天完全被这句话说中了。最近我就在重写那个程序，一方面是为了将它移到CUDA上，另一方面也是为了使代码变得更好看、更易维护。谁知昨天晚上将其中一个关键部分写完之后，程序的运行结果一直不对。我花了整整一天时间走查代码与调试，直到半个多小时以前才把那些写错的地方给修复了——不止一处地方写错了，而且都是粗心大意的错误。还好使用Nsight可以在kernel中设置断点，让CUDA程序的调试方便了不少，否则真是欲哭无泪。如果仅仅是走查代码，那就像以前考试快交卷时发现某道大题的结果不对时一样——看了n遍都觉得自己写得没问题，但结果就是不对。

　　看来如果对关键的业务逻辑进行重写，风险真是不小。尤其是科学计算用的软件，其业务逻辑本身就比其他软件要复杂得多，重写起来更是容易写错，而且也更难对错误进行排查。

　　不过从敏捷开发的角度讲，为了提高程序的可维护性和可扩展性，不断重写却是更为提倡的。不得不说这是一个矛盾。这里面应该蕴含着成本与收益的问题吧。