重构比重写要好

“看懂还没重写来得快”

这还是要评估风险吧.
如果已经上线了,问题多多. 那只能是先分析业务,整理一下测试用例. 把测试覆盖到位.
然后逐个模块的整理,重构,迁移.

重写和重构是不同的两件事情，重写就是自讨苦吃，而且不一定能写出更好的。重构难度比较高，首先要了解之前的代码和坑，提出更好的改进意见，然后实施。我深深尝过重写的恶果，不过，系统中很关键的部分在我重写后得到了一致好评。原因是，我在设计时，前人提醒了我他们以前踩过的坑。这就说明这部分不是我凭空重写的，而是在有同事了解之前系统的协助下完成了“重构”，尽管代码确实是重写了一遍，但是我还是认为这个是重构。

由此引申一个问题:
为什么代码后人看不懂?
我认为过度设计是一个原因.虽然说不重复造轮子是一个公认的常识,但是一个复杂的,没有任何注释,文档的自定义轮子,对整个系统是更大的隐患.
我接手过一套代码,是android的系统.由4个项目组成.3个属于lib项目.其中有一个是上一个开发者引以为豪的自认为很屌的轮子库.但是他离开之后,后续招聘的开发人员都没办法很好的使用.原因很简单,无注释,无文档,并且由于时间的积累,继承关系复杂,一个类有N个构造方法.直到最后我接手了这套代码,折腾了一段时间,目前交给了一个只有一个月android经验的java程序员.
我的原则是2点:
1 化繁为简,对一些并没有什么卵用的封装,全部采用系统原生的或者最简单的方式替换,然后新的模块采用新的建档方式,老的模块逐步重构.
2 对于一些功能性的"轮子",采用GitHub上最流行的(fork和star)最多的,尽量减少自定义封装的数量.这样后人如果要维护,搜一下包名就知道是哪的.而这些最流行的项目通常文档,资源齐全,后期人员维护根本不费力.
总之我是一只很反对自己封装一些乱七八糟的库的.即使封装也要是轻量级,一看即懂,或者有详细注释+demo代码的.

我比较喜欢自己重写，尽量用流行的开源库，同时文档注释和版本管理也应该是技术团队应遵守的规范。

@zhouzhe8013 同意，用流行的轮子好处太多啦！