我常常感到幸运,我们现在所处的是一个令人振奋的时代,我们进入了软件工业时代。在这个时代里,我们进行软件开发已经不再是一个一个的小作坊,我们在进行着集团化的大规模开发。我们开发的软件不再是为某个车间、某个工序设计的辅助工具,它从某个单位走向整个集团,走向整个行业,甚至整个社会,发挥着越来越重要的作用。一套软件所起到的作用与影响有多大,已经远远超越了所有人的想象,成为一个地区、一个社会,乃至整个国家不可或缺的组成部分。慢慢地,人们已经难以想象没有某某软件或系统的生活和工作会是怎样的。这就是软件工业时代的重要时代特征。
然而,在这个令人振奋的软件工业时代,处于时代中心的各大软件企业却令人沮丧。软件规模越来越庞大,软件结构越来越复杂的同时,却是软件质量越来越低下,软件维护变得越来越困难,以至于每个小小的变更都变得需要伤筋动骨。研发人员为此举足无措,测试人员成为唯一的救星,每个小小的变更都需要付出巨大代价进行测试。软件企业在这样一种恶性循环中苦苦支撑。毫无疑问,这也成为这个令人振奋的时代的另一个特征。
是的,面对软件工业时代我们并没有做好准备。过去,一套软件的生命周期不过2~3年时间,随着软件需求的变化,我们总是选择将软件推倒了重新开发,但是现在这样的情况在发生着改变。随着软件规模的扩大,软件数据的积累,软件影响力的提升,我们,以及我们的客户,都真切地感受到,要推倒一套软件重新开发,将变得越来越困难而不切实际。这样的结果就是,我们的软件将不停地修改、维护、再修改、再维护……直到永远。这是一件多么痛苦的事情啊!
一套软件,当它第一次被开发出来的时候,一切都十分清晰:清晰的业务需求、清晰的设计思路、清晰的程序代码。但经历了几次需求变更与维护以后,一切就变得不那么清晰了。业务需求文档变得模糊不清,设计思路已经跟不上变更的脚步,程序代码则随着业务逻辑的复杂而臃肿不堪。程序员开始读不懂代码,软件开发工作变得不再是一种乐趣。
随着时间的推移,软件经过数年、数十次的变更与维护,情况变得越来越糟。最初的程序员已经不愿再看到自己的代码而选择离去。他的继任者们变得更无所是从,由于看不懂程序,代码的每一次修改如同在走钢丝。测试人员变成了唯一的希望,开发人员的每一次修改都意味着测试人员需要把所有程序测试一遍。继任者们开始质问最初的设计者们,程序是怎么设计的。如果此时恰巧又有什么新技术出现,就会更显得原有系统的破旧与不堪。
相信这就是软件工业时代的所有企业都不得不面对的尴尬境地。难倒真的是我们最初的设计错了吗?是的,我们都这样质问过我们自己,因此我们开始尝试在软件设计之初投入更多的精力。我们开始投入更多的时间作需求调研,考虑更多可能的需求变化,做更多的接口,实现更加灵活但复杂的设计。然后呢,我们解决了我们的问题了吗?显然是没有。需求并没有像我们想象的那样发生变更:我们之前认为可能发生的变更并没有发生,使我们为之做出的设计变成了摆设;我们之前没有考虑到的变更发生了,让我们猝不及防,软件质量开始下降,我们被打回了原形。难倒真的是无药可解了吗?在我看来,如果我们没有看明白软件开发的规律与特点,那么我们永远找不到那份向往已久的解药。现在,让我们真正静下心来分析分析软件开发的规律与特点吧。
软件,特别是管理软件,其实质是对真实世界的模拟。我们通过对真实世界的模拟,实现计算机的信息化管理,来提高我们的生产效率。然而,真实的世界复杂而多变的,我们认识世界却是一个由简单到复杂循序渐进的过程,这是一个我们无法改变的客观规律。因此,毫无疑问,遵循着这样一个客观规律,我们的软件开发过程必然也是一个由简单到复杂循序渐进的过程。
最初,我们开发的是一个对真实世界最简单、最主要、最核心部分的模拟。因为简单,我们的思路变得清晰而明了。但是,我们的软件不能永远只是模拟那些最简单、最主要、最核心的部分。我们的客户在使用软件的过程中,如果遇到那些不那么简单、不那么主要、不那么核心的情况时,我们的软件就无法处理了,这是客户无论如何不能接受的。因此,但软件的第一个版本交付客户以后,客户的需求就开始变更。
客户的需求永远不会脱离真实世界,也就是说,真实世界不存在的事物、现象、关系永远都不可能出现在软件需求中。但是,真实世界的事物、规则与联系并不是那么的简单与清晰的。随着我们的软件对它模拟得越来越细致,程序的业务逻辑开始变得不再那么清晰而易于理解,这就是软件质量下降最关键的内因。
任何一个软件的设计,总是与软件的复杂度有密切的关系。举例来说吧,客户资料是许多系统都必须要记录的重要信息。起初,我们程序简单,客户资料只记录了一些简单的信息,如客户名称、地址、电话等等,但随着程序复杂度的增加,客户资料开始变得复杂。比如,起初“地址”字段就仅仅需要一个字符串就可以了,但随着需求的变更,它开始有了省份、城市、地区、街道等信息。随后还会有邮政编码、所属社区、派出所等信息。起初增加一个两个字段时我们还可以在“客户信息表”里凑合一下,但后来我们必须要及时调整我们的设计,将地址提取出来单独形成一个“地址信息表”。如果不及时予以调整,“客户信息表”将越来越臃肿,由10来个字段,变成50个、80个、上100个……
信息表尚且如此,业务操作更是如此。起初的业务操作是如此的简单而明了,以至于我们不需要花费太多的类就可以将它们描述清楚。比如开票操作,最初的需求就是将已开具的票据信息读取出来,保存,并统计出本月开票量及金额。这样一个简单操作,设计成一个简单的“开票业务类”合情合理。但随后的业务逻辑变得越来越复杂,我们要检查客户是否存在、开票人是否有权限、票据是否还有库存,等等。起初的开票方式只有一种,但随着非正常开票的加入,开票方式不再单一,而统计方式也随之变化……随着业务的不断增加,软件代码的规模也在发生着质的变化。如果这时我们不及时调整我们的设计,而是将所有的程序都硬塞进“开票业务类”,那么程序质量必然会退化。“开票业务类”由原有的数十行,激增到数百行,甚至上千行。这时的代码将难于阅读,维护它将变成一种痛苦,毫无乐趣可言。
面对这样的状况,我们应当怎样走出困境呢?毫无疑问,就是重构,软件的重构。开票前的校验真的属于“开票业务类”吗?它们是否应当被提取出来,解耦成一个一个的校验类。正常开票与非正常开票真的应该写在一起吗?是否我们应当把“开票业务类”抽象成接口,以及正常开票与非正常开票的实现类。这就是我给大家的良方:当软件因为需求变更而开始渐渐退化时,运用软件重构改善我们的结构,使之重新适应软件需求的变化。
然而,在这个令人振奋的软件工业时代,处于时代中心的各大软件企业却令人沮丧。软件规模越来越庞大,软件结构越来越复杂的同时,却是软件质量越来越低下,软件维护变得越来越困难,以至于每个小小的变更都变得需要伤筋动骨。研发人员为此举足无措,测试人员成为唯一的救星,每个小小的变更都需要付出巨大代价进行测试。软件企业在这样一种恶性循环中苦苦支撑。毫无疑问,这也成为这个令人振奋的时代的另一个特征。
是的,面对软件工业时代我们并没有做好准备。过去,一套软件的生命周期不过2~3年时间,随着软件需求的变化,我们总是选择将软件推倒了重新开发,但是现在这样的情况在发生着改变。随着软件规模的扩大,软件数据的积累,软件影响力的提升,我们,以及我们的客户,都真切地感受到,要推倒一套软件重新开发,将变得越来越困难而不切实际。这样的结果就是,我们的软件将不停地修改、维护、再修改、再维护……直到永远。这是一件多么痛苦的事情啊!
一套软件,当它第一次被开发出来的时候,一切都十分清晰:清晰的业务需求、清晰的设计思路、清晰的程序代码。但经历了几次需求变更与维护以后,一切就变得不那么清晰了。业务需求文档变得模糊不清,设计思路已经跟不上变更的脚步,程序代码则随着业务逻辑的复杂而臃肿不堪。程序员开始读不懂代码,软件开发工作变得不再是一种乐趣。
随着时间的推移,软件经过数年、数十次的变更与维护,情况变得越来越糟。最初的程序员已经不愿再看到自己的代码而选择离去。他的继任者们变得更无所是从,由于看不懂程序,代码的每一次修改如同在走钢丝。测试人员变成了唯一的希望,开发人员的每一次修改都意味着测试人员需要把所有程序测试一遍。继任者们开始质问最初的设计者们,程序是怎么设计的。如果此时恰巧又有什么新技术出现,就会更显得原有系统的破旧与不堪。
相信这就是软件工业时代的所有企业都不得不面对的尴尬境地。难倒真的是我们最初的设计错了吗?是的,我们都这样质问过我们自己,因此我们开始尝试在软件设计之初投入更多的精力。我们开始投入更多的时间作需求调研,考虑更多可能的需求变化,做更多的接口,实现更加灵活但复杂的设计。然后呢,我们解决了我们的问题了吗?显然是没有。需求并没有像我们想象的那样发生变更:我们之前认为可能发生的变更并没有发生,使我们为之做出的设计变成了摆设;我们之前没有考虑到的变更发生了,让我们猝不及防,软件质量开始下降,我们被打回了原形。难倒真的是无药可解了吗?在我看来,如果我们没有看明白软件开发的规律与特点,那么我们永远找不到那份向往已久的解药。现在,让我们真正静下心来分析分析软件开发的规律与特点吧。
软件,特别是管理软件,其实质是对真实世界的模拟。我们通过对真实世界的模拟,实现计算机的信息化管理,来提高我们的生产效率。然而,真实的世界复杂而多变的,我们认识世界却是一个由简单到复杂循序渐进的过程,这是一个我们无法改变的客观规律。因此,毫无疑问,遵循着这样一个客观规律,我们的软件开发过程必然也是一个由简单到复杂循序渐进的过程。
最初,我们开发的是一个对真实世界最简单、最主要、最核心部分的模拟。因为简单,我们的思路变得清晰而明了。但是,我们的软件不能永远只是模拟那些最简单、最主要、最核心的部分。我们的客户在使用软件的过程中,如果遇到那些不那么简单、不那么主要、不那么核心的情况时,我们的软件就无法处理了,这是客户无论如何不能接受的。因此,但软件的第一个版本交付客户以后,客户的需求就开始变更。
客户的需求永远不会脱离真实世界,也就是说,真实世界不存在的事物、现象、关系永远都不可能出现在软件需求中。但是,真实世界的事物、规则与联系并不是那么的简单与清晰的。随着我们的软件对它模拟得越来越细致,程序的业务逻辑开始变得不再那么清晰而易于理解,这就是软件质量下降最关键的内因。
任何一个软件的设计,总是与软件的复杂度有密切的关系。举例来说吧,客户资料是许多系统都必须要记录的重要信息。起初,我们程序简单,客户资料只记录了一些简单的信息,如客户名称、地址、电话等等,但随着程序复杂度的增加,客户资料开始变得复杂。比如,起初“地址”字段就仅仅需要一个字符串就可以了,但随着需求的变更,它开始有了省份、城市、地区、街道等信息。随后还会有邮政编码、所属社区、派出所等信息。起初增加一个两个字段时我们还可以在“客户信息表”里凑合一下,但后来我们必须要及时调整我们的设计,将地址提取出来单独形成一个“地址信息表”。如果不及时予以调整,“客户信息表”将越来越臃肿,由10来个字段,变成50个、80个、上100个……
信息表尚且如此,业务操作更是如此。起初的业务操作是如此的简单而明了,以至于我们不需要花费太多的类就可以将它们描述清楚。比如开票操作,最初的需求就是将已开具的票据信息读取出来,保存,并统计出本月开票量及金额。这样一个简单操作,设计成一个简单的“开票业务类”合情合理。但随后的业务逻辑变得越来越复杂,我们要检查客户是否存在、开票人是否有权限、票据是否还有库存,等等。起初的开票方式只有一种,但随着非正常开票的加入,开票方式不再单一,而统计方式也随之变化……随着业务的不断增加,软件代码的规模也在发生着质的变化。如果这时我们不及时调整我们的设计,而是将所有的程序都硬塞进“开票业务类”,那么程序质量必然会退化。“开票业务类”由原有的数十行,激增到数百行,甚至上千行。这时的代码将难于阅读,维护它将变成一种痛苦,毫无乐趣可言。
面对这样的状况,我们应当怎样走出困境呢?毫无疑问,就是重构,软件的重构。开票前的校验真的属于“开票业务类”吗?它们是否应当被提取出来,解耦成一个一个的校验类。正常开票与非正常开票真的应该写在一起吗?是否我们应当把“开票业务类”抽象成接口,以及正常开票与非正常开票的实现类。这就是我给大家的良方:当软件因为需求变更而开始渐渐退化时,运用软件重构改善我们的结构,使之重新适应软件需求的变化。