- 论坛徽章:
- 0
|
【转载】Keeping Software Soft (Martin Fowler)
>;如果需求变化很大
>;以致整个系统都要重写时
>;那么事实是是开始一个新项目了
Refactoring 也不是万能的，这种情况得比较一下 Refactoring 和重写的成本
如果 Refactoring 的成本更高，就重写吧。
>;所以重构只是重组织以前的对象
>;让他们更合理
>;或是对一小部分编写得不合理的对象重写
>;而不应该是全盘推倒重来
说得对，每次的重构只是对系统的一部分进行的。
>;大系统中对象的关联很多
>;重构时必须考虑其它对象的影响
>;所以我认为重构并不适合大系统
>;你可以进行局部的修改,或是模块内的修改
>;但是对整个系统的全局修改那要问问经理是不是同意了
良好的设计应该做到：如果增加一个新的功能，系统需要改动的地方应该最少
这可以由两个方法做到：
早期的设计考虑到了将来的变化
早起的设计没有考虑到这个变化，但可以用重构使系统的结构适合这点
>;另外重构需要花时间与人员
>;所以只是不得已时而为之
不同意。
重构的结果是：程序更容易理解，更容易面对变化，每次加入新的功能都只需要改动很少数的地方，
这样可以减少理解系统，增加新功能的时间，使项目能以恒定的速度加入新的功能
而不是象以前的项目，开发越来越慢，最后加入一个新功能会导致系统的太多地方的改变而不得不
减慢开发速度，甚至完全重新系统
>;每个项目都有自己的预算与经费
>;经常重构, 系统的开发成本会更高
>;因此开始时应该尽量掌握客户需求而不是想等到后面客户提出需求时再重构
不同意。
重构不会引起开发成本的提高，反而会降低开发成本
正如文章里所说的，正是由于以往的开发（up-front design）害怕将来的需求改变
所以才出现你说的这种情况：
“希望开始时应该尽量掌握客户需求而不是想等到后面客户提出需求时再重构”
但是，开发人员和客户都是在系统开发的过程中对系统有不断深入的认识的
所以不可能指望一开始就掌握完整的需求，必须承认这点：需求永远使变化的。
究其根本，文中说道，是一个“want 和 cost 的问题”，是因为后期的需求改变
所带来的成本的增加太多了，你的推断是基于这个前提。
但是由于有了 Refactoring，有了完备的测试，有了良好的设计，使 want 和 cost
的关系发生了很大的变化，后期需求的改变并不会引起太多的成本增加。
这就是 xp 里所说的勇气：有了测试，refactoring，频繁的发布，我们需要做的只是
努力做好今天的事情，我们并不害怕将来的需求的变化。
Martin Fowler 为 Refactoring 专门写了一本书：
Refactoring: Improving the Design of Existing Code
在中国刚出影印版：
http://www.china-pub.com/computers/common/info.asp?id=12301
可以去看看。
：） |
|
免费注册
发表于 2003-06-25 16:47
