《设计模式解析（第2版•修订版）》—第1章 1.3节需求问题

本节书摘来自异步社区《设计模式解析（第2版•修订版）》一书中的第1章，第1.3节需求问题，作者【美】Alan Shalloway（艾伦•沙洛维） , James R.Trott（詹姆斯•R.特罗特），更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.3 需求问题
设计模式解析（第2版•修订版）
需求总在变化

问问软件开发人员，对于从用户那里获取的需求，他们认为有哪些说法正确。他们经常像下面这样回答。

需求是不完整的。
需求经常是错误的。
需求（和用户）容易让人误解。
需求并不会告诉你全部情况。
只有一种回答你是听不到的：“我们的需求不仅完整、清晰、易于理解，而且还说明了我们今后五年需要的所有功能！”

在30年编写软件的经历中，关于需求我所学会的主要一点就是，需求总在变化。

我还了解到，大多数开发人员都认为这是一件坏事。但是很少有人能够编写可以很好地处理需求变更的代码。

需求之所以变化，有如下几个简单原因。

用户对自己需求的看法，会因为与开发人员的讨论以及看到软件新的可能性而发生变化。
开发人员对用户问题领域的看法，会在开发使该领域自动化的软件的过程中，因为对它更加熟悉而发生变化。
我可能无法知道什么将会变化，但是我能够猜到在哪里会变化

在刚入行的时候，我有一个师傅总爱说：“第二次既然总能编写正确，你第一次也应该能编写正确！”我经常会想起这条忠告。我曾经认为这句话的意思是尝试预期所有可能发生的变化，并相应地构建代码。这当然再好不过，但是通常结果都会令人失望的，因为很少能够预测整个过程所有可能的变化。

最后，我认识到，虽然无法预测会发生什么变化，但是通常可以预期哪里会发生变化。面向对象的巨大优点之一，就是可以封装这些变化区域，从而更容易地将代码与变化产生的影响隔离开来。
软件开发的环境发生了变化。（5年前谁能想到Web开发能有今日？）

这并不意味着我们可以不去收集好的需求。这只是说明我们编写的代码必须要能适应变化，说明我们（可能还有我们的客户）不应该为阻止那些自然而然会发生的事情而庸人自扰。

发生变化了！从容应对

在所有情况下（最简单的除外），需求总会变化的，无论最初的分析做得多好！

与其抱怨需求总是变化，不如改变开发过程，从而更有效地应对变化。

代码可以设计得使需求的变化不至于产生太大影响。代码可以逐步演进，新代码可以影响较少地加入。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。