我敢肯定，我们大多数人都熟悉项目需求在启动后发生变化的概念，这变得越来越成为一个问题，客户对事情的工作方式了解得越少，我们与他们的合作就越紧密。

那我该如何设计一个系统(特别是一个网站，但一般的建议可能是最好的选择)，以便进行较小的更改，是否有任何编程策略可以解决此问题？

解决方案

我认为最大的事情是确保我们拥有一个全面的测试套件。这样，我们可以在需要时放心地进行更改，并知道何时发生更改。

我建议为我们选择的语言使用经过验证的框架。大多数好的框架都将被设计来适应多种场景。

所有正常的oo原则都适用于此，减少耦合，增加内聚力，不要重复自己等等。这将确保我们具有灵活且可扩展的代码库。

除此之外，请勿尝试先发制人。在任何地方使用YAGNI(我们将不会需要它)。只构建我们知道用户需要的东西。不要构建我们认为需要的东西。我们更有可能猜错了，然后我们可能会碰到很多这样的代码。

首先，我们应该确定变化可能性高的方面。这些方面应"抽象化"。一个经典的例子是我们网站的样式(即通过CSS)。但是我们甚至可以定义一个" presenter"类来布置网页的特定元素。

困难的是正确估计变化的可能性。但这取决于你:)

没有PHP经验的人，请花点时间看一下。

但这全都在于知道变革将到来。因此，当我们进行编码并开始希望破解这些东西以完成工作时，停下来思考"如果我需要再次更改此内容，该怎么办？"。

现在，我知道php是一种脚本语言，但是我们必须能够关闭代码库，对吗？那是最好的事情，在大多数情况下，要进行1到2个方法调用，请保持UI(网页)尽可能的浅。

如果我们有精美的渲染逻辑，请对其进行存储。创造出常见的漂亮外观吗？查看可能发生的变化(配色方案等)，将其存储起来。我们已经将所有核心代码都放入了库中，对吗？ ;)

如果我们一直在构建库，那么在收到更改请求时，我们需要做的就是"为其找到合适的书"。我们要做的很酷的事情是，如果书写得好，我们可以轻松地给它添加注释;)

这基本上就是我目前正在做的事情，我的"项目"是建立将来的应用程序将要使用的平台，所以这实际上是我的主要重点。 :)

更新

Mendelt在应用YAGNI时很好地指出了上述几点，不要只是将内容写到库中，而是如果我们想一秒钟就可以重新使用刚创建的性感小表(因为客户想要)， ，那么该是时候考虑使其更加实用了。对于一次性客户端的一些晦涩功能应临时完成。

好吧，我会尝试从另一侧解决这个问题：

与客户/用户进行更多的交流。

我本人曾去过那里，编写不需要或者无法正确通信的程序，并且必须重做许多代码。通过更多的交流或者更确切地说是可以避免的：通过更多正确的交流。

除此之外：
允许用户更改颜色并不时问他们，在哪里放置按钮以及可能性，他们将对这种"出色的控制水平"感到满意。然后他们不希望我们重做真实功能。是的，我对此很讽刺。

这就是框架起作用的地方。

如果所有基线，背景，一切照旧都在框架中，那么应用程序就是扩展，特殊情况和添加组件。

该框架已经为变更而设计和构建。我们要做的就是框架设计要接受的更改。

发生更改时，我们将通过修改框架配置和重写插入框架的内容的组合来响应更改。我们可以通过不关注默认的背景材料来应对变化。将其委托给其他人-框架作者。