大话重构Word格式文档下载.docx

大话重构Word格式文档下载.docx

《大话重构Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《大话重构Word格式文档下载.docx（61页珍藏版）》请在冰豆网上搜索。

是的，面对软件工业时代我们并没有做好准备。

过去，一套软件的生命周期不过2~3年时间，随着软件需求的变化，我们总是选择将软件推倒了重新开发，但是现在这样的情况在发生着改变。

随着软件规模的扩大，软件数据的积累，软件影响力的提升，我们，以及我们的客户，都真切地感受到，要推倒一套软件重新开发，将变得越来越困难而不切实际。

这样的结果就是，我们的软件将不停地修改、维护、再修改、再维护……直到永远。

这是一件多么痛苦的事情啊！

一套软件，当它第一次被开发出来的时候，一切都十分清晰：

清晰的业务需求、清晰的设计思路、清晰的程序代码。

但经历了几次需求变更与维护以后，一切就变得不那么清晰了。

业务需求文档变得模糊不清，设计思路已经跟不上变更的脚步，程序代码则随着业务逻辑的复杂而臃肿不堪。

程序员开始读不懂代码，软件开发工作变得不再是一种乐趣。

随着时间的推移，软件经过数年、数十次的变更与维护，情况变得越来越糟。

最初的程序员已经不愿再看到自己的代码而选择离去。

他的继任者们变得更无所是从，由于看不懂程序，代码的每一次修改如同在走钢丝。

测试人员变成了唯一的希望，开发人员的每一次修改都意味着测试人员需要把所有程序测试一遍。

继任者们开始质问最初的设计者们，程序是怎么设计的。

如果此时恰巧又有什么新技术出现，就会更显得原有系统的破旧与不堪。

相信这就是软件工业时代的所有企业都不得不面对的尴尬境地。

难倒真的是我们最初的设计错了吗？

是的，我们都这样质问过我们自己，因此我们开始尝试在软件设计之初投入更多的精力。

我们开始投入更多的时间作需求调研，考虑更多可能的需求变化，做更多的接口，实现更加灵活但复杂的设计。

然后呢，我们解决了我们的问题了吗？

显然是没有。

需求并没有像我们想象的那样发生变更：

我们之前认为可能发生的变更并没有发生，使我们为之做出的设计变成了摆设；

我们之前没有考虑到的变更发生了，让我们猝不及防，软件质量开始下降，我们被打回了原形。

难倒真的是无药可解了吗？

在我看来，如果我们没有看明白软件开发的规律与特点，那么我们永远找不到那份向往已久的解药。

现在，让我们真正静下心来分析分析软件开发的规律与特点吧。

软件，特别是管理软件，其实质是对真实世界的模拟。

我们通过对真实世界的模拟，实现计算机的信息化管理，来提高我们的生产效率。

然而，真实的世界复杂而多变的，我们认识世界却是一个由简单到复杂循序渐进的过程，这是一个我们无法改变的客观规律。

因此，毫无疑问，遵循着这样一个客观规律，我们的软件开发过程必然也是一个由简单到复杂循序渐进的过程。

最初，我们开发的是一个对真实世界最简单、最主要、最核心部分的模拟。

因为简单，我们的思路变得清晰而明了。

但是，我们的软件不能永远只是模拟那些最简单、最主要、最核心的部分。

我们的客户在使用软件的过程中，如果遇到那些不那么简单、不那么主要、不那么核心的情况时，我们的软件就无法处理了，这是客户无论如何不能接受的。

因此，但软件的第一个版本交付客户以后，客户的需求就开始变更。

客户的需求永远不会脱离真实世界，也就是说，真实世界不存在的事物、现象、关系永远都不可能出现在软件需求中。

但是，真实世界的事物、规则与联系并不是那么的简单与清晰的。

随着我们的软件对它模拟得越来越细致，程序的业务逻辑开始变得不再那么清晰而易于理解，这就是软件质量下降最关键的内因。

任何一个软件的设计，总是与软件的复杂度有密切的关系。

举例来说吧，客户资料是许多系统都必须要记录的重要信息。

