很多IT组织都面临一个难题:老系统的维护、升级越来越难做。特别是那些价值高、生命周期长、规模大的核心业务系统,越到后来,要修复一个缺陷或者新增一个功能就需要越大的工作量。这是为什么呢?
软 件的质量体现在两方面:商业方面的质量,以及技术方面的质量。从商业的角度看来,“成功的软件”意味着它所创造的价值超出在它身上付出的代价。从技术的角 度看来,“成功的软件”意味着所有测试都通过、代码结构良好、并且容易理解和维护。很多商业上非常成功的软件系统忽视了技术方面的质量,所以尽管它们仍然 在为IT组织创造价值,但对它们的维护和升级越来越困难。最终技术质量的欠缺会反过来阻碍软件系统创造更大的商业价值。
为了保留并最大化软件资产的价值,适应新的需求变更,老系统总会面对维护和升级。当维护和升级的困难达到一定程度时,很多IT组织就会决定投入一整块资源和时间来改善这些老系统的技术质量,以便将来的维护升级能顺利进行。这样的做法通常被称为“重构项目”。
根据我们的经验,很多重构项目在目标管理、任务划分和质量保证等方面存在比较严重的问题,这些问题导致重构项目不能充分发挥价值。
目标管理
很多重构项目缺乏清晰的、可测试的目标。以ThoughtWorks参 与过的一个重构项目为例,该项目最初的目标只有“提高代码可维护性”等感性的描述,缺乏量化指标。目标不清晰的直接结果是,进行重构的程序员难以明确每一 步的重构工作应该做到什么程度,导致系统各个部分的优化程度不一致,一些部分在经过重构之后仍然质量低下,而且难以确定完成重构的时间。
和 新功能开发一样,重构也同样应该是可验收的,并且验收过程应该尽可能自动化。除了确保其功能性行为仍然保持原样不变之外,重构工作的验收条件还包括单元测 试覆盖率、代码复杂度、编码规范等指标。这些指标的报告应该自动化地生成,及时地展现给所有项目成员,为此我们需要一个持续集成环境来自动、频繁地验证所 有重构工作。
在ThoughtWorks参与的重构项目中,我们采用CruiseControl作为持续集成工具。每次开发者往代码库中签入(check in)代码时,就会触发CruiseControl对项目进行构建,构建的内容包括编译、连接(对于后台部分)、单元测试、测试覆盖率统计、代码复杂度统计、编码规范检查、部署到测试环境、功能测试等。
很多遗留还缺乏有效的项目自动化(automation)机制,使得持续集成环境无法发挥出它最大的价值。在建立持续集成环境的过程中,还应该对项目自动化机制进行改进,确保所有构建工作都能自动完成。于是完整的构建不仅在持续集成服务器上频繁运行,还在每个开发者的工作机器上更加频繁地运行。
任务划分
很多重构项目并没有明确的、细粒度的任务划分,实际进行重构的程序员得到的任务往往是类似“对安全模块进行重构”这样粗粒度、模块级的任务,而项目经理得到的反馈也是类似“可能需要两个月”这样粗略的估计,因此重构项目的进度往往难以控制。
和别的任何开发任务一样,重构任务(以及其他“技术债”类型的任务)也应该符合INVEST的标准:彼此独立(Independent),可讨论(Negotiatable),有价值(Valuable),可估算工作量(Estimatable),足够小(Small),可测试(Testable)。尤其是,它们的工作量应该得到估算,它们应该按照业务价值排列优先级。因为归根到底,重构(以及其他任何开发任务)都归结为“花在代码上的成本”与“对业务创造的价值”之间的权衡。
我们建议按照软件功能模块划分任务,而不区分是新功能开发还是重构。在实际工作中我们发现,对于同样的功能模块,新开发和重构的工作量差别不大。这也意味着重构工作可以被安排在日常开发工作中进行,并统一管理进度。
质量保证
在过去的咨询项目中,我们曾经不止一次见到这样的项目:在缺乏测试覆盖的情况下,程序员们修改旧系统中的代码,试图提高其可读性和可维护性。这些项目往往自称“重构项目”,但实际上它们并不是重构,因为它们缺乏必要的质量保证机制。
按 照定义,重构是对软件内部结构的一种调整,目的是在不改变“软件之可观察行为”的前提下,提高其可理解性,降低其修改成本。如果没有一套可靠的测试机制, 重构就无从谈起,因为你根本就无从知道自己做的调整是否改变了“软件之可观察行为”,甚至可能已经搞得系统不能运行还一无所知。
对 这种没有测试的系统进行重构,就像是编织一张网:先针对一小块功能编写验收测试,在这张“粗网”的保护下再逐渐给代码添加单元测试,有了粗细两层网的保护 再深入重构。随着重构的开展,这张频繁自动化运行的安全网也渐渐铺开。从不断提升的测试覆盖率和不断降低的代码复杂度,我们就能清晰地看到重构的进展情 况。
有 时由于代码质量低劣,程序员们在试图重构时会遇到困难:那些最需要重构的代码也是最难进行单元测试的。通常这是因为模块之间的依赖过于复杂、建立依赖的方 式不佳,而导致无法将这些模块纳入测试。此时需要首先建立验收测试套件,然后用必要的解耦手段调整依赖关系,然后才能对这些模块进行单元测试,之后才能对 它们进行重构。
ThoughtWorks能做什么?
在重构项目的组织、管理、质量保证和实施技术等方面,ThoughtWorks具有无可比拟的能力和经验。我们曾为一些生命周期长至数年、规模大至上百万行代码的遗留系统进行过重构项目,并取得了良好的效果。
我们的咨询师可以和公司中的开发者共同工作,共同解决发现并解决问题。在这个过程中,ThoughtWorks的咨询师会迅速把更佳的工作方式和理念告诉作为客户的开发者,以便在将来没有ThoughtWorks咨询师的情况下,客户也可以坚持那些方发实践,并把它传播给更多的人。
分享到:
相关推荐
遗留系统重构与维护,火龙果软件课程讲义,着重介绍软件维护思想
描述了如何用重构的方法对大型遗留系统进行修补 对维护大型系统是一个新的思路
GMTC全球移动技术大会ppt 作者:@凉粉小刀 主题: iOS遗留系统上的架构重构
基于Matlab的遗留系统并行化重构方法.pdf
iOS遗留系统上的架构重构 李剑.pdf
使用标签查看重构的不同阶段阶段初始 -> 启动重构项目First Output Test -> Create first test 将输出保存到文件常量和魔术字符串 -> 自动加载和提取变量。 复杂的条件 -> 要简单游戏测试方法 -> 简单测试复杂的...
处理遗留系统
遗留系统SOA迁移解决方案,经受过实战检验的好方案
重构遗留代码,浮现架构之道-2013.04.02.pdf
在过去的几个月内,我主导着团队完成了一项工程浩大(累积八个人月的工作量)的重构工作——为我们的App替换数据库。之所以能够把这种伤筋动骨的事情称之为重构,是因为在这段时间内,我们每天向主干合并两到三次...
一种Java遗留系统服务化切分和封装方法
可口可乐-用于系统重构和分析的工具箱 是一个工具箱,专为遗留系统重构和分析而设计,包括调用图,概念分析,api树,设计模式建议。 是一个用于系统重构,系统迁移和系统分析的瑞士军刀。它可以分析代码中的测试坏味...
技巧1:使用分析器 分析器提供了任何其他工具无法提供的功能,从而能够深入检查你的应用。如果你的应用已经有一年多时间没有被分析过了,那么它肯定会有大块大块的低效代码,潜伏在某个黑暗的角落。...
可视化的遗留系统微服务改造(54页).pdf
python遗留物检测项目源码和测试视频数据都有
本文来自于servicecomb,本章探讨使用微服务改造遗留系统实践中的一些问题,希望对您能有所帮助。随着RESTful、云计算、DevOps、持续交付等概念的深入人心,微服务(Microservices)逐渐成为系统架构的一个代名词。...
大学生课程设计毕业设计项目、系统开发,供计算机等专业同学参考,提供说明材料+源代码 大学生课程设计毕业设计项目、系统开发,供计算机等专业同学参考,提供说明材料+源代码 大学生课程设计毕业设计项目、系统开发...
面对遗留系统,选择合适的测试策略,能让自动化测试的投入在一定时期内看到效果,并且建立可持续进行的机制。同为自动化测试,每种测试在面对遗留系统时遇到的挑战是不同的,起到的效果也不尽相同。 背景我目前所...
基于SOA架构的企业遗留系统复用研究