敏捷词汇表 -- 敏捷联盟
# 重构 Refactoring
## 定义
重构包括改善现有程序源代码的内部结构，同时保留其外部行为。
名词“重构”是指一种特定的行为保留转换，例如“提取方法”或“引入参数”。
## 常见陷阱
重构并不意味着：
- 重写代码
- 修正错误
- 改善软件的可观察方面，例如其界面
在缺乏防范措施来引入缺陷（即违反“行为保留”条件）的情况下进行重构是有风险的。保障措施包括帮助进行回归测试（包括自动单元测试或自动化验收测试），以及帮助进行形式推理（例如类型系统）。
## 预期收益
以下是重构带来的好处：
- 重构改善了代码的客观属性（长度，重复，耦合和内聚，循环复杂性），这些属性与维护的容易性相关
- 重构有助于代码理解
- 重构鼓励每个开发人员考虑和理解设计决策，尤其是在集体所有权/集体代码所有权的背景下
- 重构有利于可重用设计元素（例如设计模式）和代码模块的出现
## 使用迹象
- 版本控制记录（例如CVS或git日志）包括标记为“重构”的条目
- 可以验证与此类条目对应的代码修改是否与行为无关：例如，不引入新的单元测试或功能测试
## 技能水平
- 初学者
- 知道“重构”的定义
- 可以使用IDE中的一些自动重构
- 可以手动执行一些重构
- 意识到手动和自动重构带来的回归风险
- 知道代码重复，可以通过重构将其删除
- 中间
- 知道并能够补救更广泛的“代码异味”
- 意识到重构之间的依赖关系，可以链接多个重构以执行设计意图
- 持续进行重构，而不是偶尔进行冗长的会话
- 高级
- 具有敏锐的代码复制和耦合感
- 将重构应用于非代码元素，例如数据库架构，文档等。
- 使用重构指导大型代码体朝着从广泛的调色板中有意选择的设计风格：面向对象，功能化或受已知设计模式的启发
## 进一步阅读
- 《重构》，作者：马丁·福勒（Martin Fowler）
- 天皇方法
## 起源
- 1984年：Brodie的“ Thinking Forth”中描述了“重构”的概念，它是重构的一种预期，在其中以“将代码组织成有用的片段”的形式出现，“在详细的设计和实现过程中发生”。
- 1990年：Bill Opdyke与Ralph Johnson在ACM SIGPLAN论文中提出“重构”一词，“重构：帮助设计应用程序框架和发展面向对象的系统”
- 1992年：Opdyke的论文“重构面向对象的框架”中对“重构”进行了全面的描述。
- 1999年：Martin Fowler的同名书普及了“重构”的实践，这种实践早在几年前就被纳入了极限编程。
- 2001年：重构“跨越Rubicon ”，这是马丁·福勒（Martin Fowler）的一种表达方式，描述了Java语言在IDE中重构的自动化辅助工具的广泛可用性。
## 学术出版物
尽管重构的实践已变得很流行，但在学术环境中严格建立重构的益处已被证明是棘手的，这说明了研究与实践之间的共同鸿沟。
- 研究重构的影响：复杂性指标透视，一项2010年的研究，令人惊讶地发现，由版本控制日志确定的重构情节与降低循环复杂性之间的相关性很小
此类研究可能会受到方法论问题的影响，例如，在事后检查代码历史时，确定什么算作“重构”；例如，上述论文发现程序员经常标记“重构”代码更改集，其中还包括其他功能或错误修复。
点击看敏捷名词地铁线路全图