重构优化的思考

重构这个如今coding最时髦的词，在各个coder之间广泛流传。重构俨然已经成为了经验丰富的代名词。最近有机会开始重构一些东西，在这里回顾一下以前的重构基础吧。

       重构的时机：什么时候重构？

重构绝非没事的时候改动下代码让代码更美观，这个意义真的不大，太浪费精力了。当发现以前书写的代码不满足目前的功能需求时，那么可以考虑重构；当以前的代码不满足目前的性能要求时，需要重构（甚至于重写，重写要慎重）；当可预见的未来里，可能会出现功能性能瓶颈时，需要重构。总而言之，没有明确的有价值的目的期望，那还是let it alone比较好。

重构的方式：怎样开始重构？

不是说拿到项目之后立马开始改写代码，按照自己的意愿完成代码的重构；在重构之前要有足够的分析工作，确定你要重构的代码能对你的目标起到正向促进作用，重构并不一定能保证你改善代码的性能（你需要确立一些优化点-----这些点可能能改进性能），然后去执行重构工作。切记，完全不需要改进所有的代码，真正决定关键性能的代码一般绝不会超过30%，分析好关键点之后进行优化重构工作往往能起到事半功倍的作用。

重构的结果：怎么样？

重构的结果未必会达到你的期望值，所以如果不行就改回原来状态，再去分析别的关键点，重构一定要通观全局，确立疑似点，而后再去重构改写，最糟糕的情况只能是重新设计了。

PS:重构可以让你读懂代码更容易；重构可以让代码效费比更高;重构能做很多很多，但重构也要求很多很多，要有足够的经验，要有足够的分析能力，要有足够的项目认知能力。在重构的路上，我还是彻头彻尾的大菜鸟，加油哈。