重构的几大重要特点

   1.定义：重构就是在不改变代码的业务逻辑基础上，而进行对代码中一些可读性差的代码进行修改，使得代码更加清晰、易懂、扩展性增强，这样可增强代码的可读性、可维护性。
   2.重构的节奏：测试、小修改、测试、小修改.
   3.重构的难题：数据库；修改接口；无法通过重构来完成!
   4.重构的目标：设计模式;
   5.重构的保证：测试。
   6.何时不该重构：在项目的末期不该去重构、在代码错误的情况下不该去重构。
   7.臭味条款：类过大、方法过长、大量的重复代码等等！臭味条款还有很多很多，就不一一写出来了。

评论

35 楼 tuti 2010-04-14  

突然想到 《编程之道》里面的一段话，很像是重构过程中的感觉。


"Technique?" said the programmer, turning from his terminal, "What I follow is the Tao -- beyond all technique. When I first began to program I would see before me the whole program in one mass. After three years I no longer saw this mass. Instead, I used subroutines. But now I see nothing. My whole being exists in a formless void. My senses are idle. My spirit, free to work without a plan, follows its own instinct. In short, my program writes itself. True, sometimes there are difficult problems. I see them coming, I slow down, I watch silently. Then I change a single line of code and the difficulties vanish like puffs of idle smoke. I then compile the program. I sit still and let the joy of the work fill my being. I close my eyes for a moment and then log off."

“技巧？”，大师转过身说，“我所遵循的是道--它超乎所有的技巧。当我开始编程时我看到的是整个一大块的程序，三年后我看到的是子过程。现在我什么也看不到了。我的整个存在是没有任何形式的虚无。我感觉很悠闲，总之，事实上是我的程序自己在写，有时我看到一些问题，我看到它们，就停下来静静地观察它们，然后我改变了一行代码，难题就象一阵轻烟一样化为乌有。然后我编译程序。坐在那里享受工作的喜悦。闭了一会眼睛然后退出系统。

34 楼 tuti 2010-04-14  

抛出异常的爱 写道

sg552 写道

我认为在重构方面，gigix是国内的TOP X。 起码作为一个译者，人家读书就翻来覆去读了多少遍了，而且经验丰富。

记得很久以前我也发过一个帖子，大意也是 先写单元测试，再重构。不过后来gigix一针见血的评价了我： IDE很容易自动做完的工作，反而我费那么大劲。

前些天看他的第二版序，我觉得更是说明了那个道理： 重构需要扎实的基本功。把步骤都记牢了，必定不会出错。而且只有难于理解（难于写单元测试）的程序，才需要重构。 如果你很容易的写出个单元测试，说明这个程序完全没想象的那么糟糕么。

老抛不要灰心啊。我现在已经脱离了IDE，捧着书每天人工重构呢。 一起加油啊。

重构的活这阵子没有了。。。。

再看一遍重构。。。
以前看的脑子里有个概念
但没到把所有的步骤背下来。

拳不离手，曲不离口

继续重构印度人的代码去了 ～～

33 楼 抛出异常的爱 2010-04-12  

sg552 写道

我认为在重构方面，gigix是国内的TOP X。 起码作为一个译者，人家读书就翻来覆去读了多少遍了，而且经验丰富。

记得很久以前我也发过一个帖子，大意也是 先写单元测试，再重构。不过后来gigix一针见血的评价了我： IDE很容易自动做完的工作，反而我费那么大劲。

前些天看他的第二版序，我觉得更是说明了那个道理： 重构需要扎实的基本功。把步骤都记牢了，必定不会出错。而且只有难于理解（难于写单元测试）的程序，才需要重构。 如果你很容易的写出个单元测试，说明这个程序完全没想象的那么糟糕么。

老抛不要灰心啊。我现在已经脱离了IDE，捧着书每天人工重构呢。 一起加油啊。

重构的活这阵子没有了。。。。

再看一遍重构。。。
以前看的脑子里有个概念
但没到把所有的步骤背下来。

32 楼 sg552 2010-04-12  

我认为在重构方面，gigix是国内的TOP X。 起码作为一个译者，人家读书就翻来覆去读了多少遍了，而且经验丰富。

