软件配置管理
第1章 软件配置管理概念与目标
- 软件配置管理(Software Configuration Management, SCM)
(1) 定义（多个）：
l 软件配置管理是指一套管理软件开发和维护过程中所产生的各种中间软件产品的方法和规则，它是控制软件系统演变的学科。
l 软件配置管理是一组针对软件产品的追踪和控制活动，它贯穿于项目生命周期的始终，并代表着软件产品接受各项评审。
l 软件配置管理是贯穿于整个软件过程中的保护性活动，它被设计用来：(1) 标识变化；(2) 控制变化；(3) 保证变化被适当的发现；(4) 向其他可能有兴趣的人员报告变化。
(2) 目标：
l 软件配置管理的各项工作是有计划进行的。
l 被选择的项目产品得到识别，控制并且可以被相关人员获取。
l 已识别出的项目产品的更改得到控制。
l 使相关组别和个人及时了解软件基准的状态和内容。
(3) 目的：使错误降为最小并最有效地提高生产效率。
- 最终软件版本产品
最终软件版本产品是文档、程序和数据的集合，是软件生产商交付给客户的软件产品，是用户能够直接使用的软件产品。
- 软件配置
软件配置是一个软件产品在生存期各个阶段的不同形式（记录特定信息的不同媒体）和不同版本的程序、文档及相关数据的集合，或者说是配置项的集合。
- 软件配置项(Software Configuration Item，SCI)
l 软件配置是一个集合，该集合中的每一个元素称为该软件产品软件配置中的一个配置项。
l 软件配置项是软件配置管理的对象，一个软件配置项是项目中一个特定的、可文档化的工作产品集。
- 基线(Baseline)
(1) 概念
l 基线是指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。
l 基线是已经正式通过复审和批准的某规约和产品。
l 经过正式评审和审计，并被批准后的阶段性软件工作产品，称为软件配置管理中的一根基线。
(2) 分类
l 功能基线：
- 在系统分析和软件定义阶段结束时，经过正式评审和批准的系统设计规格说明中对被开发软件系统的规格说明；
- 经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对被开发软件系统的规格说明；
- 由下级申请及上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。
l 指派基线：又称为分配基线，指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明，指派基线是最初批准的指派配置标识。
l 产品基线：指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明，产品基线是最初批准的产品配置标识。
- 软件配置控制委员会(Software Configuration Control Board, SCCB，简称CCB)
l 负责管理软件配置项变更的组织。
l 具体责任如下：
- 评估变更；
- 批准变更请求；
- 在生命周期内规范变更申请流程；
- 对变更进行反馈；
- 与项目管理层沟通。
第2章 软件配置管理角色与过程
- 1. 软件配置管理角色及职责
(1) 项目经理(Project Manager，PM)
l 项目经理是整个软件研发活动的负责人，他根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。
l 其具体职责为以下几项：
- 制定和修改项目的组织结构和配置管理策略；
- 批准、发布配置管理计划；
- 决定项目起始基线和开发里程碑；
- 接受并审阅配置控制委员会的报告。
(2) 配置控制委员会(Configuration Control Board，CCB)
l 负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。
l 其具体职责为以下几项：
- 定制开发子系统；
- 定制访问控制；
- 制定常用策略；
- 建立、更改基线的设置，审核变更申请；
- 根据配置管理员的报告决定相应的对策。
(3) 配置管理员(Configuration Management Officer，CMO)
l 根据配置管理计划执行各项管理任务，定期向CCB提交报告并列席CCB的例会。
l 其具体职责包括以下几项：
- 软件配置管理工具的日常管理与维护；
- 提交配置管理计划；
- 各配置项的管理与维护；
- 执行版本控制和变更控制方案；
- 完成配置审计并提交报告；
- 对开发人员进行相关的培训；
- 识别软件开发过程中存在的问题并拟定解决方案。
(4) 系统集成员(System Integration Officer，SIO)
l 负责生成和管理项目的内部和外部发布版本。
l 其具体职责为以下几项：
- 集成修改；
- 构建系统；
- 完成对版本的日常维护；
- 建立外部发布版本。
(5) 开发人员(Developer，DEV)
l 根据组织内确定的软件配置管理计划和相关规定，按照软件配置管理工具的使用模型来完成开发任务。
- 软件配置管理基本流程
(1) 计划阶段
l CCB根据项目的开发计划确定各个里程碑和开发策略；
l CMO根据CCB的规划，制定详细的配置管理计划，交CCB审核；
l CCB审核配置管理计划后交项目经理批准，发布实施。
(2) 开发和维护阶段：
在这一阶段中，软件配置管理活动主要分为三个层面：
l 主要由CMO完成的管理和维护工作；
l 由SIO和DEV具体执行软件配置管理策略；
l 变更流程。
核心流程为：
l CCB设定研发活动的初始基线；
l CMO根据软件配置管理规划设立配置库和工作空间，为执行软件配置管理做好准备；
l 开发人员按照统一的软件配置管理策略，根据获得的授权的资源进行项目的研发工作；
l SIO按照项目的进度集成组内开发人员的工作成果，并构建系统，推进版本的演进；
l CCB根据项目的进展情况，审核各种变更请求，并适时的划定新的基线，保证开发和维护工作有序的进行。
- 3. 软件配置管理基本活动
(1) 制定配置管理计划
l 步骤：
- 参加项目规划
- 规划配置管理任务
- 形成配置管理计划
- 评审配置计划
l 配置管理计划主要内容：
- 配置管理组织及其职责
- 配置管理工具和配置库的组织结构
- 配置项标志和基线定义
- 变更管理流程
- 配置审核和配置状态统计
(2) 识别和标志配置项
步骤：
l 将软件项目中需要进行控制的工作产品定义为配置项（SCI）。
配置项分为：
- 基本配置项：软件开发者在项目开发过程中所创建的基本工作单元。
- 集成配置项：一个集成配置项是基本配置项或其它集成配置项的集合。
l 为每一个配置项分配唯一的标志。
注意：配置项标识并不是指程序/文档文件的文件名，而是该程序/文档作为一个配置项的标识。
l 建立配置项间的对应关系。
可使用某种模块互联语言(Module Interconnection language, MIL)来描述配置项之间的关系。
(3) 搭建配置管理环境
l 配置管理环境是用于进行软件配置管理的系统环境，其中最重要的是配置管理库，简称配置库。
l 配置库存储配置项 (SCI)、修改请求、变化记录等，并提供对库中所存储文件的版本控制。
l 为不同的开发人员分配不同的访问配置库的权限。
l 一般需采用配置管理工具来建立配置库。
l 配置库中文件的更改是受控的。
(4) 配置项的版本控制
l 当开发人员要使用配置库中的一个文件时，将文件检出到自己的工作目录里，此时该文件在配置库中被自动锁定，开发人员处理完该文件后，再将文件检入到配置库中（需有修改权限），一个新的版本号自动与文件相关联，文件解锁。
l 配置库的检入检出和版本控制机制解决了软件开发中的两个重要问题：
- 访问控制：保证具有相应权限的人员才能修改配置项。
- 并行控制：保证不同人员同时对某配置项进行的修改不会互相覆盖。
l 软件产品不同类型的版本的特性和所包含的配置项应被明确描述，保证可根据要求将配置项组合生成适用于不同应用环境的正确的软件产品版本。
(5) 基线变更管理
l 变更请求
l 变更评估
l 变更批准/拒绝
根据评估结果对变更作出决策：
- 直接实现变更
- 挂起或延迟变更
- 拒绝变更
- 对于批准的变更，要确定其实现进度
- 立即实现变更
- 特定的日期实现变更
- 在软件另外的版本中实现
l 变更实现
(6) 配置审核
l 配置管理活动审核：确保所有配置管理活动符合已批准的软件配置管理规程。
l 基线审核：审核基线配置项的完整性和一致性，从而保证基线配置项可被正确地构造。
- 配置库中是否包含了所有计划纳入的基线？
- 基线自身的内容是否完整？
- 编译所有的源代码，检查是否可产生最终软件产品。
- 检查需求、设计与代码间的一致性。
(7) 配置状态统计
l 配置管理系统的状态统计和评估
- 变更请求的数量。
- 变更管理活动的执行情况
- 配置管理系统存储量的变化。
- 配置管理系统在运作中发生异常的次数。
l 配置状态报告
- 每次配置的更改被批准或实现时，都会产生一个配置状态报告，通知相关人员：更改了哪些内容？由谁更改？什么时候更改？更改会产生哪些影响？
- 对于大型项目的开发，配置状态报告非常重要，它促进了人员之间的通信。
- 版本的编号
(1) 数字顺序型版本编号
l 普通版本编号
- 产品的版本号由若干数字组成，数字之间用“.”分隔。一种典型的编号策略如下：
x.y.z，x为主版本号，y为特征版本号，z为缺陷修复版本号，如V3.10.16。
² 主版本号的增加表示提供给客户的主要产品功能的增强。
² 特征版本号的增加表示产品新增了一些特征或做了一些重要修改。
² 缺陷修复版本号的增加表示在软件产品上做了一些缺陷修复工作。
- 文档编号的具体形式为英文（或中文）名加上该配置项所在的版本号，例如，详细说明书是一个配置项，它的某一个版本标识为“详细设计说明书V1.0.1”。
l α和β版本编号
- 在普通版本编号后面增加一个大写字符A或者B来分别表示α版本或β版本。例如1.2.4A或1.2.4B。
- 如果存在多次的α发布和β发布，可在A或B后面添加一个数字来说明发布的次数，例如：1.2.5A1，1.3.0B2。
² α测试是由公司内部的用户在模拟实际操作环境下进行的测试。
² β测试是由软件的多个用户在实际使用环境下进行的测试。
(2) 属性版本编号
l 把版本的重要属性反映在标识中。可以包括的属性有：客户名、开发语言、开发状态、硬件平台、生成日期等。例如：J2SDK.v.l.2.2:10/31/2000-18:00,native threads, jit-122(Jit(Just in Time)：Java即时编译技术)
l 包含的信息丰富，方便了查询和管理，版本间的关系易于保持，但由于太复杂，一般只用于软件组织内部的管理。
第3章 软件配置管理核心功能
- 软件配置管理与CMM/CMMI
(1) 软件配置管理是CMM/CMMI二级的一个重要KPA。
(2) CMM/CMMI将软件配置管理的活动分为6个方面
l SCM过程管理
l 软件配置标识
l 软件配置控制
l 软件配置状态统计
l 软件配置审计
l 软件发布管理和交付
(3) 在CMM和CMMI中，将配置管理的目的定义为“建立和维护产品的完整性”。
(4) 配置完整性
l 产品完整性：项目提交的工作成果是“产品集合完整、子产品正确”的
l 产品集合完整：产品包含的子产品（配置项）是完整的
l 子产品正确：子产品（配置项）达到了需求要求，满足标准、规程的要求
(5) 三库管理：三库的概念源自CMM/CMMI，即开发库、受控库和产品库。配置项在三库之间迁移，一级比一级的控制更严格。
l 开发库：存放开发过程中需要保留的各种信息，供开发人员专用。
l 受控库：在软件开发的某个阶段工作结束时，将工作产品存入或将有关的信息存入。
l 产品库：在开发的软件产品完成系统测试之后，作为最终产品存入库内，等待交付用户或现场安装。
- 按照三库的思路，软件开发组日常的工作在开发库中开展，当工作达到里程碑时，再迁移到受控库，在受控库中经过更严格的测试后，再上升到产品库，最后发布。
- 在实践中，三库常常被实现为物理上的三库，而不是通过逻辑的方式来实现，三库物理隔离带来的最大问题是配置项失去了历史可追溯性。
- 实现三库的指导思想应该是逻辑上独立，物理上在一起，通过权限与流程的控制来实现配置项在不同库之间的流转，以及相应角色的人员对相应库的访问。
- 不管是几个库，最终都是要提高管理效率和保存工作成果和工作记录。
- 软件配置管理核心功能
(1) 基线管理：每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线，这就是“基线管理”的过程。
l 基线具有以下属性：
- 通过正式的评审过程建立
- 基线存在于基线库中，对基线的变更接受更高权限的控制
- 基线是进一步开发和修改的基准和出发点
- 进入基线前，不对变化进行管理或者较少管理
- 进入基线后，对变化进行有效管理，而且这个基线作为后继续工作的基础
- 不会变化的东西不要纳入基线
- 变化对其他没有影响的可以不纳入基线
l 建立基线的好处：
- 重现性：及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
- 可追踪性：建立项目工件之间的前后继承关系。目的是确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。
- 版本隔离：基线为开发工件提供了一个定点和快照，新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
l 基线、配置、配置项的关系：
l 基线管理的步骤：
- 在开发前确定基线的“配置”
- 基线批准前，根据“配置”检查配置项是否齐备
- 对各个配置项，确认其版本的正确性
- 对每个配置项建立基线标志
- 基线变更管理
- 基线的各类报告和审计信息
(2) 变更管理：在有效标识了配置项并进行了管理之后，如何保证它们在复杂多变的开发过程中真正处于受控的状态，并在任何情况下都能迅速的恢复到任一历史状态就要依赖变更管理。
l 缺乏有效的变更请求管理会导致的问题：
- 软件产品质量低下，对一些缺陷的修正被遗漏
- 项目经理不了解开发人员的工作进展，缺乏对项目现状进行客观评估的能力
- 开发人员不了解手头工作的优先级别，可能出现将紧急的事情放在一边、而工作在一般优先级任务上的情况
- 可能错误使用和引用已经变更的产品，引起开发工作混乱
l 变更管理的流程：
- （获得）提出变更请求；
- 由CCB审核并决定是否批准；
- 为（被接受）修改请求分配人员，提取SCI，进行修改；
- 提交修改后的SCI，并测试（或者评审）；
- 重建软件的适当版本；
- 复审（审计）所有SCI的变化；
- 发布新版本。
l 为了更好的指导变更范围的影响分析，可以通过两种表格来帮助发现受到变更影响的内容，一种是《需求跟踪表》，一种是《配置项依赖关系表》：
(3) 配置库管理
l 设置版本分支：为每个配置项从建立开始就划分成3个不同的分支：私有分支、集成分支、公共（主干）分支，让它们分别对应3类工作空间：
- 私有分支对应的是开发人员的私有开发空间。除该开发人员外，其他人员均无权操作该私有空间中的元素。
- 集成分支对应的是开发团队的公共空间。凡是要为同组人员共享的配置项都从该分支获得。该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限。该分支的管理工作由系统集成员及相关指定人员负责。
- 公共分支对应的是整个软件开发组织的公共空间。该分支对组织内的全体软件人员开放只读权限。该分支的管理工作由系统集成员负责。
l 配置库的设置：决定配置库的结构是配置管理活动的重要基础，一般常用的是两种组织形式：按配置项类型分类建库和按任务建库。
l 配置库的日常工作：配置库的日常工作是一些事务性的工作，主要保证配置库的安全性，包括：
- 对配置库的定期备份
- 清除无用的文件和版本
- 检测并改进配置库的性能等
(4) 配置审计：配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。
l 配置审计有两种:
- PCA (Physics Configuration Audit)：即物理审计，主要是检查版本是否正确一致，一般由非配置管理人员来进行。
² 配置项是否齐备
² 版本是否齐全
- FCA (Function Configuration Audit)：即功能审计，主要是检查配置项是否完整，各种过程文档是否齐备、正确、与需求是否一致，归结为两点，即完全和齐备，由CMO来进行。
l 配置审计步骤：
- 由项目经理决定何时进行配置审计工作
- 质量保证组或项目组的配置管理组制定该项目的配置审计人员
- 项目经理和配置审计员决定审计范围
- 配置审计员准备配置审计检查单
- 配置审计员安排时间审计文档和记录，审计活动可能涉及到：项目范围，配置项的入库(check in)及出库(check out)，评审记录，配置项的变更历史，测试记录，文件的命名，变更请求和版本的编号等。
- 配置审计员在审计中发现不一致现象，并作记录
- 由项目经理负责消除不一致现象
- 配置审计员验证所有发现的不一致现象确已得到解决
(5) 配置状态报告：根据配置项操作的记录来向管理者报告软件开发活动的进展情况。
l 应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。
l 为了说明项目状态对变更的情况也应当进行报告。
l 有时，对配置库的情况也进行说明，例如备份次数，磁盘占用空间等等。只要是关心的信息，均可作为状态报告的内容。这些信息进行有效记录，往往可以作为项目度量的重要数据来源。
第4章 软件配置管理规范与相关文档
- 软件配置管理计划
主要内容：
l 人员及职责
l 配置管理软硬件资源
l 配置项计划
l 基线计划
l 配置库备份计划
- 配置库管理报告
主要内容：
l 基本信息
l 项目成员的操作权限
l 配置项记录
l 基线记录
l 配置库备份记录
l 配置项交付记录
l 配置库重要操作日志
- 配置项变更控制报告
主要内容：
l 变更申请
l 审批变更申请
l 变更配置项
l 结束变更
- 配置状态报告
主要内容：
l 各份变更请示概要：变更请求号、日期、申请人、状态、估计工作量、实际工作量、发行版本、变更结束日期
l 基线库状态：库标识、至某日预计库内配置项数、实际配置项数
l 发行信息：发行版本、计划发行时间、实际发行日期、说明
l 备份信息：备份日期、介质、备份存放位置
l 配置管理工具状态
l 配置管理培训状态
- 配置审计报告
主要内容：
l 配置项状态统计
l 基线库基线统计
l 变更统计
l 审计中发现的主要问题
第5章 软件配置管理工具(5-8章)
- Microsoft Visual SourceSafe(VSS)
(1) 特点
l 提供了完善的版本和配置管理功能，以及安全保护和跟踪检查功能
l 与 Visual Basic、Visual C++、Visual FoxPro 等开发环境以及 Microsoft Office 应用程序集成在一起
l 工作原理简单
(2) 优点
l 能够与Visual Studio实现无缝集成，使用简单
l 提供了历史版本记录、变更控制、文件比较、日志等基本功能
(3) 缺点
l 只支持Windows平台
l 速度慢、伸缩性差
l 老版本(VSS6.0及以前)不支持并行开发，只支持Check Out – Modify – Check In的管理方式，一个时间只允许一个人修改代码
l 老版本(VSS6.0及以前)不支持异地开发
- Concurrent Versions System(CVS)
(1) 特点
l CVS采用客户机/服务器体系结构，代码、文档的各种版本都存储在服务器端，开发者首先从服务器上获得一份复制到本机，然后在此基础上进行开发。
l 基于“拷贝—修改—合并”的并发控制
- 客户端check out后，有文件的一份独立拷贝。
- 开发者在自己的工作目录中修改文件。
- 若有版本冲突，则使用合并（merge）功能与其他开发者的修改合并，然后提交（check in）。
l 记录不同版本之间的差别
(2) 优点(与VSS相比)
l SourceSafe有的功能CVS全都有，CVS支持并发的版本管理，SourceSafe没有并发功能。CVS服务器的功能和性能都比SourceSafe高出一筹。
l CVS服务器是用Java编写的，可以在任何操作系统和网络环境下运行。CVS深受Unix和Linux 的用户喜爱。Borland公司的JBuilder提供了CVS的插件，Java程序员可以在JBuilder集成环境中使用CVS进行版本控制。
l CVS服务器有自己专用的数据库，文件存储并不采用SourceSafe的“共享目录”方式，所以不受限于局域网，信息安全性很好。
(3) 缺点(与VSS相比)
l 客户端软件，五花八门、良莠不齐。Unix和Linux 的软件高手可以直接使用CVS命令行程序，而Windows用户通常使用WinCVS。安装和使用WinCVS显然比SourceSafe麻烦不少，这是比较令人遗憾的。
- Subversion(SVN)
(1) 特点(和CVS比较)
l 和CVS的相似性
l 目录的版本化
l 更加好的文件版本管理（例如对文件拷贝，重命名的处理）
l 提交的原子性
l 元数据的版本化
l 可选的网络层
l 对文本文件和二进制文件一致的差异比较算法
l 高效的分支（branch）和标签（tag）操作
l 良好的可维护性
(2) 常用的SVN命令
| 命令名称 |
功能 |
| svnadmin create |
创建一个新的空的版本库。 |
| svn add |
添加文件、目录或符号链。 |
| svn checkout |
从版本库取出一个工作副本。 |
| svn commit |
将修改从工作副本发送到版本库。 |
| svn copy |
拷贝工作副本或版本库中的文件或目录。 |
| svn delete |
从工作副本或版本库中删除一个项。 |
| svn diff |
显示两个版本或两个路径的区别。 |
| svn import |
将未纳入版本控制的文件或目录树提交到版本库。 |
| svn info |
显示本地或远程条目的信息。 |
| svn list |
列出版本库中的目录内容。 |
| svn lock |
锁定版本库中的路径，使得其他用户不能向其提交修改。 |
| svn log |
显示提交日志信息。 |
| svn merge |
合并两个版本中的内容。 |
| svn mkdir |
创建纳入版本控制的新目录。 |
| svn move |
移动一个文件或目录。 |
| svn resolved |
删除工作副本中目录或文件的“冲突”状态。 |
| svn revert |
撤销所有的本地修改。 |
| svn status |
打印工作副本中文件和目录的状态。 |
| svn switch |
更新工作副本至同一版本库中另一个URL。 |
| svn unlock |
解除工作副本或URL的锁定。 |
| svn update |
更新你的工作副本。 |
- 版本控制的数据共享模型
l Lock-Modify-Unlock Model（加锁-修改-解锁）
存在问题：
- 可能导致管理问题，如长期锁定文件不放
- 会导致不必要的按顺序开发
- 可能导致死锁
l Copy-Modify-Merge Model（拷贝-修改-合并）
存在问题：
- 冲突的产生：
冲突是随着拷贝-修改-合并方案的产生而带来的问题。两个开发者使用拷贝-修改-合并方案编辑同一个文件，并且两人的修改发生了交叠时就发生了冲突
- 冲突的解决：
当冲突发生时，开发者会看到一对冲突的修改结果，通常情况下，必须让引起冲突的两个人商议之后，手动选择保留一组更改。在这里，版本控制系统只能提示冲突的发生而无法给出解决建议
- 冲突的预防：
增加开发者的交流可以最大限度减少冲突的发生，但是不可能杜绝冲突
l 两种方案比较与选择
- 文本文件（例如源代码以及用纯文本，HTML，TXT等格式保存的文档）：因为其内部结构直观可知，容易理解上下文，所以用拷贝-合并方案较好。
- 二进制文件（例如Microsoft Word格式，PDF等格式保存的文档及图片，声音，可执行文件，库等）：内部结构复杂，且不容易理解更改处的上下文，采用锁定-解锁方案较好。
代码味道与重构
- 重构
(1) 重构概念
重构是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使程序的设计和架构更趋合理，进而提高软件的扩展性和维护性。
(2) 重构意义
l 重构改进软件设计(Refactoring Improves the Design of Software)
l 重构使软件更容易理解 (Refactoring Makes Software Easier to Understand)
l 重构帮助找到缺陷 (Refactoring Helps You Find Bugs)
l 重构提高编程速度 (Refactoring Helps You Program Faster)
(3) 重构时机
l 添加功能时重构 (Refactor When You Add Function)
l 修补错误时重构 (Refactor When You Need to Fix a Bug)
l 复审代码时重构(Refactor As You Do a Code Review)
- 代码味道简介：指程序中存在的一些不良的编程或设计方案。
(1) 类内味道
l Measured Smells（可度量的味道）
- Long Method（过长函数）
- Large Class（过大类）
- Long Parameter List（过长参数列）
- Comments（过多的注释）
l Unneccessary Complexity（不必要的复杂性）
- Speculative Generality（夸夸其谈的未来性）
l Duplication（重复）
- Duplicated Code（重复代码）
- Alternative Classes with Different Interfaces（异曲同工的类）
l Conditional Logic（条件逻辑）
- Switch Statements（Switch惊悚现身）
(2) 类间味道
l Data（数据）
- Primitive Obsession（基本类型偏执）
- Data Class（纯稚的数据类）
- Data Clumps（数据泥团）
- Temporary Field（令人迷惑的暂时值域）
l Inheritance（继承）
- Refused Bequest（被拒绝的遗赠）
- Inappropriate Intimacy（狎昵关系）
- Lazy Class（冗赘类）
l Responsibility（职责）
- Feature Envy（依恋情节）
- Message Chains（过度耦合的消息链）
- Middle Man（中间转手人）
l Accommodating Change（协调变化）
- Divergent Change（发散式变化）
- Shotgun Surgery（霰弹式修改）
- Parallel Inheritance Hierarchies（平行继承体系）
l Library Classes（库类）
- Incomplete Library Class（不完善的程序库类）
- 代码味道详解
(1) Long Method（过长函数）
l 描述：A method is too long.（方法太长。）
l 重构手段：
- 把函数变小：Extract Method（提炼函数）
- 函数内有大量的参数和临时变量：Replace Temp with Query（以查询取代临时变量）
- 参数太多：Introduce Parameter Object（引入参数对象）、Preserve Whole Object（保持对象完整）
- 太多临时变量和注释：Replace Method with Method Object（以函数对象取代函数）
- 条件表达式和循环：Decompose Conditional（分解条件表达式）
(2) Large Class（过大类）
l 描述：A class is trying to do too much, it often shows up as too many instance variables.（一个类试图做太多的事情，通常会出现太多的实例变量。）
l 重构手段：
- 太多实例变量或太多代码：Extract Class（提炼类）、Extract Subclass（提炼子类）
- 确定客户端如何使用：Extract Interface（提炼接口）
- 把数据和行为移到一个独立的领域对象，但需要保留一些重复数据：Duplicate Observed Data（复制“被监视数据”）
(3) Long Parameter List（过长参数列）
l 描述：A method needs passing too many parameters.（一个方法需要传递太多的参数。）
l 重构手段：
- 向已有对象发出一条请求就可以取代一个参数：Replace Parameter with Method（以函数取代参数）
- 参数缺乏合理的对象归属：Introduce Parameter Object（引入参数对象）
- 将来自同一个对象的一堆参数收集起来：Preserve Whole Object（保持对象完整）
(4) Comments（过多的注释）
l 描述：Do not write comments when it is unnecessary. When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.（在非必要的情况下不要写注释。当你觉得需要去写一段注释时，你首先应该尝试去重构代码，这将使任何注释都变得是多余的。）
l 重构手段：
- 需要注释来解释一块代码做了什么：Extract Method（提炼函数）
- 函数已经提炼出来，但还是需要注释来解释其行为：Rename Method（函数改名）
- 需要注释来说明某些系统的需求规格：Introduce Assertion（引入断言）
(5) Speculative Generality（夸夸其谈的未来性）
l 描述：If a machinery was being used, it would be worth it. But if it is not, it is not. The machinery just gets in the way, so get rid of it.（如果一个装置【一个设计或实现方案】会被用到，那就值得去做；如果用不到，就不值得。用不到的装置会成为拦路石，因此需要将它搬移。）
l 重构手段：
- 某个抽象类没有太大作用：Collapse Hierarchy（折叠继承体系）
- 不必要的委托：Inline Class（将类内联化）
- 函数的某些参数未被使用：Remove Parameter（移除参数）
- 函数名称带有多余的抽象涵义：Rename Method（函数改名）
- 对于无用的函数：Inline Method（内联函数）、Remove Method（移除函数）
(6) Duplicated Code（重复代码）
l 描述：Same code structure happens in more than one place.（在一个以上的地方发现相似的代码结构。）
l 类型：
- 类型一：除空格、布局和注释不同之外，其余部分都相同的代码片段——采用字符串匹配检测
- 类型二：除标识符、字面量、类型、空格、布局和注释外，语法结构相同的代码片段——采用标准化检测
- 类型三：除标识符、字面量、类型、空格、布局和注释外，进一步对重复代码段进行改动，例如修改、增加或者删除语句——采用区域匹配检测
- 类型四：两个或多个代码片段执行相同的计算（功能），但是语法结构的实现方式不同
l 重构手段：
- 同一个类的一个/两个方法含有相同的代码： Extract Method（提炼函数）
- 两个互为兄弟的子类含有相同的代码：Extract Method（提炼函数）、Pull Up Method（函数上移）、Form Template Method（塑造模板函数）
- 两个毫不相关的类含有相同的代码 ：Extract Class（提炼类）
(7) Alternative Classes with Different Interfaces（异曲同工的类）
l 描述：Classes are doing similar things but with different signatures. （不同的类做相同的事情，却拥有不同的签名，主要是指方法签名不同。）
l 重构手段：
- 两个函数做同一件事，却有着不同的签名：Rename Method（函数改名）
- 将某些行为移入类，直到两者的协议一致为止：Move Method（搬移函数）
- 必须重复而冗赘地移入代码才能实现上述重构：Extract Superclass（提炼超类）
(8) Switch Statements（Switch惊悚现身）
l 描述：Switch statements often lead to duplication. Most times you see a switch statement which you should consider as polymorphism.（Switch语句通常会导致代码重复。大多数时候，一看到Switch语句你应该考虑使用多态来替换。）
l 重构手段：
- 与类型码相关的函数或类：Extract Method（提炼函数）、Move Method（搬移函数）、Replace Conditional with Polymorphism（以多态取代条件表达式）、Replace Type Code with Subclass（以子类取代类型码）、Replace Type Code with State/Strategy（以State/Strategy取代类型码）
- 只在单一函数中有一些选择事件，且不想改动它们：Replace Parameter with Explicit Methods（以明确函数取代参数）
- 选择条件之一是null：Introduce Null Object（引入Null对象）
(9) Primitive Obsession（基本类型偏执）
l 描述：Primitive types are overused in software. Small classes should be used in place of primitive types in some situations.（在软件中，基本类型被过度使用。在某些场合下，应该使用一些小的类来代替这些基本类型。）
l 重构手段：
- 将原本单独存在的数据值替换成对象：Replace Data Value with Object（以对象取代数据值）
- 如果想要替换的数据值是类型码，而它并不影响行为：Replace Type Code with Class（以类取代类型码）
- 如果有与类型码相关的条件表达式： Replace Type Code with Subclass（以子类取代类型码）、 Replace Type Code with State/Strategy（以State/Strategy取代类型码）
- 如果有一组应该总是被放在一起的字段： Extract Class（提炼函数）
- 如果在参数列中看到基本类型的数据： Introduce Parameter Object（引入参数对象）
- 发现自己正从数组中挑选数据： Replace Array with Object（以对象取代数组）
(10) Data Class（纯稚的数据类）
l 描述：These are classes that have fields, getting and setting methods for the fields, and nothing else. Such classes are dumb data holders and are almost certainly being manipulated in far too much detail by other classes.（这些类拥有一些字段【成员变量】，并提供了对应的Getter和Setter方法，除此以外一无所有。这些类只是一些不会说话的数据容器， 而且它们必定会被其他类过分琐细地操作。）
l 重构手段：
- 对于public字段： Encapsulate Field（封装字段）
- 如果一个类内含容器类的字段，如果没有得到恰当的封装： Encapsulate Collection（封装集合）
- 对于那些不该被其他类修改的字段：Remove Setting Method（移除设值函数）
- 找出Getter/Setter函数被其他类运用的地点：Move Method（搬移函数）
- 如果无法搬移整个函数：Extract Method（提炼函数）
- 将Getter/Setter函数隐藏起来：Hide Method（隐藏函数）
(11) Data Clumps（数据泥团）
l 描述：Some data items together in lots of places: fields in a couple of classes, parameters in many method signatures.（一些数据项同时出现在多个地方，例如一对类中的值域【成员变量】，多个方法签名中的参数等。）
l 重构手段：
- 两个类中有相同的字段、许多函数签名中的参数相同：Extract Class（提炼类）
- 缩短参数列表、简化函数调用：Introduce Parameter Object（引入参数对象）、Preserve Whole Object（保持对象完整）
(12) Temporary Field（令人迷惑的暂时值域）
l 描述：Sometimes you see an object in which an instance variable is set only in certain circumstances. Such code is difficult to understand, because you expect an object to need all of its variables.（有时候你会看到一个对象的实例变量仅为某些特定的场合而设。这样的代码将导致难以理解，因为你期望一个对象需要它所有的变量。）
l 重构手段：
- 一个对象中某个实例变量仅为某种特定情况而定：Move Field（搬移字段）
- 在“变量不合法”的情况下创建一个Null对象，从而避免写出条件式代码：Introduce Null Object（引入Null对象）
(13) Refused Bequest（被拒绝的遗赠）
l 描述：Subclasses get to inherit the methods and data of their parents, but they just use a few of them.（子类继承父类的方法和数据，但是它们只需要使用其中的一部分。）
l 重构手段：
- 子类不想或不需要继承超类（先为子类新建一个兄弟类）：Extract Subclass（提炼子类）、Push Down Method（函数下移）、Push Down Field（字段下移）
- 子类复用了超类的行为（实现），却又不愿意支持超类的接口，拒绝继承超类的实现：Replace Inheritance with Delegation（以委托取代继承）
(14) Inappropriate Intimacy（狎昵关系）
l 描述：Sometimes classes become far too intimate and spend too much time delving in each others’ private parts.（有时候，类之间的关系变得非常亲密，并且需要花费大量时间来探究彼此之间的私有成分。）
l 重构手段：
- 类之间的关系过于亲密：Move Method（搬移函数）、Move Field（搬移字段）、Change Bidirectional Association to Unidirectional（将双向关联改为单向关联）
- 如果两个类存在共同点：Extract Class（提炼类）、Hide Delegate（隐藏“委托关系” ）
- 从继承体系中分离子类：Replace Inheritance with Delegation（以委托取代继承）
(15) Lazy Class（冗赘类）
l 描述：Each class you create costs money to maintain and understand. A class that is not doing enough to pay for itself should be eliminated.（你所创建的每个类都需要花钱去维护和理解。一个类如果不值其身价，它就应该消失。）
l 重构手段：
- 对于几乎没用的组件：Inline Class（将类内联化）
- 如果某些子类没有做足够的工作：Collapse Hierarchy（折叠继承体系）
(16) Feature Envy（依恋情节）
l 描述：The whole point of objects is that they are a technique to package data with the processes used on that data. A Feature Envy is a method that seems more interested in a class other than the one it actually is in.（对象的全部要点在于它是一种封装数据以及施加于这些数据的处理过程的技术。依恋情节是指一个方法对别的类的兴趣高过它本身所在的类。）
l 重构手段：
- 函数对某个类的兴趣高过对自己所处类的兴趣：Move Method（搬移函数）、Move Field（搬移字段）
- 函数中只有一部分对其他类更感兴趣：Extract Method（提炼函数）、Move Method（搬移函数）
- 判断哪个类拥有最多被此函数使用的数据，然后就把这个函数和那些数据放在一起
(17) Message Chains（过度耦合的消息链）
l 描述：You see message chains when a client asks one object for another object, which the client then asks for yet another object, which the client then asks for yet another object, and so on. Navigating in this way means that the client is coupled to the structure of the navigation. Any change to the intermediate relationships causes the client to have to change.（你看到的消息链是这样的：当一个客户端向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象，如此反复。这种方式的导航意味着客户端将与整个导航结构紧密耦合在一起。一旦对象之间的联系发生任何改变，将导致客户端也不得不做出相应的修改。）
l 重构手段：
- 存在一长串getThis()或一长串临时变量：Hide Delegate（隐藏“委托关系”）
(18) Middle Man（中间转手人）
l 描述：You look at a class’s interface and find that half the methods are delegating to this other class. It may mean problems.（当你审查一个类的接口时发现其中有一半的方法都委托给了其他类，这也许就意味着存在问题了。）
l 重构手段：
- 过度运用委托（一半及以上的函数都委托给其他类）：Remove Middle Man（移除中间人）
- 如果“不干实事”的函数只有少数几个：Inline Method（内联函数）
- 如果中间人还有其他行为，需要对原对象的行为进行扩展：Replace Delegation with Inheritance（以继承取代委托）
(19) Divergent Change（发散式变化）
l 描述：Divergent change occurs when one class is commonly changed in different ways for different reasons.（如果某个类经常因为不同的原因在不同的方向上发生变化就会产生发散式变化。也就是说，一个类拥有多个引起它发生变化的原因。）
l 重构手段：
- 如果某个类经常因为不同的原因在不同的方向上发生变化【找出某特定原因而造成的所有变化】：Extract Class（提炼类）
(20) Shotgun Surgery（霰弹式修改）
l 描述：Shotgun surgery is similar to divergent change but is the opposite. Every time you make a kind of change, you have to make a lot of little changes to a lot of different classes.（霰弹式修改与发散式变化类似，却又存在相反的一面。每次进行某种修改时，你都必须对多个不同的类进行很多对应的小修改。）
l 重构手段：
- 把所有需要修改的代码放进同一个类中：Move Method（搬移函数）、Move Field（搬移字段）
- 如果眼下没有合适的类可以安置这些代码，就创造一个
- 把一系列相关行为放进同一个类中：Inline Class（将类内联化）
(21) Parallel Inheritance Hierarchies（平行继承体系）
l 描述：Parallel inheritance hierarchies is really a special case of shotgun surgery. In this case, every time you make a subclass of one class, you also have to make a subclass of another. You can recognize this smell because the prefixes of the class names in one hierarchy are the same as the prefixes in another hierarchy.（平行继承体系是霰弹式修改的一个特例。在这种情况下，当你为某个类增加一个子类时，你不得不为另一个类也相应增加一个子类。你也许能够识别到这种味道，因为一个继承体系中类的类名前缀与另一个体系中的类名前缀一样。）
l 重构手段：
- 让一个继承体系的实例引用另一个继承体系的实例：Move Method（搬移函数）、Move Field（搬移字段）
(22) Incomplete Library Class（不完善的程序库类）
l 描述：Library classes should be used carefully, especially we do not know whether a library is completed.（库类在使用时一定要小心，特别是在我们不知道一个库是否完整时。
l 重构手段：
- 如果只想修改库类的一两个函数：Introduce Foreign Method（引入外加函数）
- 如果想要添加一大堆额外行为：Introduce Local Extension（引入本地扩展）
- 常用重构技巧
(1) 重新组织函数(Composing Methods)
l Extract Method(提炼函数)
- 你有一段代码可以被组织在一起并独立出来。
- 将这段代码放进一个独立函数中，并让函数名称解释该函数的用途。
l Inline Method(内联函数)
- 一个函数的本体与名称同样清楚易懂。
- 在函数调用点插入函数本体，然后移除该函数。
l Inline Temp(内联临时变量)
- 你有一个临时变量，只被一个简单表达式赋值一次，而它妨碍了其他重构手法。
- 将所有对该变量的引用动作，替换为对它赋值的那个表达式自身。
l Replace Temp with Query(以查询取代临时变量)
- 你的程序以一个临时变量（temp）保存某一表达式的运算结果。
- 将这个表达式提炼到一个独立函数（即查询式Query）中。将这个临时变量的所有引用点替换为对新函数的调用。此后，新函数就可被其他函数所使用。
l Introduce Explaining Variable(引入解释性变量)
l 你有一个复杂的表达式。
l 将该复杂表达式（或其中一部分）的结果放进一个临时变量，以此变量名称来解释表达式用途。
l Split Temporary Variable(分解临时变量)
- 你的程序有某个临时变量被赋值超过一次，它既不是循环变量，也不是用来收集计算结果的变量。
- 针对每次赋值，创造一个独立的、对应的临时变量。
l Remove Assignments to Parameters(移除对参数的赋值)
- 你的代码对一个参数进行赋值动作。
- 以一个临时变量取代该参数的位置。
l Replace Method with Method Object(以函数对象取代函数)
- 你有一个大型函数，其中对局部变量的使用使你无法釆用 Extract Method。
- 将这个函数放进一个单独对象中，如此一来局部变量就成了对象内的字段。然后你可以在同一个对象中将这个大型函数分解为多个小型函数。
l Substitute Algorithm(替换算法)
- 你想要把某个算法替换为另一个更清晰的算法。
- 将函数本体（method body）替换为另一个算法。
(2) 在对象之间搬移特性(Moving Features Between Objects)
l Move Method(搬移函数)
- 你的程序中，有个函数与其所驻类之外的另一个类进行更多交流：调用后者，或被后者调用。【使用另一个对象的次数比使用自己所驻对象的次数还多。】
- 在该函数最常引用的类中建立一个有着类似行为的新函数。将旧函数变成一个单纯的委托函数（delegating method），或是将旧函数完全移除。
l Move Field(搬移字段)
- 你的程序中，某个字段被其所驻类之外的另一个类更多地用到。
- 在目标类中新建一个字段，修改源字段的所有用户，令它们改用此新字段。
l Extract Class(提炼类)
- 某个类做了应该由两（多）个类做的事。
- 建立一个新类，将相关的字段和函数从旧类搬移到新类
l Inline Class(将类内联化)
- 某个类没有做太多事情（没有承担足够的责任）。
- 将这个类的所有特性搬移到另一个类中，然后移除原类。
l Hide Delegate(隐藏“委托关系”)
- 客户通过一个委托类来调用另一个对象。
- 在服务类上建立客户所需的所有函数，用以隐藏委托关系。
l Remove Middle Man(移除中间人)
- 某个类做了过多的简单委托动作。
- 让客户直接调用受托类。
l Introduce Foreign Method(引入外加函数)
- 你需要为提供服务的类增加一个函数，但你无法修改这个类。
- 在客户类中建立一个函数，并以第一参数形式传入一个服务类实例。
l Introduce Local Extension(引入本地扩展)
- 你需要为服务类提供一些额外函数，但你无法修改这个类。
- 建立一个新类，让它包含这些额外函数。让这个扩展品成为源类的子类或包装类【适配器模式或装饰模式】。
(3) 重新组织数据(Organizing Data)
l Self Encapsulate Field(自封装字段)
- 你直接访问一个字段，但与字段之间的耦合关系逐渐变得笨拙。
- 为这个字段建立取值/设值(Getter/Setter)函数，并且只以这些函数来访问字段。
l Replace Data Value with Object(以对象取代数据值)
- 你有一个数据项，需要与其他数据和行为一起使用才有意义。
- 将数据项变成对象。
l Change Value to Reference(将值对象改为引用对象)
- 你从一个类衍生出许多彼此相等的实例，希望将它们替换为同一个对象。
- 将这个值对象变成一个引用对象。
l Change Reference to Value(将引用对象改为值对象)
- 你有一个引用对象，很小且不可变，而且不易管理。
- 将它变成一个值对象。
l Replace Array with Object(以对象取代数组)
- 你有一个数组，其中的元素各自代表不同的东西。
- 以对象替换数组。对于数组中的每个元素，以一个字段来表示。
l Duplicate Observed Data(复制“被监视数据”)
- 你有一些领域数据置身于GUI控件中，而领域函数需要访问这些数据。
- 将这些数据复制到一个领域对象中。建立一个Observer模式，用以同步领域对象和GUI对象内的重复数据。
l Change Unidirectional Association to Bidirectional(将单向关联改为双向关联)
- 两个类都需要使用对方的特性，但其间只有一条单向连接。
- 添加一个反向指针，并使修改双方关系的函数能够同时更新两条连接。
l Change Bidirectional Association to Unidirectional(将双向关联改为单向关联)
- 两个类之间有双向关联，但其中一个类如今不再需要另一个类的特性。
- 去除不必要的关联。
l Replace Magic Number with Symbolic Constant(以字面常量取代魔法数)
- 你有一个字面数值，带有特别含义。
- 创造一个常量，根据其意义为它命名，并将上述的字面数值替换为这个常量。
l Encapsulate Field(封装字段)
- 你的类中存在一个public字段。
- 将它声明为private，并提供相应的访问函数。
l Encapsulate Collection(封装集合)
- 有个函数返回一个集合。
- 让这个函数返回该集合的一个只读副本，并在这个类中提供添加/移除集合元素的函数。
l Replace Record with Data Class(以数据类取代记录)
- 你需要面对传统编程环境中的记录结构(Record Structure)。
- 为该记录创建一个“哑”数据对象。
实例：将传统的由JDBC返回的结果记录，替换成一个简单的值对象。
l Replace Type Code with Class(以类取代类型码)
- 类之中有一个数值类型码，但它并不影响类的行为。
- 以一个新的类替换该数值类型码。
l Replace Type Code with Subclasses(以子类取代类型码)
- 你有一个不可变的类型码，它会影响类的行为。
- 以子类取代这个类型码。
l Replace Type Code with State/Strategy(以State/Strategy取代类型码)
- 你有一个类型码，它会影响类的行为，但你无法通过继承手法消除它。
- 以状态对象或者具体策略对象取代类型码。
l Replace Subclass with Fields(以字段取代子类)
- 你的各个子类的唯一差别只在“返回常量数据”的函数身上。
- 修改这些函数，使它们返回超类中的某个（新增）字段，然后销毁子类。
(4) 简化条件表达式(Simplifying Conditional Expressions)
l Decompose Conditional(分解条件表达式)
- 你有一个复杂的条件（if-then-else）语句。
- 从if、then、else 三个段落中分别提炼出独立函数。
l Consolidate Conditional Expression(合并条件表达式)
- 你有一系列条件测试，都得到相同结果。
- 将这些测试合并为一个条件表达式，并将这个条件表达式提炼成为一个独立函数。
l Consolidate Duplicate Conditional Fragments(合并重复的条件片段)
- 在条件表达式的每个分支上有着相同的一段代码。
- 将这段重复代码搬移到条件表达式之外。
l Remove Control Flag(移除控制标记)
- 在一系列布尔表达式中，某个变量带有“控制标记”（control flag）的作用。
- 以break语句或return的语句取代控制标记。
l Replace Nested Conditional with Guard Clauses(以卫语句取代嵌套条件表达式)
- 函数中的条件逻辑（Conditional Logic）使人难以看清正常的执行路径。
- 使用卫语句表现所有特殊情况
l Replace Conditional with Polymorphism(以多态取代条件表达式)
- 你手上有个条件表达式，它可以根据对象类型的不同而选择不同的行为。
- 将这个条件表达式的每个分支放进一个子类内的覆写函数中，然后将原始函数声明为抽象函数。
l Introduce Null Object(引入Null对象)
- 你需要再三检查某对象是否为null。
- 将null值替换为null对象。
l Introduce Assertion(引入断言)
- 某一段代码需要对程序状态做出某种假设。
- 以断言(assertion)明确表现这种假设。
(5) 简化函数调用(Making Method Calls Simpler)
l Rename Method(函数改名)
- 函数的名称未能揭示函数的用途。
- 修改函数名称。
l Add Parameter(添加参数)
- 某个函数需要从调用端得到更多信息。
- 为此函数添加一个对象参数，让该对象带进函数所需信息。
l Remove Parameter(移除参数)
- 函数本体不再需要某个参数。
- 将该参数去除。
l Separate Query from Modifier(将查询函数和修改函数分离)
- 某个函数既返回对象状态值，又修改对象状态。
- 建立两个不同的函数，其中一个负责査询，另一个负责修改。
l Parameterize Method(令函数携带参数)
- 若干函数做了类似的工作，但在函数本体中却包含了不同的值。
- 建立单一函数，以参数表达那些不同的值。
l Replace Parameter with Explicit Methods(以明确函数取代参数)
- 你有一个函数，其中完全取决于参数值而采取不同行为。
- 针对该参数的每一个可能值，建立一个独立函数。
l Preserve Whole Object(保持对象完整)
- 你从某个对象中取出若干值，将它们作为某一次函数调用时的参数。
- 改为传递整个对象。
l Replace Parameter with Method(以函数取代参数)
- 对象调用某个函数，并将所得结果作为参数，传递给另一个函数。而接受该参数的函数本身也能够调用前一个函数。
- 让参数接受者去除该项参数，并直接调用前一个函数。
l Introduce Parameter Object(引入参数对象)
- 某些参数总是很自然地同时出现。
- 以一个对象取代这些参数。
l Remove Setting Method(移除设值函数)
- 类中的某个字段应该在对象创建时被设值，然后就不再改变。
- 去掉该字段的所有设值函数。
l Hide Method(隐藏函数)
- 有一个函数，从来没有被其他任何类用到。
- 将这个函数修改为private。
l Replace Constructor with Factory Method(以工厂函数取代构造函数)
- 你希望在创建对象时不仅仅是做简单的建构动作。
- 将构造函数替换为工厂函数。
l Encapsulate Downcast(封装向下转型)
- 某个函数返回的对象，需要由函数调用者执行向下转型（downcast）。
- 将向下转型动作移到函数中。
l Replace Error Code with Exception(以异常取代错误码)
- 某个函数返回一个特定的代码，用以表示某种错误情况。
- 改用异常。
l Replace Exception with Test(以测试取代异常)
- 面对一个调用者可预先检查的条件，你抛出了一个异常。
- 修改调用者，使它在调用函数之前先做检查。
(6) 处理概括关系(Dealing with Generalization)
l Pull Up Field(字段上移)
- 两个子类拥有相同的字段。
- 将该字段移至超类。
l Pull Up Method(函数上移)
- 有些函数，在各个子类中产生完全相同的结果。
- 将该函数移至超类。
l Pull Up Constructor Body(构造函数本体上移)
- 你在各个子类中拥有一些构造函数，它们的本体几乎完全一致。
- 在超类中新建一个构造函数，并在子类构造函数中调用它。
l Push Down Method(函数下移)
- 超类中的某个函数只与部分（而非全部）子类有关。
- 将这个函数移到相关的那些子类去。
l Push Down Field(字段下移)
- 超类中的某个字段只被部分（而非全部）子类用到。
- 将这个字段移到需要它的那些子类中去。
l Extract Subclass(提炼子类)
- 类中的某些特性只被某些（而非全部）实例用到。
- 新建一个子类，将上面所说的那一部分特性移到子类中。
l Extract Superclass(提炼超类)
- 两个类有相似特性。
- 为这两个类建立一个超类，将相同特性移至超类。
l Extract Interface(提炼接口)
- 若干客户使用类接口中的同一子集，或者两个类的接口有部分相同。
- 将相同的子集提炼到一个独立接口中。
l Collapse Hierarchy(折叠继承体系)
- 超类和子类之间无太大区别。
- 将它们合为一体。
l Form Template Method(塑造模板函数)
- 你有一些子类，其中相应的某些函数以相同顺序执行类似的操作，但各个操作的细节上有所不同。
- 将这些操作分别放进独立函数中，并保持它们都有相同的签名，于是原函数也就变得相同了。然后将原函数上移至超类。
l Replace Inheritance with Delegation(以委托取代继承)
- 某个子类只使用超类接口中的一部分，或是根本不需要继承而来的数据。
- 在子类中新建一个字段用以保存超类；调整子类函数，令它改而委托超类；然后去掉两者之间的继承关系。
l Replace Delegation with Inheritance(以继承取代委托)
- 你在两个类之间使用委托关系，并经常为整个接口编写许多极简单的委托函数。
- 让委托类继承受托类。
(7) 大型重构(Big Refactorings)
l Tease Apart Inheritance(梳理并分解继承体系)
- 某个继承体系同时承担两项责任。
- 建立两个继承体系，并通过委托关系让其中一个可以调用另一个。
l Convert Procedural Design to Objects(将过程化设计转化为对象设计)
- 你手上有一些以传统的过程化风格编写的代码。
- 将数据记录变成对象，将大块的行为分成小块，并将行为移入相关对象之中。
l Separate Domain from Presentation(将领域和表述/显示分离)
- 某些GUI类之中包含了领域逻辑(Domain Logic)。
- 将领域逻辑分离出来，为它们建立独立的领域类。
l Extract Hierarchy (提炼继承体系)
- 你有某个类做了太多工作，其中一部分工作是以大量条件表达式完成的。
- 建立继承体系，以一个子类表示一种特殊情况。