|
锁定老帖子 主题：对遗留系统组织重构项目
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-02-28
http://blog.csdn.net/gigix/archive/2008/02/25/2118896.aspx
引用 为了保留并最大化软件资产的价值，适应新的需求变更，老系统总会面对维护和升级。当维护和升级的困难达到一定程度时，很多IT组织就会决定投入一整块资源和时间来改善这些老系统的技术质量，以便将来的维护升级能顺利进行。这样的做法通常被称为"重构项目"。
根据我们的经验，很多重构项目在目标管理、任务划分和质量保证等方面存在比较严重的问题，这些问题导致重构项目不能充分发挥价值。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2008-03-04
我现在就面临这个问题，要将以前的四个系统合并为一个全新的系统
|
| 返回顶楼 | |
|
发表时间：2008-03-04
广告？广告？广告？
|
| 返回顶楼 | |
|
发表时间：2008-03-04
我们正在准备启动这么一个项目，曰：升级改造，好在系统的技术框架啥的都不会变，只是用户群扩大了。
|
| 返回顶楼 | |
|
发表时间：2008-03-06
我觉得产品重构这个是个技术活，要用最小的成本达到最大的效果。
一定要记住你重构的目的，不要做过多的事情。 我以前做过一个以前很烂的产品的重构，技术架构就不说了，代码简直惨目人堵，一个class，一个jsp，几千行的代码，居然做出来功能都是对的，实在是太佩服了。 我们的要求是1：提高响应速度2：增加和修改几个业务模块3：修改用户登录，权限模块4：重整UI5：合并另外一个系统的部分功能，等等 |
| 返回顶楼 | |
|
发表时间：2008-03-07
引用 一个class，一个jsp，几千行的代码，居然做出来功能都是对的，实在是太佩服了。
一两万的偶也见过。 引用 我们的要求是1：提高响应速度2：增加和修改几个业务模块3：修改用户登录，权限模块4：重整UI5：合并另外一个系统的部分功能，等等
貌似你所说的都是功能需求，而非重构。 |
| 返回顶楼 | |
|
发表时间：2008-03-08
遗留系统不会需要重构，这是一个违命题。
遗留系统是对最终用户来讲，正在使用的部分或全部功能的系统。 对于一个正在使用的系统，客户根本不会去考虑重构的问题， 即使有升级，改造的事情也是 注重新增业务功能，性能改造，不能称为重构。 作为使用者，系统稳定是大前提，不会在没有功能、性能、健壮性、可用性要求下去修改系统。 重构只能说是某个产品研发的某个阶段的某部分工作，对于产品的梳理，改造， 是有意义的。 这是一个产品所有者需要考虑的问题，而不是产品使用者需要考虑的问题。 |
| 返回顶楼 | |
|
发表时间：2008-03-09
Godlikeme 写道 遗留系统不会需要重构，这是一个违命题。
遗留系统是对最终用户来讲，正在使用的部分或全部功能的系统。 对于一个正在使用的系统，客户根本不会去考虑重构的问题， 即使有升级，改造的事情也是 注重新增业务功能，性能改造，不能称为重构。 作为使用者，系统稳定是大前提，不会在没有功能、性能、健壮性、可用性要求下去修改系统。 重构只能说是某个产品研发的某个阶段的某部分工作，对于产品的梳理，改造， 是有意义的。 这是一个产品所有者需要考虑的问题，而不是产品使用者需要考虑的问题。 麻烦先看我的文章 引用 软件的质量体现在两方面：商业方面的质量，以及技术方面的质量。从商业的角度看来，“成功的软件”意味着它所创造的价值超出在它身上付出的代价。从技术的角度看来，“成功的软件”意味着所有测试都通过、代码结构良好、并且容易理解和维护。很多商业上非常成功的软件系统忽视了技术方面的质量，所以尽管它们仍然在为IT组织创造价值，但对它们的维护和升级越来越困难。最终技术质量的欠缺会反过来阻碍软件系统创造更大的商业价值。
软件组织（或者说“产品所有者”）要做什么，这从来都不是“产品使用者”需要考虑的问题。从商业的角度，用户只要能达成他的业务价值，他才不关心你怎么弄出一个软件甚至是不是弄出一个软件来呢。 |
| 返回顶楼 | |
|
发表时间：2008-03-09
这正是我质疑之处。
遗留系统的概念的隐含主语是指 使用者。 |
| 返回顶楼 | |
|
发表时间：2008-03-09
Godlikeme 写道 这正是我质疑之处。
遗留系统的概念的隐含主语是指 使用者。 我不明白 使用者在乎的是，V9版本需要花多少钱来买，提供多少V8版本没有的功能 我从来没有听过使用者说什么“遗留系统” |
| 返回顶楼 | |
