关于重构的一些想法

引言：有时候重构是为了提高代码的执行效率。有时候重构是为了提高代码的可读性。有时候重构是为了少写代码。

方法

• 把功能相对独立的内容，拆分出来，变成一个函数。最好要功能灵活一点。不要功能太单一，也不要功能过于庞大。太单一，没必要拎出来。太庞大，就失去灵活性了。

好处：
1) 因为内容相对独立，可能别的地方也会用到，这样就可以减少代码的冗余。简单的说，就是避免代码过于重复。
2) 代码也更容易读，因为功能被封装起来了，剩下的就是大的逻辑，清晰易懂。
3） 方便修改，有时候需求变更要修改多个地方，这样只需要修改一个地方，就可以解决问题。

• 按照层级来整理，有些方法是全局的，就放到全局当中。有些方法是局部的，就放到局部当中。有些方法是内部的，就放到内部当中。

不能所有的方法都放到全局当中，那么全局就太臃肿。也不能所有的方法都放到内部当中，那么重复率就太高，每一个地方，都要重写一下方法，造成了大量的重复代码。

杂谈

• 方法重构，就需要有一定的面向对象思维，把一些行为抽象出来，命名为合理的方法名称。

• 类重构，把一些过于庞大的类，拆分成相对独立的小类。把一些过于小的类，合并到大类当中。视情况而定。

• 每次重构完成，最好进行一些单元测试，保证重构之后的正确性。

• 重构不仅仅存在于服务器端，也存在于前端，js函数一样有效果。这是一种思维，不针对语言。

• 好的习惯是，每次把功能实现之后，能够对自己写的代码进行优化，合并，拆分，重命名，优化逻辑等等。

这样就能够培养自己重构的习惯，以及重构的熟练性。

• 重构的目的是，提高代码的可读性，提高代码的安全性，提高代码的质量。

• 重构看似花费了时间，从长远角度来说，是节省时间。因为后期修改与维护会减少成本。

• 重构能够训练你的逻辑思维，把项目条理化。而不是一团乱麻。

• 架构师，就是让项目有一定的可管理性，站在高处去看待项目的人。项目的骨架都由架构师来构建。建设，调整（重构），再建设，再调整（重构）。使得项目不至于脱离轨道。稳步向前。

• MVC就是一个降低耦合度的过程，它将逻辑从数据库平台的特殊性中剥离出来。