2008-02-28
对遗留系统组织重构项目
关键字: 重构
http://blog.csdn.net/gigix/archive/2008/02/25/2118896.aspx
引用
为了保留并最大化软件资产的价值，适应新的需求变更，老系统总会面对维护和升级。当维护和升级的困难达到一定程度时，很多IT组织就会决定投入一整块资源和时间来改善这些老系统的技术质量，以便将来的维护升级能顺利进行。这样的做法通常被称为"重构项目"。
根据我们的经验，很多重构项目在目标管理、任务划分和质量保证等方面存在比较严重的问题，这些问题导致重构项目不能充分发挥价值。
根据我们的经验，很多重构项目在目标管理、任务划分和质量保证等方面存在比较严重的问题，这些问题导致重构项目不能充分发挥价值。
- 10:26
- 浏览 (887)
- 论坛浏览 (3912)
- 评论 (22)
- 分类: 企业应用建筑师
- 相关推荐
评论
kaipingk@gmail.com
2008-04-02
回复
很有意义的事情，不过做起来的确相当难！尤其是表现层的东西，期待下文
Lucas Lee 写道
看了一下链接的帖子，明显就是TW的广告么。
并没有什么独特的内容。
并没有什么独特的内容。
没错，就是广告。
一个很简单的道理：遗留系统那么多，那么多经验丰富的技术主管们成天就在为这些系统头疼，如果只要一篇文章、一个“独特的点子”就能解决的话，他们怎么可能还解决不了？
巴菲特说他怎么赚钱的办法说起来也很简单。原则总是很简单的，简单不等于容易。士兵上战场的原则最简单了，让自己不被打死，尽量打死一点敌人。很简单，但一点都不容易。
遗留系统重构也是一样。原则就这么简单，我都可以写出来。但是谁真正能提供这种服务？我相信那些正在头疼的主管们乐于看到这样的广告。
Godlikeme 写道
这里问题的焦点不在于 什么叫重构，怎么做重构。
而是重构的对象，遗留系统。
真的有这种可能么？作为客户方的银行、电信、制造业 这样的系统使用者去发起重构。
书上都写了，为什么会觉得别人没有看，莫明其妙。
而lz文章里所讲只是一般的产品所有者在研发阶段所作大规模重构，为产品长期发展所作工作，麻烦不要混淆。
说到经验，那就请拿点实例出来，让大家了解一下。
而是重构的对象，遗留系统。
真的有这种可能么？作为客户方的银行、电信、制造业 这样的系统使用者去发起重构。
书上都写了，为什么会觉得别人没有看，莫明其妙。
而lz文章里所讲只是一般的产品所有者在研发阶段所作大规模重构，为产品长期发展所作工作，麻烦不要混淆。
说到经验，那就请拿点实例出来，让大家了解一下。
谁也没说是由使用者来发起的，你为什么有这个印象？
这里问题的焦点不在于 什么叫重构，怎么做重构。
而是重构的对象，遗留系统。
真的有这种可能么？作为客户方的银行、电信、制造业 这样的系统使用者去发起重构。
书上都写了，为什么会觉得别人没有看，莫明其妙。
而lz文章里所讲只是一般的产品所有者在研发阶段所作大规模重构，为产品长期发展所作工作，麻烦不要混淆。
说到经验，那就请拿点实例出来，让大家了解一下。
而是重构的对象，遗留系统。
真的有这种可能么？作为客户方的银行、电信、制造业 这样的系统使用者去发起重构。
书上都写了，为什么会觉得别人没有看，莫明其妙。
而lz文章里所讲只是一般的产品所有者在研发阶段所作大规模重构，为产品长期发展所作工作，麻烦不要混淆。
说到经验，那就请拿点实例出来，让大家了解一下。
gigix 写道
有一些来自银行、电信、制造业之类很资深的信息主管看了这个文章以后告诉我们，他在很长的时间里以为这样的项目就没救了，没想到我们还有办法，虽然不是一针下去起死回生的灵丹妙药，至少能给他指出一条朝向逐渐改进的实际可行的路。这种事情，都是身在其中才知道有多疼，没有这种经验的人看看是没啥感觉的。
一个更完整的版本应该会在下期《程序员》杂志发表。
是的。看着那么多钱和人月的项目，就因为后期开发太麻烦，而推倒重新来，实在是太浪费了。
对遗留系统的重构我认为在国内很有前途。
gigix太能吊人胃口了……
希望下个文章能带个例子说明一下啊。
重构这东西，其实很简单：1. 简单化；2. 同义转换。只是没有写过大型软件，没有跌过跟头的人是很难体会到它的重要性和方法的。
这不昨天一个有经验的程序员，我告诉他他写的程序“很烂”，是一堆补丁组成的难以理解的程序，需要重构，可他却把每个补丁的由来给我讲一遍，并且说：我也不想这样。
重构更多的是习惯和信仰。随时随地地把你的代码写的更简单，让你的team读你的代码时感觉轻松一些，避免逻辑陷阱。前两天有个帖子谈团队精神，什么是“团队精神”？这就是团队精神。
这不昨天一个有经验的程序员，我告诉他他写的程序“很烂”，是一堆补丁组成的难以理解的程序，需要重构，可他却把每个补丁的由来给我讲一遍，并且说：我也不想这样。
重构更多的是习惯和信仰。随时随地地把你的代码写的更简单，让你的team读你的代码时感觉轻松一些，避免逻辑陷阱。前两天有个帖子谈团队精神，什么是“团队精神”？这就是团队精神。
sg552 写道
虽然很不起眼，但是第12章：大型重构 却确实存在的。小型重构只需要几分钟，
跑几次UnitTest，大型重构却需要数月甚至几年。
因此，对遗留系统进行重构，就是一个大型重构。文章和题目都是围绕重构这个核心。
文很对题。
我对这个文章很期待，因为国内的相关文章几乎没有。
跑几次UnitTest，大型重构却需要数月甚至几年。
因此，对遗留系统进行重构，就是一个大型重构。文章和题目都是围绕重构这个核心。
文很对题。
我对这个文章很期待，因为国内的相关文章几乎没有。
有一些来自银行、电信、制造业之类很资深的信息主管看了这个文章以后告诉我们，他在很长的时间里以为这样的项目就没救了，没想到我们还有办法，虽然不是一针下去起死回生的灵丹妙药，至少能给他指出一条朝向逐渐改进的实际可行的路。这种事情，都是身在其中才知道有多疼，没有这种经验的人看看是没啥感觉的。
一个更完整的版本应该会在下期《程序员》杂志发表。
Godlikeme 写道
个人05年买的英文原版，所以这样说。
这件事情我较真了，是觉得很值得较的。
泛泛的讲，重构是随时随地的，不需要分场合。
而楼主文章所言是比较正式、系统的，有计划有目标的去做重构，所谓文不对题。
这件事情我较真了，是觉得很值得较的。
泛泛的讲，重构是随时随地的，不需要分场合。
而楼主文章所言是比较正式、系统的，有计划有目标的去做重构，所谓文不对题。
我觉得你的研究精神不错。
不过你手上既然有《Refactoring》E文版，请翻开目录，看下第12章的标题。
是不是 "Big Refactorings, by Kent Beck and Martin Fowler"。
没错，重构一书前里绝大部分章节介绍的是细节重构，提取个函数，提取个方法，
简化条件表达式等等，只限于几行代码或几个类。
虽然很不起眼，但是第12章：大型重构 却确实存在的。小型重构只需要几分钟，
跑几次UnitTest，大型重构却需要数月甚至几年。
因此，对遗留系统进行重构，就是一个大型重构。文章和题目都是围绕重构这个核心。
文很对题。
我对这个文章很期待，因为国内的相关文章几乎没有。牛人没时间写，有时间的庸才又
写不出来。
非常期待这个文章，希望了解的更多。
个人05年买的英文原版，所以这样说。
这件事情我较真了，是觉得很值得较的。
泛泛的讲，重构是随时随地的，不需要分场合。
而楼主文章所言是比较正式、系统的，有计划有目标的去做重构，所谓文不对题。
这件事情我较真了，是觉得很值得较的。
泛泛的讲，重构是随时随地的，不需要分场合。
而楼主文章所言是比较正式、系统的，有计划有目标的去做重构，所谓文不对题。
Godlikeme 写道
V8，V9是软件厂商的产品，遗留系统系统是属于客户的。
产品爱怎么搞怎么搞，这叫产品的重构，不叫遗留系统的重构。
文章我看的比较仔细，也明白想说什么，重构也是2年前的读物了。
可如果标题本身存在概念理解上的偏差似乎让整个文章读起来不是那么回事
产品爱怎么搞怎么搞，这叫产品的重构，不叫遗留系统的重构。
文章我看的比较仔细，也明白想说什么，重构也是2年前的读物了。
可如果标题本身存在概念理解上的偏差似乎让整个文章读起来不是那么回事
我记得《重构》是99年就出版的，03年中文版第一次印刷。
个人以为，在文字上较真没意义，能为企业和用户带来好处就是好的。
顺便感一小慨，参与过的几个大中型规模项目，没见过几个TestCase，更别说
Refactoring的痕迹了。等下专门做个帖子说说。呵呵。
Godlikeme 写道
V8，V9是软件厂商的产品，遗留系统系统是属于客户的。
产品爱怎么搞怎么搞，这叫产品的重构，不叫遗留系统的重构。
文章我看的比较仔细，也明白想说什么，重构也是2年前的读物了。
可如果标题本身存在概念理解上的偏差似乎让整个文章读起来不是那么回事。
产品爱怎么搞怎么搞，这叫产品的重构，不叫遗留系统的重构。
文章我看的比较仔细，也明白想说什么，重构也是2年前的读物了。
可如果标题本身存在概念理解上的偏差似乎让整个文章读起来不是那么回事。
Well...如果你一定要这样说也行
但你也说了，使用者会需要对遗留系统做升级改造
那么总有一些人要来判断，升级改造带来的商业价值有多少，为此付出的成本有多少
如果技术成本太高那么就必须重构
那么你的疑问到底是什么呢？
V8，V9是软件厂商的产品，遗留系统系统是属于客户的。
产品爱怎么搞怎么搞，这叫产品的重构，不叫遗留系统的重构。
文章我看的比较仔细，也明白想说什么，重构也是2年前的读物了。
可如果标题本身存在概念理解上的偏差似乎让整个文章读起来不是那么回事
产品爱怎么搞怎么搞，这叫产品的重构，不叫遗留系统的重构。
文章我看的比较仔细，也明白想说什么，重构也是2年前的读物了。
可如果标题本身存在概念理解上的偏差似乎让整个文章读起来不是那么回事
Godlikeme 写道
这正是我质疑之处。
遗留系统的概念的隐含主语是指 使用者。
遗留系统的概念的隐含主语是指 使用者。
我不明白
使用者在乎的是，V9版本需要花多少钱来买，提供多少V8版本没有的功能
我从来没有听过使用者说什么“遗留系统”
Godlikeme 写道
遗留系统不会需要重构，这是一个违命题。
遗留系统是对最终用户来讲，正在使用的部分或全部功能的系统。
对于一个正在使用的系统，客户根本不会去考虑重构的问题，
即使有升级，改造的事情也是 注重新增业务功能，性能改造，不能称为重构。
作为使用者，系统稳定是大前提，不会在没有功能、性能、健壮性、可用性要求下去修改系统。
重构只能说是某个产品研发的某个阶段的某部分工作，对于产品的梳理，改造，
是有意义的。
这是一个产品所有者需要考虑的问题，而不是产品使用者需要考虑的问题。
遗留系统是对最终用户来讲，正在使用的部分或全部功能的系统。
对于一个正在使用的系统，客户根本不会去考虑重构的问题，
即使有升级，改造的事情也是 注重新增业务功能，性能改造，不能称为重构。
作为使用者，系统稳定是大前提，不会在没有功能、性能、健壮性、可用性要求下去修改系统。
重构只能说是某个产品研发的某个阶段的某部分工作，对于产品的梳理，改造，
是有意义的。
这是一个产品所有者需要考虑的问题，而不是产品使用者需要考虑的问题。
麻烦先看我的文章
引用
软件的质量体现在两方面：商业方面的质量，以及技术方面的质量。从商业的角度看来，“成功的软件”意味着它所创造的价值超出在它身上付出的代价。从技术的角度看来，“成功的软件”意味着所有测试都通过、代码结构良好、并且容易理解和维护。很多商业上非常成功的软件系统忽视了技术方面的质量，所以尽管它们仍然在为IT组织创造价值，但对它们的维护和升级越来越困难。最终技术质量的欠缺会反过来阻碍软件系统创造更大的商业价值。
软件组织（或者说“产品所有者”）要做什么，这从来都不是“产品使用者”需要考虑的问题。从商业的角度，用户只要能达成他的业务价值，他才不关心你怎么弄出一个软件甚至是不是弄出一个软件来呢。
遗留系统不会需要重构，这是一个违命题。
遗留系统是对最终用户来讲，正在使用的部分或全部功能的系统。
对于一个正在使用的系统，客户根本不会去考虑重构的问题，
即使有升级，改造的事情也是 注重新增业务功能，性能改造，不能称为重构。
作为使用者，系统稳定是大前提，不会在没有功能、性能、健壮性、可用性要求下去修改系统。
重构只能说是某个产品研发的某个阶段的某部分工作，对于产品的梳理，改造，
是有意义的。
这是一个产品所有者需要考虑的问题，而不是产品使用者需要考虑的问题。
遗留系统是对最终用户来讲，正在使用的部分或全部功能的系统。
对于一个正在使用的系统，客户根本不会去考虑重构的问题，
即使有升级，改造的事情也是 注重新增业务功能，性能改造，不能称为重构。
作为使用者，系统稳定是大前提，不会在没有功能、性能、健壮性、可用性要求下去修改系统。
重构只能说是某个产品研发的某个阶段的某部分工作，对于产品的梳理，改造，
是有意义的。
这是一个产品所有者需要考虑的问题，而不是产品使用者需要考虑的问题。
引用
一个class，一个jsp，几千行的代码，居然做出来功能都是对的，实在是太佩服了。
一两万的偶也见过。
引用
我们的要求是1：提高响应速度2：增加和修改几个业务模块3：修改用户登录，权限模块4：重整UI5：合并另外一个系统的部分功能，等等
貌似你所说的都是功能需求，而非重构。
welllove53
2008-03-06
回复
我觉得产品重构这个是个技术活，要用最小的成本达到最大的效果。
一定要记住你重构的目的，不要做过多的事情。
我以前做过一个以前很烂的产品的重构，技术架构就不说了，代码简直惨目人堵，一个class，一个jsp，几千行的代码，居然做出来功能都是对的，实在是太佩服了。
我们的要求是1：提高响应速度2：增加和修改几个业务模块3：修改用户登录，权限模块4：重整UI5：合并另外一个系统的部分功能，等等
一定要记住你重构的目的，不要做过多的事情。
我以前做过一个以前很烂的产品的重构，技术架构就不说了，代码简直惨目人堵，一个class，一个jsp，几千行的代码，居然做出来功能都是对的，实在是太佩服了。
我们的要求是1：提高响应速度2：增加和修改几个业务模块3：修改用户登录，权限模块4：重整UI5：合并另外一个系统的部分功能，等等
gigix
评论排行榜