重构-改善既有代码设计读后灵光

1. 设计与重构
2. 为什么要重构
3. 函数
4. 抽象
5. 封装
6. 继承
7. 多态
8. 表达式与卫语句
9. 异常与断言
10. 委托与设计模式
11. 关系处理
12. 大型重构

---

　　今年四月份的时候接触的一个快要结束的项目，在甲方一直后续增加需求，项目迟迟得不到结项。并且对于后续需求的开发成本越来越高，代码越来越复杂，错误的排查也越来越艰难。而后九月入职新公司，碰到的是两年前开发的一个产品项目，当时的开发人员已经都离职的情况下，公司要对这个产品模块进行整合，分支驳杂，这是一个alert服务，对于公司现有的所有产品线都提供的一个公共服务，但是不同的产品AI，BI，MI，云压测等产品线的需求有略微的不同，当初的开发人员是针对这几个不同的产品都部署了一套单独的服务。现在要重新拾起告警这个玩意来，对于我来说，想起今年看过的这本Martin Fowler的书《重构-改善既有代码的设计》

1 设计与重构

设计和重构的关系是什么？

设计是一个项目不变的东西么？

没有优秀的设计，就是多优秀的设计，在针对当时的需求而做的设计，你可能根据你的经验做好了预防需求修改的架构设计和技术选型，而后在经历的漫长的时间检验之后，新的需求添加进来，验证过当初的架构设计之后，也有修改和完善的可能，而技术选型是一直在进步的，肯定有更能提高开发效率的技术出现。

设计决定了一个产品的起点高低，重构是为了后续对既有设计的完善，在这个起点上的更进一步。去优化代码的执行效率，应对新需求的开发，新功能的迭代。

2 为什么要重构

在四月份的项目中，我参与进去的时候，对于用户后续提的需求，都需要对代码中很多地方进行改动才能去满足客户的需求，并且对于项目组来说，并不知道客户后续是否还有新增加需求和需求改动的可能性。那么我们需要重构么？为什么要重构？ 

需要重构，无论是否后续是否还会提新的需求出来，既有的需求会不会进行修改，我们都需要将现有的功能点，代码结构，模块和服务进行重新的组织和归约。

重构并不是对既有的代码推倒重来，不是全盘否定，不是重新开发。而是在建立在单元测试完成的情况下，对于代码块，调用关系，继承结构，异常处理的进一步调整，使之重回正轨的一种手段。目的是为了继续的往前走。

书中也谈及对于重构的定义：重构是在不改变软件可观察行为的前提下改善其内部结构。

“许多人把设计看作软件开发的关键环节，而把编程看作只是机械式的低级劳动。他们认为设计就像画工程图而编码就像施工。但是你要知道，软件和机器有着很大的差异：软件的可塑性更强，而且完全是思想产品。”

而至于重构和设计的关系，我们可以归纳为这样一种，设计是一个尽可能让编码成功的前提，重构在进行中对这一前提不断的使其重回正轨的过程，不忘初心。

3 函数

　　（重复代码）、（过长函数）、（过长的参数列表）、（过长的消息链）、（夸夸其谈其未来性）、（过多的注释）、（魔法值）、（中间人）、（switch）等

　　我们需要的时候将函数拆分成若干个细小功能的小函数，去除临时变量，以查询等的方式去提炼函数。

4 抽象

　　参数列需要进行抽象，重复代码需要抽象，行为可以抽象成行为参数化，switch可以用多态和状态模式来取代，漫长的委托关系可以抽象成消息链进行组织，

9 异常与断言

　　对于一个取款行为，取款方法withdraw()的异常处理，取款之前应该进行对于余额的检验，如果检查余额是调用者的责任，那么余额不足就是一个编程错误，那么应该使用unchecked异常。如果检查余额是withdraw()的责任，必须要方法声明处声明这个异常，提醒调用者注意这个异常，进行处理，这是checked异常。

　　unchecked异常是可以避免的。

　　断言的处理，在需求的地方合理使用断言就可以了。往往是在类库和参数的校验中，不满足条件的情况下直接抛出异常。