记得很久以前我也发过一个帖子，大意也是 先写单元测试，再重构。不过后来gigix一针见血的评价了我： IDE很容易自动做完的工作，反而我费那么大劲。

前些天看他的第二版序，我觉得更是说明了那个道理： 重构需要扎实的基本功。把步骤都记牢了，必定不会出错。而且只有难于理解（难于写单元测试）的程序，才需要重构。 如果你很容易的写出个单元测试，说明这个程序完全没想象的那么糟糕么。

老抛不要灰心啊。我现在已经脱离了IDE，捧着书每天人工重构呢。 一起加油啊。

31 楼 tuti 2010-04-11  

seen
你看过<重构>这本书吗?实际工作中用过重构这种技术吗?

30 楼 seen 2010-04-11  

呵呵 我发现tw闭嘴的速度很快的
每当要面临硬碰硬的问题时 嘴巴就闭上了
闭嘴之前的宣言说来说去就是一些正确的废话：
xx不是万能的。

然后就是扮资本家：
不给钱别想从我嘴里撬出一个字，没钱就一边凉快去吧；
如果我说漏了，那也是对你的恩赐。

这话听起来很耳熟。。。想起来了：半仙都爱这么说。

我不是你的客户或者潜在客户，我也不见得比你缺钱花，所以不要以为以钱做准入门槛就能抬高你的地位。记住你的使命：为tw赚吆喝。所以你应该抓住机会展示tw强大的一面，而不是就地找个台阶往下爬。

我就顺着你的话说下去：重构，面向对象技术，不针对并行程序设计

首先请问什么是你定义的面向对象技术。如果我用c写了一大坨面向过程的应用，是不是重构就不能用了？那是不是意味着，面向过程的程序只能推倒重写而无法重构？并且，tw无法接下c的项目？甚至一部份c++也不行吧，因为c++完全可以写出c的风格。

其次，这句话的逻辑似乎有问题。并行和面向对象难道是对立的吗？这两个概念甚至不是一个范畴的吧。却被列举在一个句子里作为正反两面。

我只是举了一个并发的例子。但那个缓存的问题呢？哦，这个不是面向对象，所以对tw来说这是个奇点。
我还可以举出更多不是并发的例子-并且是面向对象的。

比如，我需要抽象出一个接口，这个接口需要隐藏所有IPC的细节。
而这个IPC包括进程间，内核间，内核和进程间，不同物理机器之间。
现在的情况是所有的通讯接口是分散在各处的。怎样重构才能使得它们能以统一的api出现？
从技术上来说这不存在任何问题。但是这里需要一些小技巧来隐藏实现-但这小技巧绝对不只是search/replace all那么简单。
tw可以完全不懂各种IPC而做出重构？
可能tw不会接这笔生意，因为这是用面向过程的语言来写的。

那么tw有更好的选择。在再版重构的时候，明确说明所谓的面向对象-在tw看来-是哪些范畴，明确指出哪些语言的哪些特性才是tw有能力解决的。

面向对象和重构是两个不错的概念，但是tw对这两个概念独到的见解和解释却有悖于common sense。tw的理念--或者说tw所宣传的理念--是：common sense是错的，只有开化了的tw才能带着大能的光辉来解救无知的人们--同时索取报酬。

29 楼 gigix 2010-04-10  

没有人宣称重构可以治百病。没有人宣称面向对象技术可以解决一切软件问题。
事实是从那本书开始，所有人都有一个明确的共识：

重构，面向对象技术，不针对并行程序设计

你可以到那本书里找到对应的引文。

自己立一个风车自己来打，很好玩是吧？

至于对于TW的那堆评论，简单回复如下：
医生会给交了医药费的病人诊疗，有时业余时间给朋友摸摸脉提提建议
至于不相干的陌生人“有兴趣知道”什么东西，其实医生没什么兴趣知道

28 楼 seen 2010-04-10  

抛出异常的爱 写道

tuti 写道

老抛露底了吧

露就露吧
知道了些前以前不知道的东西
以后可以少作点孽


重构这书以前也看过
再看一次吧。
对不住我上个项目的兄弟们
为了分析业务折磨了他们很长时间。



