设计模式：如何重构代码

一、重构

1、重构定义

在保持功能不变的前提下，利用设计思想，原则，模式，编程规范等理论来优化代码，修改设计上的不足，提高代码质量。

2、重构原因

对项目而言，重构可以保持代码质量持续处于一个可控状态，不至于腐化到无可救药的地步。（防止破窗效应）

对个人而言，重构锻炼一个人的代码能力，有成就感的事，是学习经典设计思想，原则，模式，编程规范等理论知识的练兵场。

3、重构规模

规模角度：大规模高层次的重构；小规模低层次的重构

大规模高层次重构：代码分层，模块化，解耦，梳理类之间的交互关系，抽象复用组件等。

这部分工作利用的更多是比较抽象，比较顶层的设计思想，原则，模式。

小规模低层次的重构：规范命名，注释，修正函数参数过多，消除超大类，提取重复代码等编程细节问题，主要是针对类，函数级别的重构。

这部分工作更多利用编码规范这一理论知识。

4、重构时间

我们一定要建立持续重构意识，把重构作为开发必不可少的部分，融入到日常开发中，而不是等到代码出现很大问题的时候，再大刀阔斧地重构。

5、重构方法

大规模高层次的重构难度比较大，需要组织，有计划地进行，分阶段地小步快跑，时刻让让代码处于一个可运行的状态。

小规模底层次的重构，因为影响范围小，改动耗时短，所以，只要你愿意并且有时间，随时随地都可以去做。

二、单元测试—保证重构不出错的可落地技术手段

1、单元测试定义

单元测试：代码层面的测试，研发自己写，测试代码逻辑正确性，测试的是类或者函数。

集成测试：某个功能模块或者整个系统测试，测试执行。

2、单元测试原因

这是代码code review 和重构的过程，有效发现代码中的bug和代码设计上的问题，是对集成测试的补充，帮助快速熟悉代码，是TDD可落地执行的改进方案

3、单元测试方法

写单元测试就是针对代码设计各种测试用例，以覆盖各种输入，异常，边界情况，并将其翻译成代码。可利用测试框架简化单元测试的编写。

（1）编写单元测试尽管繁琐，但并不是太耗时
（2）可稍微放低对单元测试代码的要求
（3）覆盖率作为衡量单元测试质量的唯一标准是不合理的
（4）单元测试不要依赖被测代码的具体实现逻辑
（5）单元测试框架无法测试，多半是因为代码的可测试性不好

4、单元测试难落地原因

（1）写单元测试本身比较繁琐，技术挑战不大，很多程序员不愿意去写

（2）国内开发偏“快，糙，猛”，容易因为开发进度紧，导致单元测试执行虎头蛇尾

（3）团队没有建立对单元测试正确的认识，觉得可有可无，单靠督促很难执行得很好