重构的一些想法， 如何对待公司里面的旧程序

正在维护这个C混合C++的代码， 上个星期打算重构里面的一些数据， 主要是把C的代码往C++迁移， 让代码看起来舒服一点， 例如函数参数过多（17个你敢信）一些两级指针， 甚至有些数据用单指针表示链表， 不把代码全看完还真不知道他想干嘛。 orz...。

本来打算改一改， 但是花了大半天时间，根本没办法完全改完， 数据结构与函数， 函数里面的算法都是紧耦合的， 牵一发而动全身。就算改完了还有测试工作， 这个项目是没有完整的测试用例来做回归的， 只能靠随机测试。这样难保不会出现按下葫芦起来瓢的情况，不能保证不搞出其他bug。 同时，  而新能功能还得做， 只得暂缓了。

 

今天看到一遍文章，  对现在遇到的问题受到启发：

 

我们的代码中有一个模块完美地工作了很多年了，只是代码太乱了。我说服了我的老板，我可以重写这个模块，于是我花了三个星期来重写这个模块。今天 ，我还记得，我的老板站在我的后面看着我，而我在在流着斗大的法汗珠去fix被我重写的“超级漂亮”的那个模块中一个接一个的bug。从那以后，我再也不重写代码了，除非有重大的利益。

点评：这就所谓的屠宰式编程。这个案例告诉我们两个道理，1）维护代码要用最最最保守的方法来进行。2）重构代码前要像一个商人一样学会计算利益。当然，ThoughtWorks的咨询师一定会告诉你TDD，结对，极限等等方法告诉你如果实践重构。但我想告诉你，一个程序在生产环境里运行好几个年能没有问题是一件很不容易的事，那怕其中的代码再烂，你再看不过去，你都要有一个清醒的头脑明白这几点，1）软件的运行质量是远远大于代码质量的，2）你的测试案例是远远小于生产环境的，3）软件的完美的质量，是靠长时间的运行、测试和错误堆出来的，而不是某种方法论。

来源： 程序员那些悲催事 

 

 

衡量收益， 是应该考虑的一个方面，  对于我现在的情况， 收益确实不大， 以后没有绝对必要， 应该不会去改旧的数据结构了。