关于代码重构的一些想法

代码重构与迭代是系统开发过程中必然经历的过程。从我个人的认知来说，我追求完美，喜欢做出一些让自己赞叹的产品，我关注代码实现的细节。

个人开发经历中，做过几次比较大规模的重构。第一次是在学校，做政府项目，自己开发，自己测试，自己打包，自己release版本。当大到一个系统，或小到一个函数，自己看着觉得不爽的时候，基本可以确定，实现已经不是最优的了，至少在自己的认知范围内，必然有优化的空间。我就是用这样的方法不断的删除自己写的代码，不断替换掉每一个觉得不爽的模块，不爽的函数，不爽的空格。下面的几次都是在工作中遇到的，随着产品需求的不断更新，一些陈旧的设计，已经不能符合功能或设计的需求，重构工作就必须展开了，大公司，好像不是那么喜欢动大手术，这个可能和产品规模、项目规划有关吧，再或者是开始的架构设计就比较好，后期能维持比较长的时间来满足市场的需求。小公司，重构迭代的速度相对的快很多，有时候快到昨天的系统，今天很多模块已经不认识了。

        对一个相对较复杂，较大规模的系统进行重构，必须有一批对原系统了如指掌的人，否则，重构过程中会走很多弯路和老路，走以前系统走过的各种坑。我个人觉得，新人是不适合对一个系统进行大规模重构的，除非这个系统比较小，很少的时间和精力就可以hold住，否则，对系统了解不是十分清楚的新人，最好还是从模块化做起，做里面的小模块，一边做一边对系统进行吸入。只有对系统功能和主要问题症结有深刻了解的开发者，才有可能在最短的时间内，做出一版更加优秀的设计，实现系统的升级调优。在不了解系统细节时，快速的进行系统迭代，往往不仅不会让开发的速度加快，还会严重降低统开发的效率。