关于重构，也许路还长

博客转移到个人站点：http://www.wangchengmeng.club/2018/02/01/%E5%85%B3%E4%BA%8E%E9%87%8D%E6%9E%84%EF%BC%8C%E4%B9%9F%E8%AE%B8%E8%B7%AF%E8%BF%98%E9%95%BF/

欢迎来吐槽

如果你接手过中大型项目，做个很多个迭代，关于重构，你值得拥有。要跟上产品的节奏，迭代的步伐，重构是很有必要的。越到后面随着代码的堆积，项目越发难以维护，不重构，不仅维护困难，后期迭代也是事倍功半，而且代码极其难看。代码的抽取，利用泛型代码的向上提取，以及工具的封装都会是你在这个路上需要去掌握的，这也会提高你架构能力。

什么情况下需要重构

1, 结构错乱

~代码无法分出层次, 无法分清业务线.
~各个业务模块间/层次间的代码互相夹杂.
~由于多人协作导致的多种架构(MVP/MVVM/MVC等)并存.
~规范性问题, 导致各个模块内的代码形式互相不一致, 风格迥异.

2, 可读性差

~超长函数, 超大类
~代码的格式不规范或不一致.
~冗余代码, 无用代码, 重复代码.
~过于高明, 使用一些不常用的小技巧而且没有相关注释.
~滥用继承, 接口实现等, 导致难以跟踪.

3, 不能很好的适应产品的发展

~维护困难, 前一发动全身.
~不具备扩展灵活性, 无法很快引入系统版本更新时新特性.
~不具备可变更性, 产品添加新功能或修改需求时需要修改大量的代码.

重构的目标

重构的目的就是要提高代码质量, 而高质量的代码指标个人认为有如下几点：

1, 可读性

~规范一致性.
~结构, 层次明了.
~命名有含义, 注释要清晰.
~逻辑简短, 没有长篇大幅的代码块.
~方法提取, 类继承关系合理.
~不滥用设计模式.

2, 可维护性

~杜绝魔鬼数字/字符串/尺寸值/颜色值等
~代码复用, 以便维护.
~不写死, 预测可能的变化(但不要提前设计).

3, 可扩展性

~良好的分层结构, MVx模式运用.
~通过一些设计模式的使用来提高可扩展性.

如何重构

推荐一本书<<重构 — 改善既有代码的设计>>

1, 架构选择, 结构调整

~根据App的业务场景(展示型, 交互型, 后台工具型…)选择合适的架构.
并不是说一定要选用一个架构, 比如说后台工具型的App, 可能界面不多, 也服务器的交互也少, 基本是由Service组成, 可能直接用Android原生的结构就可以.
~界面较多, 且与服务器交互较多的建议选用MVP架构. 可以通过P来做数据处理, 将数据源M与展示层V解耦, 便于替换数据源或是改变UI.
~根据选用的架构以及业务模块分包

2, 技术/开源库选定

~ListView/RecyclerView的选择, Fragment/Activity的选择等.
~根据业务特点和选择的架构, 选用相关技术/开源库支持或对当前使用的进行整理.
~例如HTTP请求库, 缓存库, 图片加载库等等.

3, 确定规范

~制定编码规范, 可以根据Google推荐的Java编码规范, 适当定制.
~制定代码提交规范, git flow管理流程规范等.

4, 自底而上, 由小至大

~从底部开始, 也就是常说的Model层,数据层开始, 因为这部分相对独立, 可以通过提供接口与UI层隔离.
~不要一下就大面积重构, 需要逐个小的case进行重构验证, 保证当前运行.

5, 持续重构, 伴随测试

~持续进行小的重构, 每次重构需要伴随测试, 保证重构结果.

提取方法, 去除重复代码.
结构调整.
融入面向对象/接口编程思想, 注意SOLID原则.
多用组合, 少用继承

~最好有单元测试支持.

6, 重构而非重写

~不到万不得已不要想重写.
~重写会产生各种意想不到的问题, 诸如设计过度, 对于当前代码把握不够(例如现在看起来很不友好的代码可能就是为了解决一个架构无法解决的问题等).