|
锁定老帖子 主题：重构，是否适合“当前”开发模式？
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-06-20
treblesoftware 写道 luckaway 写道 被编码是时打断，重构也算是一种编码！！！
重构是是一种技能！ 并不是因为重构而重构，重构的目的是为了让软件变的可扩展、可维护！ 在框架内，一个功能写一个模块实现，而且分层很严格。突然觉得就算需求变动了，改起来也挺方便。所以才产生了这样的疑问。谢谢您的回帖。  每个功能模块都有DRUP操作,像你说的,这样下去不就有了code smell,如果修改一个地方就全得跟着改,你认为不需要重构吗.不是有了SSH,严格分层了就不需要重构了. |
| 返回顶楼 | |
|
发表时间：2009-06-22
最后修改：2009-06-22
我想 重构不是目的， 而是方法。
重构是不可避免的。 重构的前提，是可测试性。 而 重构 这本书，是如何实现＂可测试性＂。 你不可能 很简单的把一个没有提前考虑可测试性 的项目，变成可以 方便的重构的。 所以本书 从最最 原始的例子开始， 告诉你 如何去实现一个可测试性的项目，有了这个前提， 才有了可重构的项目. 重构 给出的例子 是太简单的例子， 他是说明对于很初级的程序员，也能够很好的运用TDD。我想MF 的意思不是让大家都按照这个顺序来设计项目。 他是例子来说明一个思想。 因此最后总结一下: 重构不是目的， 而是方法。 重构不仅是一个方法， 更重要的是一个思想， 或者说思维方式。 |
| 返回顶楼 | |
|
发表时间：2009-06-22
treblesoftware 写道 当我在读MF的《重构》时产生了这样的疑问。它是否适合？
这里为了减少争议，我说明一些大概的细节。一个系统在SPRING+STRUTS2+HBIERBATE下，在框架的范围内开发。严格的分层，各层之间使用IOC进行解偶，而且，每一个功能，写一个模块。而且，各各模块之间相对独立，没有父类，子类。最多只是引用一些公共包中的方法（比如：取得当前时间，等等）。在这样的情况下，我感觉使用重构的意义不大，如果为了重构而重构，明显会降低编码的速度和效率。因为我在编码时被打断会显的非常不爽，更别说在编码中进行TDD了。 不知道大家怎么看这个问题。请大家在文章范围内讨论，勿夸出范围，谢谢。  我又仔细的看了一次的主贴....... 你说的 一个功能一个模块..... 是公司规定 是不利于重构的规定之一. 当你的代码中有很强大的逻辑关系时 很多很严格的条件约束时 你会发现 你的代码很难修正 所以我常在不维反公司规定的条件下 把尽量重复 的代码 推到对应的 bean (Entity)中,让这个bean 除了set get 再多些能力 如果是个更公用的方法就推到tools中去 还有大的entity 拆成多个bean 可以更好的减少代码. 还有很多很多方式 并不一定要把重构里所有的条件作到100% 要把你的代码作的更好.... 至少要比重构之前好点吧. 读过写过上千行的一个方法后再回来讨论重构会更有意义的多. |
| 返回顶楼 | |
|
发表时间：2009-06-22
抛出异常的爱 写道 读过写过上千行的一个方法后再回来讨论重构会更有意义的多.
同意。没有经过病痛的折磨，是不会理解保健的重要性的。 |
| 返回顶楼 | |
|
发表时间：2009-06-22
palmer 写道 我想 重构不是目的， 而是方法。
重构是不可避免的。 重构的前提，是可测试性。 而 重构 这本书，是如何实现＂可测试性＂。 你不可能 很简单的把一个没有提前考虑可测试性 的项目，变成可以 方便的重构的。 所以本书 从最最 原始的例子开始， 告诉你 如何去实现一个可测试性的项目，有了这个前提， 才有了可重构的项目. 重构 给出的例子 是太简单的例子， 他是说明对于很初级的程序员，也能够很好的运用TDD。我想MF 的意思不是让大家都按照这个顺序来设计项目。 他是例子来说明一个思想。 因此最后总结一下: 重构不是目的， 而是方法。 重构不仅是一个方法， 更重要的是一个思想， 或者说思维方式。 您的总结很好，谢谢了。
|
| 返回顶楼 | |
|
发表时间：2009-06-22
抛出异常的爱 写道 treblesoftware 写道 当我在读MF的《重构》时产生了这样的疑问。它是否适合？
这里为了减少争议，我说明一些大概的细节。一个系统在SPRING+STRUTS2+HBIERBATE下，在框架的范围内开发。严格的分层，各层之间使用IOC进行解偶，而且，每一个功能，写一个模块。而且，各各模块之间相对独立，没有父类，子类。最多只是引用一些公共包中的方法（比如：取得当前时间，等等）。在这样的情况下，我感觉使用重构的意义不大，如果为了重构而重构，明显会降低编码的速度和效率。因为我在编码时被打断会显的非常不爽，更别说在编码中进行TDD了。 不知道大家怎么看这个问题。请大家在文章范围内讨论，勿夸出范围，谢谢。 我又仔细的看了一次的主贴....... 你说的 一个功能一个模块..... 是公司规定 是不利于重构的规定之一. 当你的代码中有很强大的逻辑关系时 很多很严格的条件约束时 你会发现 你的代码很难修正 所以我常在不维反公司规定的条件下 把尽量重复 的代码 推到对应的 bean (Entity)中,让这个bean 除了set get 再多些能力 如果是个更公用的方法就推到tools中去 还有大的entity 拆成多个bean 可以更好的减少代码. 还有很多很多方式 并不一定要把重构里所有的条件作到100% 要把你的代码作的更好.... 至少要比重构之前好点吧. 读过写过上千行的一个方法后再回来讨论重构会更有意义的多. 谢谢您用心的解答。您的方法有点OO的感觉，跟我说的那种“一个功能一个模块”有些不同，不过您的方法的确是个好方法 谢谢。
|
| 返回顶楼 | |
|
发表时间：2009-06-23
重构
你接手了一个项目，或者模块，看见一堆想杀人的代码，在可预计的时间范围内你将会多次被拖入这个坑 于是重构之，即便不是为了让别人不死，至少自己不能死 |
| 返回顶楼 | |
