软件,自从被我们开发出来并交付使用以后,如果它运行得好好的,我们是不会去修改它的。我们要修改软件,万变不离其宗,无非就是四种动机:
1.增加新功能;
2.原有功能有BUG;
3.改善原有程序的结构;
4.优化原有系统的性能 。
第一种和第二种动机,都是源于客户的功能需求,而第四种是源于客户的非功能需求。
软件的外部质量,其衡量的标准就是客户对软件功能需求与非功能需求的满意度。它涉及到一个企业、一个软件的信誉度与生命力,因此为所有软件企业所高度重视。但是,就在所有企业高管把软件外部质量放在高于一切的高度的同时,软件内部质量却长期为人所漠视。企业没有保证软件内部质量的措施,甚至因为需要赶工而肆意地降低内部质量的标准。这样带来的长期恶果就是,程序编写越来越烂,运行效率越来越低,程序结构越来越让人看不懂。当一群群刚刚毕业的大学生游走在这堆写得很烂的代码中时,他们开始沉沦,开始天真地以为代码就是这样写的(真是毁人不倦呀)。当我们的软件企业培养出一批批质量不高的开发人员,开发出一个个质量低下的软件系统时,它们开始发现软件维护成本越来越高,最终不得不收获自己种下的恶果。
要提高软件内部质量,毫无疑问就是软件修改的第三个动机:改善原有程序的结构。它的价值是隐性的,并不体现在某一次或两次开发中,而是逐渐体现在日后长期维护的软件过程中。高质量的软件,可以保证开发人员(即使是新手)能够轻易看懂软件代码,能够保证日后的每一次软件维护都可以轻易地完成(不论软件经历了多少次变更,维护了多少年),能够保证日后的每一次需求变更都能够轻易地进行(而不是伤筋动骨地大动)。要做到这几点其实并不容易,它需要我们持续不断地对系统内部质量进行优化与改进。这,就是系统重构的价值。
为了有效提高软件的内部质量,我们在系统重构中应当做哪些事情呢?首先是提高软件的可读性、易于阅读。软件要可读,并不是添加几行注释那么简单的事儿,首先是软件的业务逻辑要清晰。一个业务流程可能其处理过程可能非常复杂,如果在一个函数中顺序地一行一行写下来,可能需要写数百行,甚至上千行。比如,我们要实现这样一个需求:像Spring那样从一个或者数个配置文件中读取XML,然后根据XML依次去创建每一个bean,将每一个bean放到beanFactory中。如果没有经过精心地设计,而是随性地一行一行写,要实现这个功能没个几百上千行代码,想想都难。但如果我们换个思路,在入口函数里仅仅调用几个顶级方法,比如findXmlFile()、readXmlStream()、buildFactory(),然后依次去实现这几个顶级方法,程序结构就会变得清晰而易读。请看这段示例代码:
在实现这几个顶级函数的时候,我们还会将一些比较独立的功能分解出去,形成类与接口,比如这里的findXmlFile(),它可能会以各种方式去寻找XML文件,这时把这些功能提取出来,形成Resource接口和它的多个实现(如图1.1所示),为findXmlFile()所调用。如果我们将这个复杂的功能设计成这样,则毫无疑问,系统可读性将大大提高。
[align=center][img]http://dl2.iteye.com/upload/attachment/0098/9195/e9565d7c-f9ca-3f5d-bc32-a48b1c565c48.jpg[/img][/align][align=center]图1.1 工厂类模板的设计图[/align]
此外,在面向对象的世界里,我们设计的类、方法、关联,应当与现实世界中的事物、行为,及其相互的关系对应起来。现实世界有什么事物,这些事物都应当有什么行为,相互之间是什么关系,则我们在软件世界里就应当设计什么类、什么方法和它们之间的关联关系。只有这样的设计才是最易于为人所理解的设计,这就是“领域驱动设计”的思想 。在系统重构中,我们将使用“抽取方法”来分解难于阅读与维护的大函数,用“抽取对象”来分解无所不能的大对象。
系统重构要干的另一件事情就是使软件易于维护、易于变更。软件需求总是变得越来越复杂,这是无法改变的客观事实。在添加新功能的同时,我们既要保证原有代码的有效性,又必须有效地复用原有的代码。这是多么矛盾的一件事儿啊!怎么办呢?看我在后面一步一步给你分解……
大话重构连载首页:[url]http://fangang.iteye.com/blog/2081995[/url]
特别说明:希望网友们在转载本文时,应当注明作者或出处,以示对作者的尊重,谢谢!
1.增加新功能;
2.原有功能有BUG;
3.改善原有程序的结构;
4.优化原有系统的性能 。
第一种和第二种动机,都是源于客户的功能需求,而第四种是源于客户的非功能需求。
软件的外部质量,其衡量的标准就是客户对软件功能需求与非功能需求的满意度。它涉及到一个企业、一个软件的信誉度与生命力,因此为所有软件企业所高度重视。但是,就在所有企业高管把软件外部质量放在高于一切的高度的同时,软件内部质量却长期为人所漠视。企业没有保证软件内部质量的措施,甚至因为需要赶工而肆意地降低内部质量的标准。这样带来的长期恶果就是,程序编写越来越烂,运行效率越来越低,程序结构越来越让人看不懂。当一群群刚刚毕业的大学生游走在这堆写得很烂的代码中时,他们开始沉沦,开始天真地以为代码就是这样写的(真是毁人不倦呀)。当我们的软件企业培养出一批批质量不高的开发人员,开发出一个个质量低下的软件系统时,它们开始发现软件维护成本越来越高,最终不得不收获自己种下的恶果。
要提高软件内部质量,毫无疑问就是软件修改的第三个动机:改善原有程序的结构。它的价值是隐性的,并不体现在某一次或两次开发中,而是逐渐体现在日后长期维护的软件过程中。高质量的软件,可以保证开发人员(即使是新手)能够轻易看懂软件代码,能够保证日后的每一次软件维护都可以轻易地完成(不论软件经历了多少次变更,维护了多少年),能够保证日后的每一次需求变更都能够轻易地进行(而不是伤筋动骨地大动)。要做到这几点其实并不容易,它需要我们持续不断地对系统内部质量进行优化与改进。这,就是系统重构的价值。
为了有效提高软件的内部质量,我们在系统重构中应当做哪些事情呢?首先是提高软件的可读性、易于阅读。软件要可读,并不是添加几行注释那么简单的事儿,首先是软件的业务逻辑要清晰。一个业务流程可能其处理过程可能非常复杂,如果在一个函数中顺序地一行一行写下来,可能需要写数百行,甚至上千行。比如,我们要实现这样一个需求:像Spring那样从一个或者数个配置文件中读取XML,然后根据XML依次去创建每一个bean,将每一个bean放到beanFactory中。如果没有经过精心地设计,而是随性地一行一行写,要实现这个功能没个几百上千行代码,想想都难。但如果我们换个思路,在入口函数里仅仅调用几个顶级方法,比如findXmlFile()、readXmlStream()、buildFactory(),然后依次去实现这几个顶级方法,程序结构就会变得清晰而易读。请看这段示例代码:
public abstract class XmlBuildFactoryTemplate {
/**
* 初始化工厂。根据路径读取XML文件,将XML文件中的数据装载到工厂中
* @param path XML文件的路径
*/
public void initFactory(String path){
//寻找XML文件,读取数据流
InputStream inputStream = findXmlFile(path);
//解析XML文件,返回根
Element root = readXmlStream(inputStream);
//根据XML文件创建类,放入工厂中
buildFactory(root);
}
/**
* 读取一个XML的文件,输出其数据流
* @param path XML文件的路径
* @return InputStream文件输入流
*/
protected InputStream findXmlFile(Stringpath) {
......
}
/**
* 读取并解析一个XML的文件输入流,以Element的形式获取XML的根,返回之
* @param inputStream 文件输入流
* @return ElementXML的根
*/
protected Element readXmlStream (InputStream inputStream) {
......
}
/**
* 用从一个XML的文件中读取的数据构建工厂
* @param root 从一个XML的文件中读取的数据的根
*/
protected abstract void buildFactory(Element root);
}
在实现这几个顶级函数的时候,我们还会将一些比较独立的功能分解出去,形成类与接口,比如这里的findXmlFile(),它可能会以各种方式去寻找XML文件,这时把这些功能提取出来,形成Resource接口和它的多个实现(如图1.1所示),为findXmlFile()所调用。如果我们将这个复杂的功能设计成这样,则毫无疑问,系统可读性将大大提高。
[align=center][img]http://dl2.iteye.com/upload/attachment/0098/9195/e9565d7c-f9ca-3f5d-bc32-a48b1c565c48.jpg[/img][/align][align=center]图1.1 工厂类模板的设计图[/align]
此外,在面向对象的世界里,我们设计的类、方法、关联,应当与现实世界中的事物、行为,及其相互的关系对应起来。现实世界有什么事物,这些事物都应当有什么行为,相互之间是什么关系,则我们在软件世界里就应当设计什么类、什么方法和它们之间的关联关系。只有这样的设计才是最易于为人所理解的设计,这就是“领域驱动设计”的思想 。在系统重构中,我们将使用“抽取方法”来分解难于阅读与维护的大函数,用“抽取对象”来分解无所不能的大对象。
系统重构要干的另一件事情就是使软件易于维护、易于变更。软件需求总是变得越来越复杂,这是无法改变的客观事实。在添加新功能的同时,我们既要保证原有代码的有效性,又必须有效地复用原有的代码。这是多么矛盾的一件事儿啊!怎么办呢?看我在后面一步一步给你分解……
大话重构连载首页:[url]http://fangang.iteye.com/blog/2081995[/url]
特别说明:希望网友们在转载本文时,应当注明作者或出处,以示对作者的尊重,谢谢!