`
gigix
  • 浏览: 352764 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

对遗留系统组织重构项目

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

根据我们的经验,很多重构项目在目标管理、任务划分和质量保证等方面存在比较严重的问题,这些问题导致重构项目不能充分发挥价值。
分享到:
评论
23 楼 kaipingk 2008-04-02  
很有意义的事情,不过做起来的确相当难!尤其是表现层的东西,期待下文
22 楼 gigix 2008-03-11  
Lucas Lee 写道
看了一下链接的帖子,明显就是TW的广告么。
并没有什么独特的内容。

没错,就是广告。
一个很简单的道理:遗留系统那么多,那么多经验丰富的技术主管们成天就在为这些系统头疼,如果只要一篇文章、一个“独特的点子”就能解决的话,他们怎么可能还解决不了?
巴菲特说他怎么赚钱的办法说起来也很简单。原则总是很简单的,简单不等于容易。士兵上战场的原则最简单了,让自己不被打死,尽量打死一点敌人。很简单,但一点都不容易。
遗留系统重构也是一样。原则就这么简单,我都可以写出来。但是谁真正能提供这种服务?我相信那些正在头疼的主管们乐于看到这样的广告。
21 楼 LucasLee 2008-03-11  
看了一下链接的帖子,明显就是TW的广告么。
并没有什么独特的内容。
20 楼 gigix 2008-03-11  
Godlikeme 写道
这里问题的焦点不在于 什么叫重构,怎么做重构。
而是重构的对象,遗留系统。
真的有这种可能么?作为客户方的银行、电信、制造业 这样的系统使用者去发起重构

书上都写了,为什么会觉得别人没有看,莫明其妙。

而lz文章里所讲只是一般的产品所有者在研发阶段所作大规模重构,为产品长期发展所作工作,麻烦不要混淆。

说到经验,那就请拿点实例出来,让大家了解一下。

谁也没说是由使用者来发起的,你为什么有这个印象?
19 楼 Godlikeme 2008-03-11  
这里问题的焦点不在于 什么叫重构,怎么做重构。
而是重构的对象,遗留系统。
真的有这种可能么?作为客户方的银行、电信、制造业 这样的系统使用者去发起重构。

书上都写了,为什么会觉得别人没有看,莫明其妙。

而lz文章里所讲只是一般的产品所有者在研发阶段所作大规模重构,为产品长期发展所作工作,麻烦不要混淆。

说到经验,那就请拿点实例出来,让大家了解一下。
18 楼 sg552 2008-03-11  
gigix 写道

有一些来自银行、电信、制造业之类很资深的信息主管看了这个文章以后告诉我们,他在很长的时间里以为这样的项目就没救了,没想到我们还有办法,虽然不是一针下去起死回生的灵丹妙药,至少能给他指出一条朝向逐渐改进的实际可行的路。这种事情,都是身在其中才知道有多疼,没有这种经验的人看看是没啥感觉的。
一个更完整的版本应该会在下期《程序员》杂志发表。


是的。看着那么多钱和人月的项目,就因为后期开发太麻烦,而推倒重新来,实在是太浪费了。
对遗留系统的重构我认为在国内很有前途。

gigix太能吊人胃口了……
希望下个文章能带个例子说明一下啊。

17 楼 jimmy_c 2008-03-11  
重构这东西,其实很简单:1. 简单化;2. 同义转换。只是没有写过大型软件,没有跌过跟头的人是很难体会到它的重要性和方法的。
这不昨天一个有经验的程序员,我告诉他他写的程序“很烂”,是一堆补丁组成的难以理解的程序,需要重构,可他却把每个补丁的由来给我讲一遍,并且说:我也不想这样。
重构更多的是习惯和信仰。随时随地地把你的代码写的更简单,让你的team读你的代码时感觉轻松一些,避免逻辑陷阱。前两天有个帖子谈团队精神,什么是“团队精神”?这就是团队精神。
16 楼 gigix 2008-03-11  
sg552 写道
虽然很不起眼,但是第12章:大型重构 却确实存在的。小型重构只需要几分钟,
跑几次UnitTest,大型重构却需要数月甚至几年。

因此,对遗留系统进行重构,就是一个大型重构。文章和题目都是围绕重构这个核心。
文很对题。

我对这个文章很期待,因为国内的相关文章几乎没有。

有一些来自银行、电信、制造业之类很资深的信息主管看了这个文章以后告诉我们,他在很长的时间里以为这样的项目就没救了,没想到我们还有办法,虽然不是一针下去起死回生的灵丹妙药,至少能给他指出一条朝向逐渐改进的实际可行的路。这种事情,都是身在其中才知道有多疼,没有这种经验的人看看是没啥感觉的。
一个更完整的版本应该会在下期《程序员》杂志发表。
15 楼 sg552 2008-03-11  
Godlikeme 写道
个人05年买的英文原版,所以这样说。

这件事情我较真了,是觉得很值得较的。

泛泛的讲,重构是随时随地的,不需要分场合。
而楼主文章所言是比较正式、系统的,有计划有目标的去做重构,所谓文不对题。





我觉得你的研究精神不错。

不过你手上既然有《Refactoring》E文版,请翻开目录,看下第12章的标题。
是不是 "Big Refactorings, by Kent Beck and Martin Fowler"。

没错,重构一书前里绝大部分章节介绍的是细节重构,提取个函数,提取个方法,
简化条件表达式等等,只限于几行代码或几个类。

虽然很不起眼,但是第12章:大型重构 却确实存在的。小型重构只需要几分钟,
跑几次UnitTest,大型重构却需要数月甚至几年。

因此,对遗留系统进行重构,就是一个大型重构。文章和题目都是围绕重构这个核心。
文很对题。

我对这个文章很期待,因为国内的相关文章几乎没有。牛人没时间写,有时间的庸才又
写不出来。

非常期待这个文章,希望了解的更多。


14 楼 Godlikeme 2008-03-10  
个人05年买的英文原版,所以这样说。

这件事情我较真了,是觉得很值得较的。

泛泛的讲,重构是随时随地的,不需要分场合。
而楼主文章所言是比较正式、系统的,有计划有目标的去做重构,所谓文不对题。


13 楼 sg552 2008-03-10  
Godlikeme 写道
V8,V9是软件厂商的产品,遗留系统系统是属于客户的。
产品爱怎么搞怎么搞,这叫产品的重构,不叫遗留系统的重构。

文章我看的比较仔细,也明白想说什么,重构也是2年前的读物了
可如果标题本身存在概念理解上的偏差似乎让整个文章读起来不是那么回事


我记得《重构》是99年就出版的,03年中文版第一次印刷。

个人以为,在文字上较真没意义,能为企业和用户带来好处就是好的。

顺便感一小慨,参与过的几个大中型规模项目,没见过几个TestCase,更别说
Refactoring的痕迹了。等下专门做个帖子说说。呵呵。

12 楼 gigix 2008-03-09  
Godlikeme 写道
V8,V9是软件厂商的产品,遗留系统系统是属于客户的。
产品爱怎么搞怎么搞,这叫产品的重构,不叫遗留系统的重构。

文章我看的比较仔细,也明白想说什么,重构也是2年前的读物了。
可如果标题本身存在概念理解上的偏差似乎让整个文章读起来不是那么回事。

Well...如果你一定要这样说也行
但你也说了,使用者会需要对遗留系统做升级改造
那么总有一些人要来判断,升级改造带来的商业价值有多少,为此付出的成本有多少
如果技术成本太高那么就必须重构
那么你的疑问到底是什么呢?
11 楼 Godlikeme 2008-03-09  
V8,V9是软件厂商的产品,遗留系统系统是属于客户的。
产品爱怎么搞怎么搞,这叫产品的重构,不叫遗留系统的重构。

文章我看的比较仔细,也明白想说什么,重构也是2年前的读物了。
可如果标题本身存在概念理解上的偏差似乎让整个文章读起来不是那么回事
10 楼 Godlikeme 2008-03-09  
发重复了。
9 楼 gigix 2008-03-09  
Godlikeme 写道
这正是我质疑之处。
遗留系统的概念的隐含主语是指 使用者。

我不明白
使用者在乎的是,V9版本需要花多少钱来买,提供多少V8版本没有的功能
我从来没有听过使用者说什么“遗留系统”
8 楼 Godlikeme 2008-03-09  
这正是我质疑之处。
遗留系统的概念的隐含主语是指 使用者。
7 楼 gigix 2008-03-09  
Godlikeme 写道
遗留系统不会需要重构,这是一个违命题。
遗留系统是对最终用户来讲,正在使用的部分或全部功能的系统。
对于一个正在使用的系统,客户根本不会去考虑重构的问题,
即使有升级,改造的事情也是 注重新增业务功能,性能改造,不能称为重构。
作为使用者,系统稳定是大前提,不会在没有功能、性能、健壮性、可用性要求下去修改系统。

重构只能说是某个产品研发的某个阶段的某部分工作,对于产品的梳理,改造,
是有意义的。
这是一个产品所有者需要考虑的问题,而不是产品使用者需要考虑的问题。

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

软件组织(或者说“产品所有者”)要做什么,这从来都不是“产品使用者”需要考虑的问题。从商业的角度,用户只要能达成他的业务价值,他才不关心你怎么弄出一个软件甚至是不是弄出一个软件来呢。
6 楼 Godlikeme 2008-03-08  
遗留系统不会需要重构,这是一个违命题。
遗留系统是对最终用户来讲,正在使用的部分或全部功能的系统。
对于一个正在使用的系统,客户根本不会去考虑重构的问题,
即使有升级,改造的事情也是 注重新增业务功能,性能改造,不能称为重构。
作为使用者,系统稳定是大前提,不会在没有功能、性能、健壮性、可用性要求下去修改系统。

重构只能说是某个产品研发的某个阶段的某部分工作,对于产品的梳理,改造,
是有意义的。
这是一个产品所有者需要考虑的问题,而不是产品使用者需要考虑的问题。
5 楼 jimmy_c 2008-03-07  
引用
一个class,一个jsp,几千行的代码,居然做出来功能都是对的,实在是太佩服了。

一两万的偶也见过。

引用
我们的要求是1:提高响应速度2:增加和修改几个业务模块3:修改用户登录,权限模块4:重整UI5:合并另外一个系统的部分功能,等等

貌似你所说的都是功能需求,而非重构。
4 楼 welllove53 2008-03-06  
我觉得产品重构这个是个技术活,要用最小的成本达到最大的效果。
一定要记住你重构的目的,不要做过多的事情。
我以前做过一个以前很烂的产品的重构,技术架构就不说了,代码简直惨目人堵,一个class,一个jsp,几千行的代码,居然做出来功能都是对的,实在是太佩服了。
我们的要求是1:提高响应速度2:增加和修改几个业务模块3:修改用户登录,权限模块4:重整UI5:合并另外一个系统的部分功能,等等

相关推荐

    云原生背景下的系统重构.pdf

    - **微服务改造**:为遗留系统创建API,逐步构建新系统,直至旧系统被取代。 - **DevOps实践**:推动开发运营一体化,采用持续交付,优化项目管理和团队组织。 - **平台运营团队**:打造平台运营团队,为业务团队...

    重构 _改善既有代码的设计(中文版) pdf

    这种做法对于维护历史遗留系统尤为重要,因为在长期的项目中,代码库往往会变得复杂且难以理解。重构可以减小系统复杂性,为未来可能的变更提供更坚实的基础。书中介绍了超过70种重构方法,每种方法都包括了应用重构...

    浅议.NET遗留应用改造.doc

    棕地项目则涉及到在现有(遗留)系统上进行开发,需要考虑与现有系统集成和共存,这通常更复杂,但也有助于利用现有资源和经验。 3. **绿地项目开发**的优势在于创新空间大,但可能缺乏明确的方向和商业模式,需要...

    Re-Engineering Legacy Software

    - **复杂的业务逻辑**:经过多年的维护和发展,遗留系统的业务逻辑可能变得非常复杂,这使得对其进行更改或重构变得更加困难。 - **缺乏测试覆盖**:许多遗留系统可能没有或只有很少的自动化测试,这增加了修改...

    lidando-com-legado:介绍处理遗留系统和代码的方法

    此外,培训团队对遗留系统的理解和技能提升也是必不可少的。组织内部研讨会,分享遗留代码的最佳实践和处理经验,鼓励团队成员积极参与遗留系统的改造工作,以提高整体技术水平和团队协作能力。 最后,制定长远的...

    BattleShip-Refactoring:软件设计和架构,重构项目(截止日期 01.12.2015)。 如果您要完全重构一个类,请将其标记为绿色,以免进一步考虑

    本项目"BattleShip-Refactoring"专注于通过重构提升软件设计和架构的质量,其截止日期设定为2015年12月1日,表明这是一个时间紧迫的任务,要求开发者在有限的时间内对现有代码进行深度优化。 在Java编程语言中,...

    Thinking of Digital Transformation

    首先是评估现有遗留系统对业务的价值,确定哪些系统是必须保留和改进的。其次,制定清晰的现代化目标和路线图,确保转型过程与企业的整体战略相匹配。然后,选择合适的技术和方法,进行逐步的迁移和优化。最后,确保...

    Application Modernization

    应用现代化是IT行业的一个重要领域,专注于将旧的、传统的系统或应用程序更新为更...正确地实施现代化不仅能延长遗留系统的使用寿命,而且可以为企业带来新的竞争优势,使企业能够更好地适应不断变化的市场和技术环境。

    希赛软考学院系统分析师考试辅导与培训_新技术应用资料

    商业价值评价考虑遗留系统对公司业务的影响,以及替换或升级它的成本效益分析。 ##### 2.3 外部环境评价 外部环境评价考虑了市场竞争、技术趋势等因素对遗留系统的影响。 ##### 2.4 应用软件评价 应用软件评价关注...

    软件系统架构师(电子书)

    7. **架构演进与重构**:随着业务发展,系统可能会出现遗留问题或需要适应新的技术趋势。书中会讲解如何进行架构重构,以及如何平滑地进行系统升级和迁移。 8. **团队协作与沟通**:架构师不仅要懂技术,还要懂得与...

    Wrox-Professional.Refactoring.in.Visual.Basic[www.TopSage.com].pdf

    3. **大规模代码组织**(Chapter 13):探讨了如何在大型项目中进行有效的代码组织和重构,这对于维护大型软件系统尤为重要。 #### 知识点五:重构的实际应用与新技术的结合 第五部分重点讲述了重构在实际项目中的...

    福瑞博德---软件外包成熟解决方案.docx

    这些解决方案涵盖了金融服务应用系统、互联网电子商务解决方案、企业运营/管理系统、遗留系统迁移和 SOA 解决方案、IT 技术人才外派和管理等多个方面。 金融服务应用系统解决方案: * 国际标准化现金/转账管理系统...

    Manning.Brownfield.Application.Development.in.NET.Mar.2010.rar

    8. **遗留系统集成**:在许多情况下,Brownfield项目需要与旧有的系统或服务集成。书中可能会讨论如何处理这些接口,确保新代码与旧系统的兼容性。 9. **决策与风险管理**:书中会强调在进行Brownfield开发时做出...

    修改代码艺术(Working Effectively with Legacy Code)

    遗留代码通常指的是那些没有适当维护,或者设计和文档不完整的项目。处理这些代码时,开发者往往需要小心翼翼,以防止引入新的错误或破坏现有功能。 书中涵盖了以下几个关键知识点: 1. **理解代码结构**:...

    maven 逆向逆向工程

    总之,Maven逆向工程是解决遗留系统问题和提升项目可维护性的有力工具,通过合理利用相关工具和技术,开发者可以有效地将无源码项目转换为符合Maven规范的现代开发结构。然而,这也需要开发者具备一定的Maven知识和...

Global site tag (gtag.js) - Google Analytics