大话重构Word格式文档下载.docx
- 文档编号:15118753
- 上传时间:2022-10-27
- 格式:DOCX
- 页数:61
- 大小:485.28KB
大话重构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脚本也是一个不错的方式,它虽然有诸多问题,但却可以在系统重构初期有效地
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 大话