对遗留系统组织重构项目

Posted on

对遗留系统组织重构项目 - 透明思考@CSDN

http://blog.csdn.net/gigix

思考着的程序员,程序员的思考

*

用户操作[留言] [发消息] [加为好友] 订阅我的博客XML聚合 FeedSky订阅到鲜果订阅到Google订阅到抓虾[编辑]gigix的公告[编辑]文章分类* (RSS)《软件工艺》

原创 对遗留系统组织重构项目 收藏

很多IT组织都面临一个难题:老系统的维护、升级越来越难做。特别是那些价值高、生命周期长、规模大的核心业务系统,越到后来,要修复一个缺陷或者新增一个功能就需要越大的工作量。这是为什么呢?

软 件的质量体现在两方面:商业方面的质量,以及技术方面的质量。从商业的角度看来,“成功的软件”意味着它所创造的价值超出在它身上付出的代价。从技术的角 度看来,“成功的软件”意味着所有测试都通过、代码结构良好、并且容易理解和维护。很多商业上非常成功的软件系统忽视了技术方面的质量,所以尽管它们仍然 在为IT组织创造价值,但对它们的维护和升级越来越困难。最终技术质量的欠缺会反过来阻碍软件系统创造更大的商业价值。

为了保留并最大化软件资产的价值,适应新的需求变更,老系统总会面对维护和升级。当维护和升级的困难达到一定程度时,很多IT组织就会决定投入一整块资源和时间来改善这些老系统的技术质量,以便将来的维护升级能顺利进行。这样的做法通常被称为“重构项目”。

根据我们的经验,很多重构项目在目标管理、任务划分和质量保证等方面存在比较严重的问题,这些问题导致重构项目不能充分发挥价值。

目标管理

很多重构项目缺乏清晰的、可测试的目标。以ThoughtWorks参 与过的一个重构项目为例,该项目最初的目标只有“提高代码可维护性”等感性的描述,缺乏量化指标。目标不清晰的直接结果是,进行重构的程序员难以明确每一 步的重构工作应该做到什么程度,导致系统各个部分的优化程度不一致,一些部分在经过重构之后仍然质量低下,而且难以确定完成重构的时间。

和 新功能开发一样,重构也同样应该是可验收的,并且验收过程应该尽可能自动化。除了确保其功能性行为仍然保持原样不变之外,重构工作的验收条件还包括单元测 试覆盖率、代码复杂度、编码规范等指标。这些指标的报告应该自动化地生成,及时地展现给所有项目成员,为此我们需要一个持续集成环境来自动、频繁地验证所 有重构工作。

在ThoughtWorks参与的重构项目中,我们采用CruiseControl作为持续集成工具。每次开发者往代码库中签入(check in)代码时,就会触发CruiseControl对项目进行构建,构建的内容包括编译、连接(对于后台部分)、单元测试、测试覆盖率统计、代码复杂度统计、编码规范检查、部署到测试环境、功能测试等。

很多遗留还缺乏有效的项目自动化(automation)机制,使得持续集成环境无法发挥出它最大的价值。在建立持续集成环境的过程中,还应该对项目自动化机制进行改进,确保所有构建工作都能自动完成。于是完整的构建不仅在持续集成服务器上频繁运行,还在每个开发者的工作机器上更加频繁地运行。

任务划分

很多重构项目并没有明确的、细粒度的任务划分,实际进行重构的程序员得到的任务往往是类似“对安全模块进行重构”这样粗粒度、模块级的任务,而项目经理得到的反馈也是类似“可能需要两个月”这样粗略的估计,因此重构项目的进度往往难以控制。

和别的任何开发任务一样,重构任务(以及其他“技术债”类型的任务)也应该符合INVEST的标准:彼此独立(Independent),可讨论(Negotiatable),有价值(Valuable),可估算工作量(Estimatable),足够小(Small),可测试(Testable)。尤其是,它们的工作量应该得到估算,它们应该按照业务价值排列优先级。因为归根到底,重构(以及其他任何开发任务)都归结为“花在代码上的成本”与“对业务创造的价值”之间的权衡。

我们建议按照软件功能模块划分任务,而不区分是新功能开发还是重构。在实际工作中我们发现,对于同样的功能模块,新开发和重构的工作量差别不大。这也意味着重构工作可以被安排在日常开发工作中进行,并统一管理进度。

质量保证

在过去的咨询项目中,我们曾经不止一次见到这样的项目:在缺乏测试覆盖的情况下,程序员们修改旧系统中的代码,试图提高其可读性和可维护性。这些项目往往自称“重构项目”,但实际上它们并不是重构,因为它们缺乏必要的质量保证机制。

按 照定义,重构是对软件内部结构的一种调整,目的是在不改变“软件之可观察行为”的前提下,提高其可理解性,降低其修改成本。如果没有一套可靠的测试机制, 重构就无从谈起,因为你根本就无从知道自己做的调整是否改变了“软件之可观察行为”,甚至可能已经搞得系统不能运行还一无所知。

对 这种没有测试的系统进行重构,就像是编织一张网:先针对一小块功能编写验收测试,在这张“粗网”的保护下再逐渐给代码添加单元测试,有了粗细两层网的保护 再深入重构。随着重构的开展,这张频繁自动化运行的安全网也渐渐铺开。从不断提升的测试覆盖率和不断降低的代码复杂度,我们就能清晰地看到重构的进展情 况。

有 时由于代码质量低劣,程序员们在试图重构时会遇到困难:那些最需要重构的代码也是最难进行单元测试的。通常这是因为模块之间的依赖过于复杂、建立依赖的方 式不佳,而导致无法将这些模块纳入测试。此时需要首先建立验收测试套件,然后用必要的解耦手段调整依赖关系,然后才能对这些模块进行单元测试,之后才能对 它们进行重构。

ThoughtWorks能做什么?

在重构项目的组织、管理、质量保证和实施技术等方面,ThoughtWorks具有无可比拟的能力和经验。我们曾为一些生命周期长至数年、规模大至上百万行代码的遗留系统进行过重构项目,并取得了良好的效果。

我们的咨询师可以和公司中的开发者共同工作,共同解决发现并解决问题。在这个过程中,ThoughtWorks的咨询师会迅速把更佳的工作方式和理念告诉作为客户的开发者,以便在将来没有ThoughtWorks咨询师的情况下,客户也可以坚持那些方发实践,并把它传播给更多的人。

发表于 @ 2008年02月25日 13:30:00 | 评论( loading... )| 编辑| 举报| 收藏

旧一篇:用一朵云重建软件开发者的声望——讲述iTechTag网站的故事 | 新一篇:Announcement: Fluorida 0.0.1

查看最新精华文章 请访问博客首页相关文章

热门招聘职位

希望本站内容对您有点用处,有什么疑问或建议请在后面留言评论
转载请注明作者(RobinChia)和出处 It so life ,请勿用于任何商业用途