敏捷开发下的重构技术

1、敏捷开发下的重构技术1 概述软件开发流程是指将在开发、 运营、维护软件的过程中很多 技术、做法、习惯和思想统一到一个体系中。从而能提高软件开 发、运营和维护的效率，以及提升用户满意度、软件的可靠性和 可维护性。经过这些年的积累，软件开发模型从最早最简单的 瀑布模型开始发展出了包括原型法、 演化原型法、增量开发、 螺旋模型、 V 模型、混沌模型和近年流行的敏捷开发模式。2 敏捷开发特点敏捷开发是一种采取迭代开发方式， 以人作为驱动核心的一 种软件开发流程。团队成员无缝的交流，如每天短时间的站立会 议。拒绝使用一切形式化的东西，使用简单易用的工具开始工作。 在需求变化越来越不确定和产品原型周期要求

2、越来越短的今天， 敏捷开发模式被越来越多的开发团队所接受。理论上看敏捷方法论无比完美：图 1 敏捷流程图第一步：找出完成项目需要做的事情。图中 Product Backlog ，是指“积压的任务”或“待解决的问题”。 Backlog 的管理工作主要由 Scrum Master 来主导。第二步：当前的冲刺主要需要解决的事情 Sprint Backlog 任务被进一步细化为小的 Task。如果一个任务的估计时间太长， 那么它就应该被进一步分解。第三步：冲刺（ Sprint ）。在冲刺阶段，一切对交流只能通 过 Scrum Master 来完成。冲刺期间 ，每天要开一个每日 “站 会”，大家依次报告

3、各自每天的进度情况。 平且有任何需求的改 变都留待冲刺结束后再讨论。在完成项目之前， 通常使用燃尽图来对需要完成的工作的一 种可视化表示（图 2）。在燃尽图中，纵轴、横轴分别代表工作和时间。在理想情况 下，燃尽图应是一个向下的曲线， 直到完成剩余的工作， “烧尽” 至零。3 敏捷开发中的重构所谓重构（ Refactoring ）就是对软件现有的功能进行充分 的利用，通过对程序代码进行调整，进一步提高软件的质量，丰 富软件的性能， 在一定程度上使程序的设计模式和架构趋于合理 化，从而提高软件的可扩展性和可维护性。从本质上说，重构就 是调整软件的内部结构，其目的主要是在现有软件功能的基础 上，降低

4、软件的修改成本，同时提高软件的可理解性。对于重构 的方式，通常情况下可以分为代码重构、设计重构、架构重构和 业务重构。3.1 代码重构代码重构是指在编码规范层面上对细粒度代码实行规范化 的过程。 代码重构由于其是处在方法级别重构技术， 所以无论是 在传统开发流程还在敏捷开发模式中都适应。 下面是一些常用代 码重构方法： 封装成员变量： 将仅限于本类使用的变量重写成私有成员 变量，并提供访问方法。 这种重构方式可以将与外部调用者无关 的变量隐藏起来，减少代码的耦合性，并减少意外出错的概率。 提取方法： 将大段代码中的一部分提取后， 构成一个新方 法。这种重构可以使整段程序的结构变得更清晰， 从而

5、增加可读 性。这也对函数通用。 一般化类型：将多个类/函数共用的类型抽象出可以公用 的基类，然后利用多态性追加每个类 /函数需要的特殊函数。这 种重构可以让结构更加清晰，同时可以增加代码的可维护性。 函数归父：也叫函数上移，是指将子类方法上移到父类。避免行为的重复性。虽然重复的两个函数可以各自工作，但是， 对自身进行重复，会成引发错误。无论在任何情况下，系统内部 只要出现重复，同时只能修改其中的一个。 函数归子：也叫函数下移，是指将父类的方法下移到子类。 函数归子恰恰相反于函数归父。 在必要的情况下， 将某些行为从 父类移至特定的子类时， 这时就可以使用函数归子， 它通常也只 在这种时候有用。

