工作中重构一个小工程时犯的错误

工程:是由两个人开发的,前期的基本框架完成后,后期遇到各种问题不停的往里面打补丁

最终工程代码是:cpp文件不超过10个   每一个文件里代码行数不超过500行

工程里存在的问题是:变量和类的命名不规范,部分LOG需要控制输出或者删除,部分代码需要重构改动,需要增加不超过3个文件   类的结构需要更改

 

本来我以为更改非常简单:于是按照自己的思路,重新调整代码,真正动起手来才发现并非易事

问题有:改了这个变量 重新编译发现不少文件里都有这个变量    尤其是用了grep在整个目录下完整替换,又遇到例如get_status  status  set_status

如果更改status这个字符串,其他的变量都改了

本来想好好设计下代码结构,发现不是那么回事,仅仅改变量和命名就花了3天时间,后来用了1周时间,基本功能测试OK 

后面问题来了,好好的代码,当时没有完全测试,最后用的时候发现不少问题,仅仅是基本功能OK    一些边边角角的特殊情况以及 除了功能以外其他的附属的测试工具都得

进行同步修改。

通过这个重构:

1.无论工程再小,不到万不得已,不要重构

2.我们平时打补丁,代码改动再少,自己再怎么肯定,一定要验证一遍,无论是编译还是相关的功能。

3.一个小小的补丁都尚且要求要验证 验证 再验证(编译到功能到附属的工具等等),更何况是  对工程进行重构呢

4.重构一个工程的验证步骤:由浅入深<1>编译能通过<2>patch不能遗漏<3>基本功能OK<4>代码里每一个关掉的宏开关及LOG都要 逐一打开或者同时打开,验证功能

<5>开发的测试工具和case都要相应地更新<6>代码提交后,后续在此基础上有开发的人 都要知道

总结就是:无论你对自己的代码多么肯定, 一定要动手验证,测试