我的确有对需求丢失有恐惧症
去年一月份的一个项目作的那叫一个恶心。。。。
今年年初的一个项目的维护
几乎每次改BUG都像是重新开发一样
把所有可能的需求要REVIEW两次
成果还是被肯定的。
但代价是大多数时间在开会。
每天开发时间大约在2小时左右。
就是恐惧需求缺失。。。。

翻翻以前的贴子
发现gigix以前也说过这样的话。
但当时不是很理解。。。。

你要明白为什么gigix说这个话
tw是做什么的? 到处宣称自己会魔法 可以解百病
tw还不至于厚着脸皮说自己可以精通所有行业的业务
但是他们又希望可以从所有行业里分一杯羹
于是他们想出个办法 说重构是一种高级魔法 可以无视魔防 无视障碍
并且这个世界上大部分人都彻底学不会这种魔法 -- 我估计重构的最佳实践就是加入tw
其实我相信存在这种魔法 因为它的本质是字符串的搜索和替换
换个函数名 或者把函数换个地方 诸如此类

但是 问题在于这种魔法有任何实际意义吗？
有-可以骗钱
但对于你，抛爱同志来说，你相信通过这种全局搜索替换字符串的把戏就可以解决代码中的bug或者潜在bug吗？
如果你只是想让代码看起来符合某些最佳实践，那么这种把戏的确可以做到-至少理论上是可以的
但是你要明白 代码的健壮性完备性效率靠的不是这些死板的规矩和重构工具
如果写代码的人不具备足够的经验和智商，那么这些重构的结果无非是从一个火坑跳到另外一个

tw接受了不少的来自各方面的怀疑 所以他们也发展出了抗体--害虫都有这种本事
他们的抗体就是 彻底否认行业经验对代码的影响 宣布一个人 只要坚决执行所谓重构的实践
那么哪怕他完全不懂代码的真实涵义-对现实的映射，他也可以提升代码质量 解决潜在bug
在宣称这个断言的同时 任何关于重构的、并且出版了的实际例子都是玩具例子
另外的间接例证是tw为多少多少大公司服务过
不知道你感觉如何 反正我是觉得这比皇帝的新衣好不到哪里去

我很有兴趣知道 如果面对一个因为一级缓存被污染而导致的效率下降的bug tw可以给出什么样的解决方案
如果一个因为12个核并发而导致的偶然发生的core，tw又能给出什么方案
tw不是宣称他们无需任何行业相关知识吗？不是说可以完全不理解代码的逻辑吗？那自然也不用理解缓存和pipeline了

我也不知道gigix到底是一个称职的tw人，或者不是。
因为一方面他不遗余力的为tw摇旗呐喊，一方面又反复的暴露tw的方针政策是多么的可笑
这算无间道吗？

27 楼 抛出异常的爱 2010-04-10  

tuti 写道

老抛露底了吧

露就露吧
知道了些前以前不知道的东西
以后可以少作点孽


重构这书以前也看过
再看一次吧。
对不住我上个项目的兄弟们
为了分析业务折磨了他们很长时间。



我的确有对需求丢失有恐惧症
去年一月份的一个项目作的那叫一个恶心。。。。
今年年初的一个项目的维护
几乎每次改BUG都像是重新开发一样
把所有可能的需求要REVIEW两次
成果还是被肯定的。
但代价是大多数时间在开会。
每天开发时间大约在2小时左右。
就是恐惧需求缺失。。。。

翻翻以前的贴子
发现gigix以前也说过这样的话。
但当时不是很理解。。。。

26 楼 tuti 2010-04-10  

老抛露底了吧

25 楼 gigix 2010-04-10  

抛出异常的爱 写道

你是说我不需要去考虑逻辑直接用这些手法来作？
考虑逻辑是我重构过程中最主要的工作。。。。
占工作时间的4/5左右。。。。

这的确是需要用勇气的地方。

不是勇气，而是相信科学
整个重构这件事，是建立在William Opdyke的博士论文基础上的，那篇论文最重要的东西就是在讲行为保持的程序修改手法

有一些修改手法是行为保持的。行为保持的修改手法的叠加是行为保持的。这是已经被证明的原理。