6、 方法更名： 将方法名称以更好的表达它的用途。 方法更名说的简单点就是把方法启一个与它功能相对应的名称， 当你的方 法是求和操作时，你的方法名应该是Sum( int param )，而不要写成 a( int param )。3.2 软件设计重构 设计重构是在代码重构之上更高级别重构技术， 通常(面向 对象语言中) 采取面向对象的分析和设计原则， 选择合适的设计 原则和设计模式来构建类之间依赖关系。 在敏捷开发中通常采取 如下设计重构方法： 单一职责原则： 对于一个类来说， 引起它变化的原因应该 仅有一个。简单地说，就是一个类只具有一个功能，这是因为， 如果一个类能够实现两个功能， 必然造成一个

7、功能的变动会污染 另外一个功能的代码。 开放 -封闭原则：类、模块、函数等软件实体，通常情况 下都是可以扩展的，但是不可对其进行修改。简单地说，该原则 的极限情况是， 如果完成一个软件实体， 那么这个软件实体以后 不允许改动，而且，当添加新功能时，在不修改原来的代码的基 础上可以继续书写代码。 在社会实践中， 虽然达不到这种理想情 况，但是可以接近，通常情况下，这种接近的状态就是一种比较 完美的状态。 Liskov替换原则：子类型必须能对它们的基类型进行替 换。简单的说，该原则就，如果不是基于“is -a”的原则进行继 承，这种情况下比较危险，这是因为，由于时间、开发者之间存 在差异，在一定程

8、度上可能导致子类型替换父类型。 依赖倒置原则：对于高层模块来说，不能对低层模块形成 依赖，二者之间应该依赖于抽象。简单的说，因为软件的策略部 分和业务模型主要集中在高层模块， 这是软件的主要特征。另外， 在实际编程过程中，高层模块是应用最多的，在很多库的支持下， 细节模块不再那么重要。在这种情况下，可以说，高层不依赖于 低层。接口隔离原则：在实际使用过程中，防止客户依赖它们不用的方法。简单地说，就是将接口进行内聚处理，如 果接口缺乏相应的内聚性， 在这种情况下，就会出现接口中的某 些方法会被污染。这是因为，当一个客户使用的接口中包含他不 需要的方法时，这时改动客户不需要的方法， 就会对客户的接

9、口 造成污染，进而在一定程度上污染了客户的代码。3.3 系统架构重构 对于传统的架构设计，通常情况下主要包括两个方面， 分别 为架构和设计。其中，设计包含详细设计（详细的类图，顺序图 等UML图）、详细的API设计以及接口描述，存储层数据库表字 段设计等。当前，随着社会节奏的不断加快，进一步使得业务需 求、技术等都在快速地变化着，在进行架构设计时，前期花费的 时间约占 30%。在进行需求分析时，如果分析不彻底，就会导致 开发出的软件不符合市场需求， 甚至需求发生变动，就会改动成 本。如图 3所示，描述了敏捷开发前和后架构方式：图 3 敏捷开发前后架构设计方式3.4 业务流程重构业务流程重构即B

10、PR BPR的思想是指精简企业机构设置， 简化企业业务沉程，以降低经营运行成本，提高企业经济效益， 大限度地减少或精简不必要的业务流程。随着大数据、云计算、 移动设备、 社交商务等 IT 趋势的发展， 新业务形态对 IT 基础架 构带来了新的挑战。4 结束语对于代码来说， 需要明确它要做的内容， 对于如何做的问题， 需要通过重构来解决。重构的目的就是通过对程序代码进行调 整，进而在一定程度上提高软件的质量，丰富软件的性能，使得 程序的设计模式、 架构趋于合理， 同时提高软件的可扩展性和可 维护性。对于软件产品来说，最初制造出来，通常情况下需要经 过精心设计，并且具备良好的架构。但是，随着时间的延长，用 户的需求发生了变化，在这种情况下需要对原有的功能进行修 改，或者添加新的功能。在这一过程中，需要对软件存在的缺陷 进行修改和完善。 为了不断满