软件配置管理复习
软件配置管理程序员
第1章 软件配置管理概念与目标算法
- 软件配置管理(Software Configuration Management, SCM)
(1) 定义（多个）：数据库
l 软件配置管理是指一套管理软件开发和维护过程当中所产生的各类中间软件产品的方法和规则，它是控制软件系统演变的学科。编程
l 软件配置管理是一组针对软件产品的追踪和控制活动，它贯穿于项目生命周期的始终，并表明着软件产品接受各项评审。数组
l 软件配置管理是贯穿于整个软件过程当中的保护性活动，它被设计用来：(1) 标识变化；(2) 控制变化；(3) 保证变化被适当的发现；(4) 向其余可能有兴趣的人员报告变化。安全
(2) 目标：服务器
l 软件配置管理的各项工做是有计划进行的。网络
l 被选择的项目产品获得识别，控制而且能够被相关人员获取。session
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 (提炼继承体系)
- 你有某个类作了太多工做，其中一部分工做是以大量条件表达式完成的。
- 创建继承体系，以一个子类表示一种特殊状况。
- 1. 软件配置管理
- 2. SCM软件配置管理
- 3. HIT-SC-软件生命周期与配置管理复习
- 4. 软件测试管理方法（九）——软件配置管理
- 5. 软件项目管理复习笔记
- 6. 软件配置管理方针
- 7. 软件配置管理工做心得
- 8. 软件包/仓库管理与配置
- 9. 软件配置管理工程师(SCM)
- 10. 软件配置管理基本术语
- 更多相关文章...
- • XSL-FO 软件 - XSL-FO 教程
- • Maven 构建配置文件 - Maven教程
- • IDEA下SpringBoot工程配置文件没有提示
- • IntelliJ IDEA 代码格式化配置和快捷键
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 外部其他进程嵌入到qt FindWindow获得窗口句柄 报错无法链接的外部符号 [email protected] 无法被([email protected]@[email protected]@@引用
- 2. UVa 11524 - InCircle
- 3. The Monocycle（bfs）
- 4. VEC-C滑窗
- 5. 堆排序的应用-TOPK问题
- 6. 实例演示ElasticSearch索引查询term,match,match_phase,query_string之间的区别
- 7. 数学基础知识 集合
- 8. amazeUI 复择框问题解决
- 9. 背包问题理解
- 10. 算数平均-几何平均不等式的证明,从麦克劳林到柯西
- 1. 软件配置管理
- 2. SCM软件配置管理
- 3. HIT-SC-软件生命周期与配置管理复习
- 4. 软件测试管理方法（九）——软件配置管理
- 5. 软件项目管理复习笔记
- 6. 软件配置管理方针
- 7. 软件配置管理工做心得
- 8. 软件包/仓库管理与配置
- 9. 软件配置管理工程师(SCM)
- 10. 软件配置管理基本术语