标签：
软件配置管理
第1章 软件配置管理概念与目标
(1) 定义（多个）：
l 软件配置管理是指一套管理软件开发和维护过程中所产生的各种中间软件产品的方法和规则，它是控制软件系统演变的学科。
l 软件配置管理是一组针对软件产品的追踪和控制活动，它贯穿于项目生命周期的始终，并代表着软件产品接受各项评审。
l 软件配置管理是贯穿于整个软件过程中的保护性活动，它被设计用来：(1) 标识变化；(2) 控制变化；(3) 保证变化被适当的发现；(4) 向其他可能有兴趣的人员报告变化。
(2) 目标：
l 软件配置管理的各项工作是有计划进行的。
l 被选择的项目产品得到识别，控制并且可以被相关人员获取。
l 已识别出的项目产品的更改得到控制。
l 使相关组别和个人及时了解软件基准的状态和内容。
(3) 目的：使错误降为最小并最有效地提高生产效率。
最终软件版本产品是文档、程序和数据的集合，是软件生产商交付给客户的软件产品，是用户能够直接使用的软件产品。
软件配置是一个软件产品在生存期各个阶段的不同形式（记录特定信息的不同媒体）和不同版本的程序、文档及相关数据的集合，或者说是配置项的集合。
l 软件配置是一个集合，该集合中的每一个元素称为该软件产品软件配置中的一个配置项。
l 软件配置项是软件配置管理的对象，一个软件配置项是项目中一个特定的、可文档化的工作产品集。
(1) 概念
l 基线是指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。
l 基线是已经正式通过复审和批准的某规约和产品。
l 经过正式评审和审计，并被批准后的阶段性软件工作产品，称为软件配置管理中的一根基线。
(2) 分类
l 功能基线：
l 指派基线：又称为分配基线，指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明，指派基线是最初批准的指派配置标识。
l 产品基线：指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明，产品基线是最初批准的产品配置标识。
l 负责管理软件配置项变更的组织。
l 具体责任如下：
第2章 软件配置管理角色与过程
(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根据项目的进展情况，审核各种变更请求，并适时的划定新的基线，保证开发和维护工作有序的进行。
(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。
² 主版本号的增加表示提供给客户的主要产品功能的增强。
² 特征版本号的增加表示产品新增了一些特征或做了一些重要修改。
² 缺陷修复版本号的增加表示在软件产品上做了一些缺陷修复工作。
l α和β版本编号
² α测试是由公司内部的用户在模拟实际操作环境下进行的测试。
² β测试是由软件的多个用户在实际使用环境下进行的测试。
(2) 属性版本编号
l 把版本的重要属性反映在标识中。可以包括的属性有：客户名、开发语言、开发状态、硬件平台、生成日期等。例如：J2SDK.v.l.2.2:10/31/2000-18:00,native threads, jit-122(Jit(Just in Time)：Java即时编译技术)
l 包含的信息丰富，方便了查询和管理，版本间的关系易于保持，但由于太复杂，一般只用于软件组织内部的管理。
第3章 软件配置管理核心功能
(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 变更管理的流程：
l 为了更好的指导变更范围的影响分析，可以通过两种表格来帮助发现受到变更影响的内容，一种是《需求跟踪表》，一种是《配置项依赖关系表》：
(3) 配置库管理
l 设置版本分支：为每个配置项从建立开始就划分成3个不同的分支：私有分支、集成分支、公共（主干）分支，让它们分别对应3类工作空间：
l 配置库的设置：决定配置库的结构是配置管理活动的重要基础，一般常用的是两种组织形式：按配置项类型分类建库和按任务建库。
l 配置库的日常工作：配置库的日常工作是一些事务性的工作，主要保证配置库的安全性，包括：
(4) 配置审计：配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。
l 配置审计有两种:
² 配置项是否齐备
² 版本是否齐全
l 配置审计步骤：
(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章)
(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及以前)不支持异地开发
(1) 特点
l CVS采用客户机/服务器体系结构，代码、文档的各种版本都存储在服务器端，开发者首先从服务器上获得一份复制到本机，然后在此基础上进行开发。
l 基于“拷贝—修改—合并”的并发控制
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麻烦不少，这是比较令人遗憾的。
(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 两种方案比较与选择
代码味道与重构
(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（可度量的味道）
l Unneccessary Complexity（不必要的复杂性）
l Duplication（重复）
l Conditional Logic（条件逻辑）
(2) 类间味道
l Data（数据）
l Inheritance（继承）
l Responsibility（职责）
l Accommodating Change（协调变化）
l Library Classes（库类）
(1) Long Method（过长函数）
l 描述：A method is too long.（方法太长。）
l 重构手段：
(2) Large Class（过大类）
l 描述：A class is trying to do too much, it often shows up as too many instance variables.（一个类试图做太多的事情，通常会出现太多的实例变量。）
l 重构手段：
(3) Long Parameter List（过长参数列）
l 描述：A method needs passing too many parameters.（一个方法需要传递太多的参数。）
l 重构手段：
(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 重构手段：
(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 重构手段：
(6) Duplicated Code（重复代码）
l 描述：Same code structure happens in more than one place.（在一个以上的地方发现相似的代码结构。）
l 类型：
l 重构手段：
(7) Alternative Classes with Different Interfaces（异曲同工的类）
l 描述：Classes are doing similar things but with different signatures. （不同的类做相同的事情，却拥有不同的签名，主要是指方法签名不同。）
l 重构手段：
(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 重构手段：
(9) Primitive Obsession（基本类型偏执）
l 描述：Primitive types are overused in software. Small classes should be used in place of primitive types in some situations.（在软件中，基本类型被过度使用。在某些场合下，应该使用一些小的类来代替这些基本类型。）
l 重构手段：
(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 重构手段：
(11) Data Clumps（数据泥团）
l 描述：Some data items together in lots of places: fields in a couple of classes, parameters in many method signatures.（一些数据项同时出现在多个地方，例如一对类中的值域【成员变量】，多个方法签名中的参数等。）
l 重构手段：
(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 重构手段：
(13) Refused Bequest（被拒绝的遗赠）
l 描述：Subclasses get to inherit the methods and data of their parents, but they just use a few of them.（子类继承父类的方法和数据，但是它们只需要使用其中的一部分。）
l 重构手段：
(14) Inappropriate Intimacy（狎昵关系）
l 描述：Sometimes classes become far too intimate and spend too much time delving in each others’ private parts.（有时候，类之间的关系变得非常亲密，并且需要花费大量时间来探究彼此之间的私有成分。）
l 重构手段：
(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 重构手段：
(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 重构手段：
(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 重构手段：
(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 重构手段：
(19) Divergent Change（发散式变化）
l 描述：Divergent change occurs when one class is commonly changed in different ways for different reasons.（如果某个类经常因为不同的原因在不同的方向上发生变化就会产生发散式变化。也就是说，一个类拥有多个引起它发生变化的原因。）
l 重构手段：
(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 重构手段：
(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 重构手段：
(22) Incomplete Library Class（不完善的程序库类）
l 描述：Library classes should be used carefully, especially we do not know whether a library is completed.（库类在使用时一定要小心，特别是在我们不知道一个库是否完整时。
l 重构手段：
(1) 重新组织函数(Composing Methods)
l Extract Method(提炼函数)
l Inline Method(内联函数)
l Inline Temp(内联临时变量)
l Replace Temp with Query(以查询取代临时变量)
l Introduce Explaining Variable(引入解释性变量)
l 你有一个复杂的表达式。
l 将该复杂表达式（或其中一部分）的结果放进一个临时变量，以此变量名称来解释表达式用途。
l Split Temporary Variable(分解临时变量)
l Remove Assignments to Parameters(移除对参数的赋值)
l Replace Method with Method Object(以函数对象取代函数)
l Substitute Algorithm(替换算法)
(2) 在对象之间搬移特性(Moving Features Between Objects)
l Move 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(自封装字段)
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(复制“被监视数据”)
l Change Unidirectional Association to Bidirectional(将单向关联改为双向关联)
l Change Bidirectional Association to Unidirectional(将双向关联改为单向关联)
l Replace Magic Number with Symbolic Constant(以字面常量取代魔法数)
l Encapsulate Field(封装字段)
l Encapsulate Collection(封装集合)
l Replace Record with Data Class(以数据类取代记录)
实例：将传统的由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(分解条件表达式)
l Consolidate Conditional Expression(合并条件表达式)
l Consolidate Duplicate Conditional Fragments(合并重复的条件片段)
l Remove Control Flag(移除控制标记)
l Replace Nested Conditional with Guard Clauses(以卫语句取代嵌套条件表达式)
l Replace Conditional with Polymorphism(以多态取代条件表达式)
l Introduce Null Object(引入Null对象)
l Introduce 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(隐藏函数)
l Replace Constructor with Factory Method(以工厂函数取代构造函数)
l Encapsulate 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(将领域和表述/显示分离)
l Extract Hierarchy (提炼继承体系)
标签：
原文地址：http://www.cnblogs.com/zqlmmd/p/5459936.html
