重构-改善既有代码的设计 总结
重构笔记
写这篇文章的目的:
最近读书总是一掠而过, 很少做笔记和总结.有些惭愧, 趁着最近空闲, 把曾经读过不错的技术书做一些适当的总结.
也算加深下自己的印象, 本文是对《重构 改善既有代码的设计》的一个总结, 并会添加一些前端的思考
定义
重构是在不改变软件可观察行为的前提下改善其内部结构
- 过度工程
- 如果他还可以运行, 就不要去动他
原则
What
对软件内部结构的一种调整, 目的是在不改变软件可观察行为的前提下, 提高其可理解性, 降低其修改成本
Why
重构不是”银弹”, 但他可以帮你始终良好的控制自己的代码, 他可以用于以下几个目的
- 重构改进软件设计
- 重构使软件(代码)更容易理解
- 重构帮助找到bug
- 重构提高编程速度
可能这点违背直觉, 但良好的设计师快速开发的根本
When
重构不需要特定拨出时间来做, 他应该是随时的
- 添加功能时
- fix bug 时
- code review 时
何时不该重构?
需要重写时(代码无法工作
项目期限受限
重构与设计
重构是与设计互补的
重构无法取代设计, 但可以减少预先设计的压力
代码的坏味道
- 重复代码
- 过长函数
- 过大的类
- 过长参数列
- 发散式变化
- 霰弹式修改
- 依恋情节
- 数据泥团
- 基本类型偏执
- switch 惊悚现身
- 平行继承体系
- 累赘类
- 夸夸其谈未来性
- 令人迷惑的暂时字段
- 过度耦合的消息链
- 中间人
- 狎昵关系
- 异曲同工的类
- 不完美的库类
- 纯稚的数据类
- 被拒绝的遗赠
- 过多的注释
构筑测试体系
重构首要的前提是拥有一个可靠的测试环境
重构列表
每个重构手法包含下面五个部分
- 名称 – 重构词汇表
- 概要
- 动机 – 何时需要重构 & 何时不该重构
- 做法
- 范例
- 重构的记录格式
重构手法
重新组织函数
- 提炼函数 Extract Method
函数的粒度越小, 复用的机会就更大 关于函数名: 长度不是问题, 关键在于函数名称和函数本体之间的语义距离, 用函数的意图来命名(do what not how to do) - 内联函数 Inline Method
let _numOfLateDeliveries;
let moreThanFiveLateDeliveries = () => _numOfLateDeliveries > 5;
let getRating = () => moreThanFiveLateDeliveries() ? 2 : 1;
// ↓
let getRating2 = _numOfLateDeliveries > 5 ? 2 : 1;
有时函数内部代码和函数名称同样清晰易读, 如此便可去除此函数, 直接使用内部代码
- 内联临时变量 Inline Temp
只被用一次的临时变量可以去掉(webstorm 自动有这个warning) - 以查询取代临时变量 Replace Temp width Query
没觉得这个重构方法哪里好, 可能书里的例子不佳 - 引入解释性变量 Introduce Explaining Variable
将复杂度的表达式(或一部分)放进一个临时变量, 以此变量名来解释表达式用途