＋设为首页 ＋添加到收藏夹
表示层与entity的绑定,entity的持久化,各层之间传递数据的方式,缓存对象之间的依赖关系,对象之间的协作,统一的安全控制的错误处理.配置信息的管理,unit test.
如果不是看了文章的标题,我想我会很容易的接受,并将其放入收藏夹.我不相信像作者这样有经验的人会犯文不对题的问题,所以我又仔仔细细将文章看了一遍,似乎也看出一点东西,但对于重构,作者确实是用笔太少. 【程序编程相关:CodePlus将要推出新版了：）列举一】
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 【推荐阅读:Java技巧：列表排序】
先让我们看看«重构»的作者是怎么定义重构的:“在不改变代码外在行为的前提下对代码做出修改,以改进代码的内部结构的过程.”请注意,重构是在不改变外在行为的优化.这就像人身上脏了要洗澡一样,是频繁.小度量的工作步骤.如果在前几次的迭代中还不能激发变化,我们就需要考虑度的把握,不要奢望在项目后期进行系统级的重构,它的代价太大了.如果你的改动将影响整个系统,那你只能想别的办法补救,所以,放弃重构吧,至少在当前这个可运行的版本中. 【扩展信息:使用WMI来得到系统的服务】
让我们按照作者的思路来考虑这个问题,由于成本.时间等多面因素,我们不可能对一切变化做出准备,尽管有很多办法可以帮助我们刺激变化,及时发现潜在的变化,但难免的,在项目后期,我们还是会面临需求变更的危机,如果这个变化是我们所未预料的,并且牵一发动全身,那么,这种情况下,我们是否需要重构?
就像作者说的work,right,best一样,重构的前提是代码可以正常工作,目的是让代码更好的工作的.所以更多时候,我会把设计看作系统级的,把重构看作代码级,它们是两个阶段的两种工作,不能混为一团.
重构不是万能的,不要依赖于重构,也不要夸大了重构的功用,在很多时候,它并不能改善你设计上的缺陷.