对遗留系统组织重构项目
Posted on对遗留系统组织重构项目 - 透明思考@CSDN
http://blog.csdn.net/gigix
思考着的程序员,程序员的思考
*
用户操作[留言] [发消息] [加为好友] 订阅我的博客 [编辑]gigix的公告[编辑]文章分类* 《软件工艺》
- 技术文章
- 人物访谈
- 散文随笔
- 剃刀书评
- 新闻评论[编辑]测试Arrays.asList("Rod", "Jane", "Freddy");(RSS)存档* 2010年03月(1)
- 2008年04月(1)
- 2008年03月(2)
- 2008年02月(1)
- 2007年12月(3)
- 2007年11月(4)
- 2007年10月(4)
- 2007年09月(1)
- 2007年08月(1)
- 2007年07月(1)
- 2007年06月(3)
- 2007年05月(1)
- 2007年04月(2)
- 2007年03月(6)
- 2007年02月(4)
- 2007年01月(2)
- 2006年10月(1)
- 2006年09月(2)
- 2006年08月(1)
- 2006年07月(5)
- 2006年06月(10)
- 2006年05月(1)
- 2006年04月(2)
- 2006年03月(12)
- 2006年02月(9)
- 2006年01月(1)
- 2005年11月(4)
- 2005年09月(7)
- 2005年08月(5)
- 2005年06月(1)
- 2005年02月(2)
- 2005年01月(2)
- 2004年08月(1)
- 2004年07月(2)
- 2004年06月(1)
- 2004年05月(1)
- 2004年04月(1)
- 2004年03月(4)
- 2004年02月(3)
- 2003年12月(7)
- 2003年11月(8)
- 2003年10月(2)
- 2003年09月(9)
- 2003年08月(9)
- 2003年07月(7)
- 2003年06月(14)
- 2003年05月(15)
- 2003年04月(1)
- 2003年03月(3)
- 2003年02月(5)
- 2003年01月(2)
- 2002年12月(2)
- 2002年11月(3)
- 2002年10月(3)
- 2002年09月(1)
- 2002年08月(1)
- 2002年07月(3)
- 2002年06月(2)
- 2002年05月(3)
- 2002年04月(41)
- 2002年03月(102)
- 2002年02月(1)
- 2001年11月(1)
- 2001年10月(4)
- 2001年08月(1)
公告: [意见反馈][官方博客]
对遗留系统组织重构项目 收藏
很多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
查看最新精华文章 请访问博客首页相关文章