重构——程序猿的艺术
Posted chengweijun
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了重构——程序猿的艺术相关的知识,希望对你有一定的参考价值。
何为重构
重构:在不改变软件对外表现和行为的前提下修改已有代码使其易于理解,便于扩展
重构就是让代码易于程序猿理解。在重构的世界里代码是写给程序猿看的而非写给机器看,我们会忽视性能而专注于让代码对程序猿更友好(先让代码跑通,再去重构,最后才考虑性能优化)
为什么要重构
- 在添加功能前重构,可以时原有的代码更易扩展,简化功能添加难度
- 在改bug前重构,可以优化代码的结构,使逻辑更加清晰,更容易找出bug
- 在评审代码时(无论是自己的还是别人的代码都行)进行重构,可以加深对代码逻辑的理解
重复一遍:
重构时机 | 好处 |
---|---|
添加功能前 | 更易扩展 |
改bug前 | 更易找出bug |
评审代码时 | 加深理解 |
怎么重构
看图:
第一步 建立测试框架
测试框架是判断重构成功与否的关键,再重复一遍:
重构:在不改变软件对外表现和行为的前提下修改已有代码使其易于理解,便于扩展
重构不能改变代码对外的表现和行为,测试框架正是要测试重构是否改变了代码的对外接口,如果不能通过测试,必须对重构进行修复(回滚到重构之前)
第二步 寻找代码坏味
代码坏味(Bad Smell),出自《重构——改善既有代码的设计》的作者,作者认为代码的不合理设计就像婴儿的尿布散发出来的Bad Smell一样,当你闻到它的时候,就应该警惕:该给代码换尿布了
我们要重构代码,首先要找出需要重构的地方,作者总结了几种特殊“味道”的Bad Smell,我把它写在了【怎么重构】的下面(代码坏味)
第三步 代码重构
使用针对代码坏味的重构手段对其进行重构即可
第四步 测试
使用第一步建立的测试框架对重构进行测试
重构可不是写Bug
代码坏味
我只收录了《重构——改善既有代码的设计》中一部分常见的代码坏味,更多的请查看原书
我极力推荐给大家这本书:世界软件开发大师Martin Fowler的《重构——改善既有代码的设计》
坏味 | 表现 | 对应的重构手段 |
---|---|---|
重复代码块 | 相同代码重复出现 | 抽取方法 |
方法过长 | 方法体长度超过30行 | 抽取方法 |
方法参数过多 | 方法所需的参数超过3个 | 使用对象封装参数集 |
临时变量存在 | 代码中有临时变量 | 使用查询方法取代临时变量 |
switch语句存在 | 代码中有switch分支 | 使用多态取代switch分支 |
类过长 | 类的长度超过100行 | 转移成员变量和函数 抽取类 |
发散式变化 | 引发一个类修改的原因不只一个 | 抽取类 |
发散式修改 | 一个类修改,引发修改的其他类不止一个 | 抽取类 |
数据依赖&过度亲密 | 一个类过多调用另一个类的成员和函数(甚至超过了拥有成员和函数的类) | 转移成员变量和函数 |
重构手段
等我把这些文章全写完发了,再给你们提供链接
-
到处都是重复的代码?方法体又臭又长看不懂?快来试试抽取方法(Extract Method)吧,保证药到病除!
使用对象封装参数集
答应我,别再给方法弄一长溜的参数了,好吗?
使用查询方法取代临时变量
你这方法里怎么这么多临时变量?我完全记不住每个变量是用来干什么的!
使用多态取代switch分支
“来看看外包老哥写的超长switch语句”这种文章又登上首页了
及时打断if条件分支
外包老哥总是被黑的幕后黑手找到了!
转移成员变量和函数
道理我都懂,可是你一直在用的成员变量为什么要让我负责管理?
抽取类
总觉得,是时候new一个替身出来帮我干活了
将数据的处理函数转移给持有数据的类
或许,这个锅应该由你来背
向父类转移成员变量和函数
所有子类都需要做的事,为什么不让父类直接做了?
注意集合型成员变量的get/set方法!
有人动了我的集合对象,可是我却不知道!
技术不分领域,思想一脉相承
以上是关于重构——程序猿的艺术的主要内容,如果未能解决你的问题,请参考以下文章
Java程序猿的JavaScript学习笔记(9—— jQuery工具方法)
Java程序猿的JavaScript学习笔记(9—— jQuery工具方法)