起初，我们程序简单，客户资料只记录了一些简单的信息，如客户名称、地址、电话等等，但随着程序复杂度的增加，客户资料开始变得复杂。

比如，起初“地址”字段就仅仅需要一个字符串就可以了，但随着需求的变更，它开始有了省份、城市、地区、街道等信息。

随后还会有邮政编码、所属社区、派出所等信息。

起初增加一个两个字段时我们还可以在“客户信息表”里凑合一下，但后来我们必须要及时调整我们的设计，将地址提取出来单独形成一个“地址信息表”。

如果不及时予以调整，“客户信息表”将越来越臃肿，由10来个字段，变成50个、80个、上100个……

信息表尚且如此，业务操作更是如此。

起初的业务操作是如此的简单而明了，以至于我们不需要花费太多的类就可以将它们描述清楚。

比如开票操作，最初的需求就是将已开具的票据信息读取出来，保存，并统计出本月开票量及金额。

这样一个简单操作，设计成一个简单的“开票业务类”合情合理。

但随后的业务逻辑变得越来越复杂，我们要检查客户是否存在、开票人是否有权限、票据是否还有库存，等等。

起初的开票方式只有一种，但随着非正常开票的加入，开票方式不再单一，而统计方式也随之变化……随着业务的不断增加，软件代码的规模也在发生着质的变化。

如果这时我们不及时调整我们的设计，而是将所有的程序都硬塞进“开票业务类”，那么程序质量必然会退化。

“开票业务类”由原有的数十行，激增到数百行，甚至上千行。

这时的代码将难于阅读，维护它将变成一种痛苦，毫无乐趣可言。

面对这样的状况，我们应当怎样走出困境呢？

毫无疑问，就是重构，软件的重构。

开票前的校验真的属于“开票业务类”吗？

它们是否应当被提取出来，解耦成一个一个的校验类。

正常开票与非正常开票真的应该写在一起吗？

是否我们应当把“开票业务类”抽象成接口，以及正常开票与非正常开票的实现类。

这就是我给大家的良方：

当软件因为需求变更而开始渐渐退化时，运用软件重构改善我们的结构，使之重新适应软件需求的变化。

第一部分基础篇

第1章重构：

改变既有代码的一剂良药

前面我们提到了，面对软件工业时代的到来，我们的软件企业陷入了一种更深的迷茫之中，一种“后有追兵，前有悬崖，进退两难”的境地。

后有追兵：

面对维护了数十年之久的大型遗留系统，我们到底改还是不改？

不改，面对越来越多的需求变更，我们维护的成本越来越高，变更变得越来越困难；

面对不断涌现的新技术，使我们的系统显得越来越丑陋与落后；

面对越来越多的竞争者，使我们面临着被市场淘汰的风险。

前有悬崖：

原本运行得好好的软件系统，凑合一下还可以运行几年。

一不小心改出问题了，企业立马就歇菜儿了，面对大量的用户投诉，企业四处救火，竞争对手趁火打劫，这是任何软件企业都不能承受的巨大风险。

难倒真的“熊掌和鱼不能兼得”吗？

真的没有一种方法，能够既保证我们系统可以技术改造，又能有效地避免改造过程的风险吗？

有，那就是系统重构。

1.1什么是系统重构

提到重构，许多人都讳莫如深、敬而远之。

什么是系统重构呢？

大家可能有很多的不同看法：

1.系统重构是那些系统架构师、技术大牛玩的高端玩意儿，咱普通屌丝不懂，跟咱没啥关系。

2.系统重构就是改代码，大改特改那种，整个重来一遍那种，这个比较邪恶，比较容易改出事儿，还是不要轻易尝试为妙。

3.我知道系统重构，也知道它能改善遗留系统，但我还是不敢轻易尝试，因为改出问题来怎么办，还是算了吧。

然而我认为，现在我们对系统重构有太多的误解，以至于我们还不怎么了解它，就已经将它拒之门外。

它是一套严谨而安全的过程方法，它通过一系列行之有效的方法与措施，保证软件在优化的同时，不会引入新的BUG，保证软件改造的质量。

