需求变更是罪恶之源吗？

我们身处软件工业时代这个令人振奋的时代，却面临着遗留系统这个令人尴尬的难题。事情总是这样的：软件最开初开发的时候总是非常清晰，清晰的需求、清晰的设计、清晰的代码，清晰的程序结构让人赏心悦目，甚至有些自我陶醉。随后，软件开始需求变更，每变更一次软件的质量就下降一次。这样，软件经过数次的变更以后，需求文档变得模糊不清，设计思路跟不上变更的脚步，程序代码则随着业务逻辑的复杂而臃肿不堪，程序员开始读不懂代码，软件开发工作变得不再是一种乐趣。随着时间的推移，经过数年、数十次的需求变更，情况变得越来越糟，软件质量像滚雪球一样直线下降。难道需求变更就是软件变糟的罪恶之源吗？

然而这不是真相，这是一个真实的谎言。如果我们不明白软件发展的规律，我们是不可能明白其背后的真相。软件，特别是管理软件，其实质是对真实世界的模拟。我们通过对真实世界的模拟，实现计算机的信息化管理，来提高我们的生产效率。然而，真实的世界复杂而多变的，我们认识世界却是一个由简单到复杂循序渐进的过程，这是一个我们无法改变的客观规律。因此，毫无疑问，遵循着这样一个客观规律，我们的软件开发过程必然也是一个由简单到复杂循序渐进的过程。

最初，我们开发的是一个对真实世界最简单、最主要、最核心部分的模拟。因为简单，我们的思路变得清晰而明了。但是，我们的软件不能永远只是模拟那些最简单、最主要、最核心的部分。我们的客户在使用软件的过程中，如果遇到那些不那么简单、不那么主要、不那么核心的情况时，我们的软件就无法处理了，这是客户无论如何不能接收的。因此，但软件的第一个版本交付客户以后，客户的需求就开始变更。

客户的需求永远不会脱离真实世界，也就是说，真实世界不存在的事物、现象、关系永远都不可能出现在软件需求中。但是，真实世界的事物、规则与联系并不是那么的简单与清晰的。随着我们的软件对它模拟得越来越细致，程序的业务逻辑开始变得复杂而不再那么清晰、易于理解，这就是软件质量下降最关键的内因。

任何一个软件的设计，总是与软件的复杂度有密切的关系。简单软件有简单软件的设计，复杂软件有复杂软件的设计，它们是不一样的。但是，软件的发展规律却是一个由简单软件转变为复杂软件的过程。正因为如此，我们最初的设计通常是简单软件的设计，然而随着软件复杂度的提升，我们是否调整过我们的设计，向复杂软件的设计过渡呢？非常遗憾的是，通常情况却不是这样，起初进行简单软件设计以后，虽然软件在越来越复杂，但开发人员没有通过重构对软件结构进行调整，而是就着简单软件的设计，添加复杂的程序逻辑。这才是所有遗留系统面临的真正问题：不是因为软件需求在变更，而是因为当需求变更以后，软件业务逻辑在变得越来越复杂时，我们没有通过系统重构调整原有的系统结构，以适应新的需求。正因为如此，我们的遗留系统将变得越来越难懂，越来越难于维护，任何一项变更都成本巨大。

说了这么多，你也许还没有什么感觉。举例来说吧，客户资料是许多系统都必须要记录的重要信息。起初，我们程序简单，客户资料只记录了一些简单的信息，如客户名称、地址、电话等等，但随着程序复杂度的增加，客户资料开始变得复杂。比如，起初“地址”字段就仅仅需要一个字符串就可以了，但随着需求的变更，它开始有了省份、城市、地区、街道等信息。随后还会有邮政编码、所属社区、派出所等信息。起初增加一个两个字段时我们还可以在“客户信息表”里凑合一下，但后来我们必须要及时调整我们的设计，将地址提取出来单独形成一个“地址信息表”。如果不及时予以调整，“客户信息表”将越来越臃肿，由10来个字段，变成50个、80个、上100个……

