|
锁定老帖子 主题：重构，是否适合“当前”开发模式？
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-04-22
重构好痛苦
|
| 返回顶楼 | |
|
发表时间：2009-04-22
Saito 写道 从楼主的帖子中看出. 并没有提到 单元测试. 重构能够得以进行. 就是要有类似于这种测试框架的支持. 要不然. 重构是危险的. 没有保障的.
当然. 更进一步的来说. 我们应该用TDD 来进行开发.并随时重构自己的程序. SSH为什么会那么能受大众喜欢. 有一个原因就是 他们易于测试. 这就易于重构我们的业务逻辑. 让我们的逻辑更加清晰. 更容易复用. 即使转手自己的工作. 别人也能只读我们的单元测试框架内的测试代码. 就能知道我们在做什么. 说白了. 我觉得我们是在挖井. 现在挖的过程是痛苦的. 等到一天业务发生改变. 就是你吃水的时候了. 有时候这样想. TDD + 重构有时候确实很难在公司. 企业内实行. 我觉得有一个原因就是我们程序员都有点急功近利. 说白了就是浮躁.( 当然包括我.) 觉得重构代码是件浪费时间的事. ( 这也包括我.) .就跟我们编码很少去想到 防御式编程是一样的. bug多多.唯完成功能是论. (这说的就是我.) .kent beck .martin fowler这种大师都在他的工具箱里有 重构 有 Junit . 我觉得我们更该有.. 再说了. 重构是需要经验的.不是看refactory就能学会的. 现在不去做. 什么时候去做? 趁现在还在学校. 把 TDD +refactory 装进自己的工具箱吧.. 当然 我是准备这么做了.. 支持！不过现在我做的项目都是在开发中变动需求，而需求变动不大，没有麻烦到非要refactory 不可。我只是最近看了refactorying这本书，对当前形式下的开发模式产生了一些疑问。想和大家讨论一下。以决定我是否需要花这个时间去啃这本书。不过就目前来看，是应该好好的啃一啃了。谢谢您的回帖和建议。 
|
| 返回顶楼 | |
|
发表时间：2009-04-22
yuan 写道 treblesoftware 写道 当我在读MF的《重构》时产生了这样的疑问。它是否适合？
这里为了减少争议，我说明一些大概的细节。一个系统在SPRING+STRUTS2+HBIERBATE下，在框架的范围内开发。严格的分层，各层之间使用IOC进行解偶，而且，每一个功能，写一个模块。而且，各各模块之间相对独立，没有父类，子类。最多只是引用一些公共包中的方法（比如：取得当前时间，等等）。在这样的情况下，我感觉使用重构的意义不大，如果为了重构而重构，明显会降低编码的速度和效率。因为我在编码时被打断会显的非常不爽，更别说在编码中进行TDD了。 不知道大家怎么看这个问题。请大家在文章范围内讨论，勿夸出范围，谢谢。  重构是在以不改变代码外在行为为前提的情况下，改善代码的内部结构。 好吧，我特意翻了一下重构这本书，Fowler说： page i 重构一词非常清楚地说明了它自身的意义和价值：在不破坏可察功能的前提下，借由搬移、提炼、打散、凝聚…，改善事物的体质。 page xvi 所谓重构是这样一个过程：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。 简单的想：既然这两句定义这么强调“不改变代码外在行为”，那我觉得无论在什么情况下，重构都是可以进行的吧。 怀疑有很大的成分是被“重构”这个词给迷糊了。汉语中“重构”似乎更像一切推倒从来。但是Fowler的解释似乎与此格格不入，呵呵。 |
| 返回顶楼 | |
|
发表时间：2009-04-22
luckaway 写道 被编码是时打断，重构也算是一种编码！！！
重构是是一种技能！ 并不是因为重构而重构，重构的目的是为了让软件变的可扩展、可维护！ 在框架内，一个功能写一个模块实现，而且分层很严格。突然觉得就算需求变动了，改起来也挺方便。所以才产生了这样的疑问。谢谢您的回帖。 
|
| 返回顶楼 | |
|
发表时间：2009-04-22
我觉的代码重构是一件很幸福的事，很多公司还没有机会给你重构呢！
有时候代码写的很难于阅读同是有些东西很多地方用到，我就会想重构。 感觉重构是一种享受，感觉代码在自己手中一下子升华了! 最重要的是你这次写的一写东西抽象的好，下次还可以用，多省力啊，开发效率一下子就高起来了！你们说的重构那本书没看过，不过重构这件事我一直在做！ |
| 返回顶楼 | |
|
发表时间：2009-04-23
最后修改：2009-04-23
treblesoftware 写道 Saito 写道 从楼主的帖子中看出. 并没有提到 单元测试. 重构能够得以进行. 就是要有类似于这种测试框架的支持. 要不然. 重构是危险的. 没有保障的.
当然. 更进一步的来说. 我们应该用TDD 来进行开发.并随时重构自己的程序. SSH为什么会那么能受大众喜欢. 有一个原因就是 他们易于测试. 这就易于重构我们的业务逻辑. 让我们的逻辑更加清晰. 更容易复用. 即使转手自己的工作. 别人也能只读我们的单元测试框架内的测试代码. 就能知道我们在做什么. 说白了. 我觉得我们是在挖井. 现在挖的过程是痛苦的. 等到一天业务发生改变. 就是你吃水的时候了. 有时候这样想. TDD + 重构有时候确实很难在公司. 企业内实行. 我觉得有一个原因就是我们程序员都有点急功近利. 说白了就是浮躁.( 当然包括我.) 觉得重构代码是件浪费时间的事. ( 这也包括我.) .就跟我们编码很少去想到 防御式编程是一样的. bug多多.唯完成功能是论. (这说的就是我.) .kent beck .martin fowler这种大师都在他的工具箱里有 重构 有 Junit . 我觉得我们更该有.. 再说了. 重构是需要经验的.不是看refactory就能学会的. 现在不去做. 什么时候去做? 趁现在还在学校. 把 TDD +refactory 装进自己的工具箱吧.. 当然 我是准备这么做了.. 支持！不过现在我做的项目都是在开发中变动需求，而需求变动不大，没有麻烦到非要refactory 不可。我只是最近看了refactorying这本书，对当前形式下的开发模式产生了一些疑问。想和大家讨论一下。以决定我是否需要花这个时间去啃这本书。不过就目前来看，是应该好好的啃一啃了。谢谢您的回帖和建议。 一个业务如果写在一个BO的方法中 要对14个变量进行判断,(其中数据库中有的字段占9个) 两次遍历.5百++以上的代码...... ......... 这样的业务需求在我作的项目中很多..... 这样的代码如果不重构的话....谁变更谁想死 另重构是指小幅度的改变设计.... 你的需求变更后 设计很有可能需要大幅的变化 先把需求作出来 再一点点的变化变量名 抽出,拉入,移动 等操作最后达到以前的设计重组的作用. 减少架构变更的冲击 |
| 返回顶楼 | |
|
发表时间：2009-04-23
重构是一种乐趣，就像把一个杂乱无章的房间收拾得井井有条一样，看着都是一种享受。如果你不能把写程序当成一种艺术来看，你就体会不到这种乐趣。
|
| 返回顶楼 | |
|
发表时间：2009-04-23
好多公司都不给时间重构,项目完成就抓紧上线验收收尾款了
|
| 返回顶楼 | |
|
发表时间：2009-04-23
treblesoftware 写道 各各模块之间相对独立，没有父类，子类。最多只是引用一些公共包中的方法（比如：取得当前时间，等等）。在这样的情况下，我感觉使用重构的意义不大，如果为了重构而重构，明显会降低编码的速度和效率。
这种情况下讨论重构有啥意义？如果业务很简单（curd）代码很规范还有人叫你去重构，那你就问他重构什么 |
| 返回顶楼 | |
|
发表时间：2009-04-23
logicgate 写道 重构是一种乐趣，就像把一个杂乱无章的房间收拾得井井有条一样，看着都是一种享受。如果你不能把写程序当成一种艺术来看，你就体会不到这种乐趣。
同感 |
| 返回顶楼 | |