所以你需要首先记住一些常用的行为保持的修改手法，面对一个复杂的程序就直接用这些手法去修改它
这个过程中你清楚自己做的每一步不会对程序的行为造成任何改变
这靠的不是勇气，而是知识
你知道自己每一个动作是在做什么，就像你知道加上一行注释不会改变程序的行为一样

如果必须理解一段程序才能重构它，那你同样会陷入两难
最难重构的那段代码，你是没办法理解它的

之所以有那么多关于重构的奇谈怪论，其实很简单
因为太多人根本就不会重构

24 楼 抛出异常的爱 2010-04-10  

gigix 写道

抛出异常的爱 写道

已经有过重构那种项目的经历了

一开始不是太了解业务。
所以用的暴力DEBUG改了一个模块
太浪费时间
还有业务缺失。

再下来一点点拆代码。。。。。

但还是认为真是个磨灭人性的方式。

你去看我给那本书新写的序
重构的关键不仅是不改变程序行为
更重要的是不需要了解程序行为
你记熟了那些重构手法之后，动手去做的过程完全是形式化的，出错的几率很小，这样你才能安全地做出第一步重构，拆出一些较小的单元，加上测试，然后继续深入
当然这个“记熟”就不仅仅是记得一点“思想”或者知道这些重构手法的名字
你必须记住重构手法的每一个实施步骤
这个道理，我在几年里把那本书读了十几遍才真正明白的

你是说我不需要去考虑逻辑直接用这些手法来作？
考虑逻辑是我重构过程中最主要的工作。。。。
占工作时间的4/5左右。。。。

这的确是需要用勇气的地方。

23 楼 gigix 2010-04-10  

抛出异常的爱 写道

已经有过重构那种项目的经历了

一开始不是太了解业务。
所以用的暴力DEBUG改了一个模块
太浪费时间
还有业务缺失。

再下来一点点拆代码。。。。。

但还是认为真是个磨灭人性的方式。

你去看我给那本书新写的序
重构的关键不仅是不改变程序行为
更重要的是不需要了解程序行为
你记熟了那些重构手法之后，动手去做的过程完全是形式化的，出错的几率很小，这样你才能安全地做出第一步重构，拆出一些较小的单元，加上测试，然后继续深入
当然这个“记熟”就不仅仅是记得一点“思想”或者知道这些重构手法的名字
你必须记住重构手法的每一个实施步骤
这个道理，我在几年里把那本书读了十几遍才真正明白的

22 楼 抛出异常的爱 2010-04-09  

gigix 写道

抛出异常的爱 写道

没有测试代码。
重构就是在自杀。

说明你看那本书看得不够深入
用这个思路你就会进入一个死结：

最需要重构的那些代码是没有测试并且很难加上测试的

结论就是最需要重构的代码你是没办法重构的
所以，你还得继续认真读那本书

已经有过重构那种项目的经历了

一开始不是太了解业务。
所以用的暴力DEBUG改了一个模块
太浪费时间
还有业务缺失。

再下来一点点拆代码。。。。。

但还是认为真是个磨灭人性的方式。

21 楼 gigix 2010-04-09  

抛出异常的爱 写道

没有测试代码。
重构就是在自杀。

说明你看那本书看得不够深入
用这个思路你就会进入一个死结：

最需要重构的那些代码是没有测试并且很难加上测试的

结论就是最需要重构的代码你是没办法重构的
所以，你还得继续认真读那本书

20 楼 baiiiuuu 2010-04-09  

抛出异常的爱 写道

没有测试代码。
重构就是在自杀。

5.重构的保证：测试。  

说的不错！

19 楼 nijian 2010-03-31  

抛出异常的爱 写道

没有测试代码。
重构就是在自杀。

赞同。重构还有一个目标，就是形成越来越成熟的程序结构，甚至提炼框架，仅仅让代码味道好是不够的。

18 楼 抛出异常的爱 2010-03-30  

没有测试代码。
重构就是在自杀。

17 楼 rappy 2010-03-30  

“重构”就一单词，语境不同，语义有异，跟“方便”没啥两样。

别死抠了，这东东早就有了，只不过某些人非要给起个名。

说白了就是：让程序看起来爽一点。看得不爽就给改改，再测一把，完了。就这么简单。

16 楼 gagi 2010-03-28  

lz的总结出于《基于现有代码的重构与设计》