信息表尚且如此，业务操作更是如此。起初的业务操作是如此的简单而明了，以至于我们不需要花费太多的类就可以将它们描述清楚。比如开票操作，最初的需求就是将已开具的票据信息读取出来，保存，并统计出本月开票量及金额。这样一个简单操作，设计成一个简单的“开票业务类”合情合理。但随后的业务逻辑变得越来越复杂，我们要检查客户是否存在、开票人是否有权限、票据是否还有库存，等等。起初的开票方式只有一种，但随着非正常开票的加入，开票方式不再单一，而统计方式也随之变化……随着业务的不断增加，软件代码的规模也在发生着质的变化。如果这时我们不及时调整我们的设计，而是将所有的程序都硬塞进“开票业务类”，那么程序质量必然会退化。“开票业务类”由原有的数十行，激增到数百行，甚至上千行。这时的代码将难于阅读，维护它将变成一种痛苦，毫无乐趣可言。

面对这样的状况，我们应当怎样走出困境呢？毫无疑问，就是重构，软件的重构。开票前的校验真的属于“开票业务类”吗？它们是否应当被提取出来，解耦成一个一个的校验类。正常开票与非正常开票真的应该写在一起吗？是否我们应当把“开票业务类”抽象成接口，以及正常开票与非正常开票的实现类。这就是我给大家的良方：当软件因为需求变更而开始渐渐退化时，运用软件重构改善我们的结构，使之重新适应软件需求的变化。（续）

相关文档
遗留系统：IT攻城狮永远的痛
需求变更是罪恶之源吗？
系统重构是个什么玩意儿
我们应当改变我们的设计习惯
小步快跑是这样玩的（上）
小步快跑是这样玩的（下）
代码复用应该这样做（1）
代码复用应该这样做（2）
代码复用应该这样做（3）
做好代码复用不简单（1）

特别说明：希望网友们在转载本文时，应当注明作者或出处，以示对作者的尊重，谢谢！

系统重构,是老板问题。

大部分程序员都是很愿意与时俱进，都愿意没事重构下系统什么的。

但是绝大部分老板不愿意。

系统重构，
对甲方来说，原有系统不是还能用吗？干嘛要重构，干嘛要多付钱了，甲方不干。
对乙方来说，改改就好了，干嘛重构，费钱费功夫，等系统实在跑不动了再忽悠甲方做个新的，还能再捞一票，乙方不干。

两边老板都没这想法，你一搞技术的折腾个什么劲。

当初我遇到一个问题，
我们系统服务器 都是将就着用，领导舍不得投钱，在会议上，领导直接就说 我花钱直接顾一个毕业生，每月4000，都比买服务器这些省钱。

后来一个老大给我说，领导都是这样的，技术部本身就是一个烧钱的部门，不会有那么直观的经济的体现，这时候你就应该提出方案来说服领导给你投钱，我加服务器，性能上的优化，用户体验上的提升等等，可以拿数据说话。

拿系统重构来说，

你要拿出一套方案来说明，不重构会面临什么样的问题，需要的多少的人力财力来维持这样的状况，如果重构那将减少多少的浪费，能够避免什么可怕的后果等等。你要拿出可靠的依据来让领导相信重构的好处。

需求最重要的是要挖掘，如果模型被你挖掘得差不多了，就算需求里面某些功能没做，也不影响设计出能响应变更的业务模型。

系统重构的目的不是为了解决需求变更的吧！
重构是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性；而需求变更等于变相的增加了新的功能。

重构的目的是为了更好地应对需求变更，但重构方法却要求我们不要为系统添加新的功能，这确实比较矛盾。但你理解了重构中“两顶帽子”的设计方式，你就明白啦！

“两顶帽子”的设计方式要求我们，当软件需要变更时，第一步先不要为其变更，而是重构现有程序结构以适应新的需求，然后再添加新的功能。

“两顶帽子”是一种设计方式的变革，它让我们能够做出正确的设计以提高代码质量。关于它后面还会详细讨论。

老板对于这个问题的态度一般有2个阶段，第一阶段是没有必要为其投入，但当软件维护越来越困难，投入成本越来越高，维护风险越来越大时，开始进入第二阶段，老板开始犹豫是不是应该重构了，怎么重构？

的确是这样。
不过天朝99.99%的老板在进入第二阶段之前，已成功转战房地产和高利贷产业了。