fangang
- 浏览: 881755 次
- 性别:
- 来自: 北京
-
最新评论
-
Junjing：
非常感谢楼主的分享，受益匪浅！我是一位从业务规划和运营转需求分 ...
我们应当怎样做需求确认：评审与签字确认会 -
kersky：
感谢楼主的辛苦输出，半天看完了整个系列。对于一个转从开发转需求 ...
我们应当怎样做需求确认：评审与签字确认会 -
DEMONU：
必须要顶
谈谈软件开发的那些事儿 之 软件开发的轮回 -
dripstone：
非常感谢楼主，用了大半天的时间，一口气读完了需求分析阶段。好多 ...
我们应当怎样做需求确认：评审与签字确认会 -
Codepoe：
做了一些开发，看了楼主的文章，我深有感触，为自己的做法找到了理 ...
我们应当改变我们的设计习惯
文章列表
《大话重构》这本书是我写的第一本书，从今天起我将通过连载的形式逐渐跟大家分享。
这本书让你：
告别游击队转变为正规军，
远离劣质代码走向精妙设计
真正明白专业级的软件开发是怎样的
真正明白重构是怎样一步一步进行的
高效重构七步曲，面对实践不卡壳
让遗留系统维护不再是你的梦魇
读完这本书以后：
需求变更不再纠结，重构让你润物细无声地容纳它们
超越代码级的重构，从各个层面深度领略重构之美
自动化测试不再是梦想，重构让自动化测试走你
重新审视熟悉而陌生的技术，将碎了一地的它们重新铆合在一起
本书的目录：
遗留系统——软件工业时代的痛
第一部分 基础篇
重构，一个既熟悉又陌生的名词。在这里 ...
[置顶] 我的电子书地址
- 博客分类：
- 杂谈
过去在主页的边栏中就有“我的电子书”，现在被iteye改没了，
有网友问到了，我就把地址公布一下吧：
http://fangang.iteye.com/blog/pdf
其它文章，可以访问我的百度文集：
http://www.baidu.com/p/Mooodo?from=wenku
另外，我还有以下几个博客网站，我都尽量保持同步发布：
http://blog.csdn.net/mooodo
http://www.cnblogs.com/mooodo/
很好，我们终于迈出了重构的第一步，而这第一步我们瞄准了代码问题的重灾区——超级大函数。超级大函数之所以是代码问题的重灾区，就是因为它们往往难于阅读、难于维护。面对大函数我们采取的办法是拆分，以功能为核 ...
使用抽取方法，虽然道理十分简单，但实际操作起来却并不是那么容易的。完成抽取方法最大的困难，就是如何处理抽取函数与原函数的数据交换。如同将一颗大树从土壤里拔出来，盘根错节的根茎，那是剪不断理还乱。当代码 ...
说了那么多理论，我们来看看怎样使用抽取方法来重构遗留系统。如前所述，重构的过程首先是阅读程序代码，边阅读边整理程序。将功能相对独立的代码段放在一起，在前面加上注释。调整一些程序的顺序，将相关的代码尽量放在一起，但要保证程序执行的结果不会发生改变。比较典型的，将变量的定义与使用变量的代码放在一起。这个步骤比较实用，因为许多的遗留系统，其代码都有一个坏毛病，就是在程序开始时定义一大堆变量，但要弄清这些变量都用来做什么，却十分困难。边读边调整，将变量的定义逐渐迁移到使用它的代码段中，将大大提高代码可读性，你甚至会发现并简化一些变量。
前面的工作为抽取函数做好了准备，但你不必阅读和整理完所有的代码才开 ...
事情总是这样的：当我们对一个遗留系统一忍再忍，再忍，忍，还要忍……终于积攒到某一天，实在忍无可忍了，拍案而起，不能再忍了，重构！！！事情就这样发生了。然而，在这时你突然发现，重构的工作千头万绪，真不知从何开始。堆积如山的问题此起彼伏，期望修改的设计思绪万千。这里有个想法，那里有个思路，什么都想做，却什么都做不了，真是脑子里一团乱麻。这时候，没有一个合理的步骤，清晰的计划，瞎干蛮干是十分危险的，它会为你的重构带来不可预期的未来。无数次的经验告诉我，不论是什么系统，采用什么架构，从分解大函数开始，肯定没有错。
大函数，就是那些业务逻辑特别复杂、程序代码特别多、一提起就叫人头疼不已的超级方法。超级大 ...
第五次重构我们引入了数据库的设计，用户信息要从数据库中读取，问候语库存储在数据库中，并支持添加与更新。数据库的引入使自动化测试变得困难了，因为数据状态总是变化着的，而这种变化使得测试过程不能复现，这是我们不愿看到的。因此，我们在设计时将业务与数据库访问分离，形成了UserDao与GreetingRuleDao。此时，我们的设计应当遵从“依赖反转”原则，即将UserDao与GreetingRuleDao设计成接口，并编写它们的实现UserDaoImpl与GreetingRuleDaoImpl。这样设计就为我们Mock掉UserDao与GreetingRuleDao的实现类创造了条件。
这是我们的 ...
说了那么多，让我们用示例看看，系统重构是应该怎样做自动化测试的。还是回到前面那个HelloWorld的例子（详见 3.3 小步快跑是这样玩的），该类中有一个sayHello()方法，只要我们输入当前的时间与用户名，就返回对该用户的问候语。如果当前时间是上午，则返回“Hi, XXX. Good morning!”；如果是下午，则返回“Hi, XXX. Good afternoon!”；如果是晚上，则返回“Hi, XXX. Good Night!”，这是HelloWorld这个程序实现的功能。
然后我们开始为这段程序编写测试代码（如果采用测试驱动开发，应当先写测试代码再写程序）。我们首先建立一个t ...
正如许多事情都有其两面性一样，测试方法也是这样。要保证测试方法正确，最简单、最直观地想法就是多写些测试用例，从更多地角度去测试，但这必然增加我们的测试成本。小步快跑要求我们频繁进行测试，假如我们重构的周期是20分钟，但测试却要花掉10分钟，那么这样的成本就实在太大了。假如这种测试还是开发人员手工测试，每天都有对同样的测试反复执行数十遍，那么开发人员估计就要疯掉了。
你可能立即就想到自动化测试了。是的，在许多重构的书籍中，大师们都建议我们在重构开始前，首先建立自动化测试机制。但遗憾的是，我经过多年的实践总结出来的经验是，这几乎不可能实现。每次重构，我们面临的都是一个个遗留系统。大多数遗留系统都有 ...
通过前面的描述你已经对重构中“小步快跑”的开发模式有了一个清楚的认识。学会和习惯小步快跑的开发模式，对于重构工作极其重要，因为它让这种大范围、大幅度修改代码的重构工作变得不再像以往那样让人胆战心惊。究 ...
说了那么多，相信你对小步快跑的概念有了一个初步的印象，但理解还不是很深。让我们来看一看一个实际工作中的例子，来亲身感受一下什么是大布局，什么是大设计，什么是小设计。
还是回到前面那个Hello World的例子，起初 ...
开车的朋友一定深有体会，驾驶汽车其实就是在不断矫正汽车行驶方向的一个过程。在整个驾驶过程中，你必须全神贯注地紧盯前方，通过方向盘不断矫正方向，否则即使行驶在直线路段也可能偏离车道。那些疲劳驾驶的司机， ...
作为优秀开发人员，重构应当成为一种习惯，自然而然地运用重构的开发模式，自然而然地在优化和调整我们的代码。它首先要求我们掌握重构的开发模式，就是“小步快跑”的开发模式，运用“两顶帽子”的设计顺序，去开发 ...
下面我们来盘点一下系统重构工具箱里都有什么，也就是看一看系统重构到底都有哪些方法。系统重构总是在不同层次上调整我们的代码，因此重构方法也就分为了多个层次。从总体上看，重构方法分为以下几个层次：方法的重构、对象的重构、对象间的重构、继承体系间的重构、组织数据的重构与体系架构的重构。
前面那个例子我们可以清楚地看到方法的重构过程。方法的重构往往发生在一个对象的内部，是对一个对象内部的优化。从这个例子中，我们首先看到了增加注释、调整顺序、重命名变量、进行分段等操作，这些虽然不是什么重构方法，却是我们进行前期准备的常用技法。随后我们将通过注释分段存放的各个代码段提取出来，形成单独的函数。这种重构方法被 ...
经过前面的一番讲解，相信你已经对系统重构有了一些初步的认识了。一切的一切仿佛在告诉我们，系统重构总是与需求变更无关。但此时，我不得不告诉你这是真实的谎言。
我们的软件系统总是处于一种变化之中，并且往往是一种由浅入深、由易到难的过程。但是，当系统复杂程度发生变化时，我们应当及时调整我们的设计，来适应新的变化。然而我们没有做到这一点，所以我们的系统维护变得越来越困难。要解决我们的问题必须通过系统重构去优化我们的程序，使之重新适应业务需求。毫无疑问，需求变更才是我们去重构的主要动因。
然而，系统重构要求我们不能改变软件的外部行为，这意味着在重构的过程中不能为软件添加任何新功能，重构仿佛与变更无关。 ...