这一点在我后面一步一步的拆解中，你可以慢慢体会到。

我们先看看系统重构的概念。

系统重构，就是在不改变软件外部行为的基础上，改变软件内部的结构，使其更加易于阅读、易于维护和易于变更。

系统重构中一个非常关键的前提就是“不改变软件外部行为”，这个前提非常重要，它保证了我们在改造原有系统的同时，不会为原系统带来新的BUG，以确保改造的安全。

这里，什么是“为原系统带来新的BUG”？

我们必须为其做出一个严格的定义，那就是“改变了软件原有的外部行为”。

也许你对此有些不太赞同，改变了软件原有的外部行为，怎么就能武断地认为，是为原系统带来了新的BUG呢？

为此我们来举个例吧。

假如一个系统的报表查询功能，原来在表格里的返回结果中，日期是这样表示的“2013-2-18”，经过系统改造以后变成这样了“2013-2-1800:

00:

00”，这是BUG吗？

作为开发人员你可能认为这算什么BUG，但作为客户那就是BUG，因为它让表格变得难看，使用不再方便了。

系统重构，对于客户来说应当是完全透明的。

我们为之做了很多工作，而他们应当完全感觉不到它的存在。

如果我们的重构做到了这一点，那么我们的重构就必然是安全的、可靠的、没有风险的。

更广泛一些来说，如果我们打开软件内部，保证系统中的每个接口与改造前是等价的，也就是说，其输入输出在改造前后都是一致的。

当我们的每个改造都是这样进行的，则必然不会为系统带来新的BUG。

这就是我们进行改造的保险索，它也是我现在所说的重构，与以往那种拿着代码一阵瞎改的根本区别。

总而言之，系统重构不是那种冒着极大风险进行的代码修改，而是必须保证修改前后输入输出的一致，这就是我们说的“不改变外部行为”。

为此，贯穿整个重构过程的是不断的测试。

起初这种测试是手工测试，随后逐渐转变为自动化测试。

每修改一点点就进行一个测试，再修改一点点。

测试，就是系统重构的保险索。

1.2在保险索上走钢丝

当我们开始系统重构的时候，不是着手去修改代码，而是首先建立测试机制。

不论什么程序，只要是被我们修改了，理论上就可能引入BUG，因此我们就必须要进行测试。

既然是测试就必须要有一个正确与否的评判标准。

以往的测试，其评判的标准就是是否满足业务需求。

因此，测试人员往往总是拿着需求文档测试系统。

与以往的代码修改不同，重构没有引入任何新的需求，系统原来什么功能，重构以后还是这些功能。

因此，重构的测试标准就只有一个，就是与之前的功能完全保持一致，仅此而已。

然而在许多经典的重构书籍中，大师们总是建议我们首先建立自动化测试机制，这已经被我在无数次实践中证明是不现实的。

要知道我们现在重构的是一个遗留系统，它往往设计混乱，接口不清晰，程序相互依赖。

所有这些都使得最初的自动化测试变得非常困难而不切实际。

因此，从一开始就实现自动化测试是不切实际的，我们所能采用的还是手工测试。

在重构之前首先将系统启动起来，执行相应的功能，得到各自相应的输出。

然后开始重构，每次重构对代码的修改量不要太大，花费的时间不要太长。

因为，修改量太大，花费时间太长，一旦测试不通过，很难定位错误的原因。

在这种情况下，我们只能还原代码，将此次修改的工作完全作废。

如果此次修改已经花费了你数天甚至数月的时间，这样的损失就实在太大了。

每做一次重构，修改一点儿代码，然后提交，对系统进行一次测试。

如果系统依然保持与以往一样的功能，重构成功，继续进行下一次重构。

如果不是，你不得不还原回来重新重构。

频繁地测试着实让你挺烦的，但却有效减少了重构失败带给你的损失。

一个折中的办法就是，平时频繁测试的时候，测试项目少一些，只测试主要项目，定期再进行全面地测试。

录制QTP脚本也是一个不错的方式，它虽然有诸多问题，但却可以在系统重构初期有效地