重构

概念:

　　重构:在不改变软件可观察行为的前提下改善其内部结构.核心是直观,易修改.

　　会面临的问题:重构只是让代码更简洁,并没有添加新功能,这会造成重构很多情况下是个人工作态度的选择,领导,同事并发现不了它的价值.
　　Martin Fowler:写出人容易理解的代码才是优秀的程序员.

原则:

1. 一次只做一件事.重构时只替换代码,不在重构的同时解决代码错误.
2. 核心是简洁.效率不是第一考虑要素.

作用:
　　简洁,效率,严谨,可扩展

原因:

1. 代码堆积会造成理解困难
2. 代码重复变多,修改困难
3. 后续维护困难
4. 存在隐藏的bug
5. 简化会促进开发进度

重构具体可以分为3部分:

　　1 实体
　　　　问题:字段过多,数据类型的选择,实体间关联关系
　　　　解决:
　　　　　　字段过多:进行字段归类,抽取字段实体;
　　　　　　数据类型选择:使用包装类,数据类型要具体明确,如数组区分数据类型,多种类型混杂就要使用实体代替;
　　　　　　关联关系:单向关联,只有一方可获取对方,简单,可控制修改途径;双向关联,双方都可获取对方,获取方便;
　　2 类
　　　　问题:类的问题就是方法的归类不正确,方法调用复杂,对外暴露方法过多,引用类功能扩展等问题
　　　　解决:
　　　　　　方法归类:将对外部耦合的方法,整合到一个方法中,甚至可以提炼到一个类中,保证逻辑连贯,修改影响小;
　　　　　　方法调用复杂:主要也是方法归类,进行方法合并;
　　　　　　对外暴露方法过多:进行方法封装,让方法再去调用其他类的方法,减少修改难度;但是封装过多也会造成自己成为中间类,复杂度增加;
　　　　　　类扩展:可以通过声明为引用类的子类,包装类等方法;
　　　　引申:
　　　　　　类的重构往往会涉及类结构的调整,比如使用继承,实现,在业务逻辑上使用多态替换条件判断,增强可扩展性.这一部分按作者归类属于高级部分.
　　3 方法
　　　　问题:方法的主要是业务逻辑和参数,这里可能存在的问题就是:方法过长,方法过短,参数过长,变量不直观等
　　　　解决:
　　　　　　方法过长:抽取业务逻辑,按功能进行方法归类,这样可以减少注释,整合代码,提高代码复用;
　　　　　　方法过短:说明方法抽取有问题,可以直接使用方法逻辑,去除方法;
　　　　　　参数过长:减少临时参数,可以从实体中取值的传实体,不能的将参数进行封装成实体;
　　　　　　变量使用:减少临时变量,减少临时变量多次赋值的情况,可以将重复使用的条件表达式抽取为变量,让代码更容易理解;
　　　　　　减少临时变量,它会增加要传递参数,性能,赋值操作容易造成问题.

测试:
　　很重要.不管是重构还是正常开发,测试可以提高代码质量,减少未意料的错误.

重构与性能:
　　重构往往可能使性能变差,但是它可以让性能优化进行的更顺利.因为性能优化应该在项目阶段性完成时才进行的操作,往往并不是在开发中要主要关注的问题.

感触:

　　感觉重构核心就是方法重组,归类,让代码更直观,整洁.跟大龙也沟通了这件事,他说不是书不行,是目前自己的水平达不到,并且没有实际需求.

　　因为重构和设计模式一样本身也是一个比较抽象的概念.它要求的是一种开发理念,或者说是原则.这种专门花时间重构没有实际业务的推动很难达到理想的效果.

　　其实写这种总结是比较鸡肋的一种操作,就是将别人的饭,自己煮一下,但是不写又感觉没有收获感.聊以自慰吧!

参考资料:
　　Martin Fowler:重构 改善既有代码的设计