对遗留系统组织重构项目

发重复了。

V8，V9是软件厂商的产品，遗留系统系统是属于客户的。
产品爱怎么搞怎么搞，这叫产品的重构，不叫遗留系统的重构。

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

Well...如果你一定要这样说也行
但你也说了，使用者会需要对遗留系统做升级改造
那么总有一些人要来判断，升级改造带来的商业价值有多少，为此付出的成本有多少
如果技术成本太高那么就必须重构
那么你的疑问到底是什么呢？

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

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

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

个人05年买的英文原版，所以这样说。

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

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

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

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

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

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

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

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

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

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

重构这东西，其实很简单：1. 简单化；2. 同义转换。只是没有写过大型软件，没有跌过跟头的人是很难体会到它的重要性和方法的。
这不昨天一个有经验的程序员，我告诉他他写的程序“很烂”，是一堆补丁组成的难以理解的程序，需要重构，可他却把每个补丁的由来给我讲一遍，并且说：我也不想这样。
重构更多的是习惯和信仰。随时随地地把你的代码写的更简单，让你的team读你的代码时感觉轻松一些，避免逻辑陷阱。前两天有个帖子谈团队精神，什么是“团队精神”？这就是团队精神。

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

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

这里问题的焦点不在于 什么叫重构，怎么做重构。
而是重构的对象，遗留系统。
真的有这种可能么？作为客户方的银行、电信、制造业 这样的系统使用者去发起重构。

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

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

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