关于重构解决思路

关于重构
最近写代码发现一段很久之前自己写的代码太乱了, 逻辑不清, 维护太难.
遂准备重写一下, 写了一个礼拜了, 发现越改工作越多, 涉及10几个文件, 几千行代码了已经.
今天理了理思路, 准备推倒重来(还好有svn)
我总结了一下失败的原因
1. 绝不要轻易有重构的想法, 因为以前的自己或是别人写的代码可能要比想象的复杂的多
2. 改动前先规划一下, 比如画uml图. 必须把整个重构部分都理清思路再写.
   之前我理了一部分思路就改了, 发现不行
3. 我认为最重要的一点, 每一个版本(上传到svn)必须能编译, 且运行无误. 因为工程可能是多人开发的
   必须尽量保持和trunk同步. 为了同步就必须把自己的工作经常上传到trunk, 这就要求必须是可编译, 可运 行的.
   为了做到这点, 不要改以前的代码, 比如有个class A, 那就再定义一个 class A2, 这样等A2完全测试完成后, 就可以用最短的时间把调用A类的地方改成调用A2类.
   之所以认为第三点最重要, 是因为如果做到这点就不容易中途放弃重构了. 之前也做过几次改了几天然后放弃的经历, 都是因为直接改的老的代码

------解决方案--------------------
有时候重构一个可能还不如自己写一个来得快，呵呵，当然只是有时候。
------解决方案--------------------
重构对能力的要求比较高
------解决方案--------------------
个人意见：代码重构对程序员来说如同自掘坟墓。