我们身处软件工业时代这个令人振奋的时代，却面临着遗留系统这个令人尴尬的难题。事情总是这样的：软件最开初开发的时候总是非常清晰，清晰的需求、清晰的设计、清晰的代码，清晰的程序结构让人赏心悦目，甚至有些自我陶醉。随后，软件开始需求变更，每变更一次软件的质量就下降一次。这样，软件经过数次的变更以后，需求文档变得模糊不清，设计思路跟不上变更的脚步，程序代码则随着业务逻辑的复杂而臃肿不堪，程序员开始读不懂代码，软件开发工作变得不再是一种乐趣。随着时间的推移，经过数年、数十次的需求变更，情况变得越来越糟，软件质量像滚雪球一样直线下降。难道需求变更就是软件变糟的罪恶之源吗？
然而这不是真相，这是一个真实的谎言。如果我们不明白软件发展的规律，我们是不可能明白其背后的真相。软件，特别是管理软件，其实质是对真实世界的模拟。我们通过对真实世界的模拟，实现计算机的信息化管理，来提高我们的生产效率。然而，真实的世界复杂而多变的，我们认识世界却是一个由简单到复杂循序渐进的过程，这是一个我们无法改变的客观规律。因此，毫无疑问，遵循着这样一个客观规律，我们的软件开发过程必然也是一个由简单到复杂循序渐进的过程。
最初，我们开发的是一个对真实世界最简单、最主要、最核心部分的模拟。因为简单，我们的思路变得清晰而明了。但是，我们的软件不能永远只是模拟那些最简单、最主要、最核心的部分。我们的客户在使用软件的过程中，如果遇到那些不那么简单、不那么主要、不那么核心的情况时，我们的软件就无法处理了，这是客户无论如何不能接受的。因此，但软件的第一个版本交付客户以后，客户的需求就开始变更。
客户的需求永远不会脱离真实世界，也就是说，真实世界不存在的事物、现象、关系永远都不可能出现在软件需求中。但是，真实世界的事物、规则与联系并不是那么的简单与清晰的。随着我们的软件对它模拟得越来越细致，程序的业务逻辑开始变得复杂而不再那么清晰、易于理解，这就是软件质量下降最关键的内因。
任何一个软件的设计，总是与软件的复杂度有密切的关系。简单软件有简单软件的设计，复杂软件有复杂软件的设计，它们是不一样的。但是，软件的发展规律却是一个由简单软件转变为复杂软件的过程。正因为如此，我们最初的设计通常是简单软件的设计，然而随着软件复杂度的提升，我们是否调整过我们的设计，向复杂软件的设计过渡呢？非常遗憾的是，通常情况却不是这样，起初进行简单软件设计以后，虽然软件在越来越复杂，但开发人员没有通过重构对软件结构进行调整，而是就着简单软件的设计，添加复杂的程序逻辑。这才是所有遗留系统面临的真正问题：不是因为软件需求在变更，而是因为当需求变更以后，软件业务逻辑在变得越来越复杂时，我们没有通过系统重构调整原有的系统结构，以适应新的需求。正因为如此，我们的遗留系统将变得越来越难懂，越来越难于维护，任何一项变更都成本巨大。
说了这么多，你也许还没有什么感觉。举例来说吧，客户资料是许多系统都必须要记录的重要信息。起初，我们程序简单，客户资料只记录了一些简单的信息，如客户名称、地址、电话等等，但随着程序复杂度的增加，客户资料开始变得复杂。比如，起初“地址”字段就仅仅需要一个字符串就可以了，但随着需求的变更，它开始有了省份、城市、地区、街道等信息。随后还会有邮政编码、所属社区、派出所等信息。起初增加一个两个字段时我们还可以在“客户信息表”里凑合一下，但后来我们必须要及时调整我们的设计，将地址提取出来单独形成一个“地址信息表”。如果不及时予以调整，“客户信息表”将越来越臃肿，由10来个字段，变成50个、80个、上100个……
信息表尚且如此，业务操作更是如此。起初的业务操作是如此的简单而明了，以至于我们不需要花费太多的类就可以将它们描述清楚。比如开票操作，最初的需求就是将已开具的票据信息读取出来，保存，并统计出本月开票量及金额。这样一个简单操作，设计成一个简单的“开票业务类”合情合理。但随后的业务逻辑变得越来越复杂，我们要检查客户是否存在、开票人是否有权限、票据是否还有库存，等等。起初的开票方式只有一种，但随着非正常开票的加入，开票方式不再单一，而统计方式也随之变化……随着业务的不断增加，软件代码的规模也在发生着质的变化。如果这时我们不及时调整我们的设计，而是将所有的程序都硬塞进“开票业务类”，那么程序质量必然会退化。“开票业务类”由原有的数十行，激增到数百行，甚至上千行。这时的代码将难于阅读，维护它将变成一种痛苦，毫无乐趣可言。
面对这样的状况，我们应当怎样走出困境呢？毫无疑问，就是重构，软件的重构。开票前的校验真的属于“开票业务类”吗？它们是否应当被提取出来，解耦成一个一个的校验类。正常开票与非正常开票真的应该写在一起吗？是否我们应当把“开票业务类”抽象成接口，以及正常开票与非正常开票的实现类。这就是我给大家的良方：当软件因为需求变更而开始渐渐退化时，运用软件重构改善我们的结构，使之重新适应软件需求的变化。（续）
