工作中重构一个小工程时犯的错误
工程：是由两个人开发的，前期的基本框架完成后，后期遇到各种问题不停的往里面打补丁
最终工程代码是：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>代码提交后，后续在此基础上有开发的人 都要知道
总结就是：无论你对自己的代码多么肯定， 一定要动手验证，测试