您如何处理复杂性跳跃？
似乎很少见，但经常遇到的经验是，有时您正在从事一个项目，突然间突然出现一些意外情况，在工作中投入了大量的扳手，并极大地提高了复杂性。 例如，我正在开发一个与其他各种机器上的SOAP服务通信的应用程序。我提出了一个效果很好的原型，然后继续开发常规前端，并以一种不错，相当简单且易于遵循的方式来启动和运行所有东西。直到我们开始在更广泛的网络上进行测试，突然页面开始超时，因为连接的延迟和在远程计算机上执行计算所需的时间导致对Soap服务的请求超时后，它才开始工作。事实证明，我们需要更改架构以将请求转出到自己的线程上并缓存返回的数据，以便可以在后台逐步更新它，而不是根据请求逐个执行计算。 这种情况的细节不是太重要-确实不是一个很好的例子，因为它是可以预见的，并且为这种环境编写过很多此类应用的人可能已经预料到了-除了它说明了一种方式可以从简单的前提和模型开始，然后突然将复杂性升级到项目的开发中。 您有什么策略来应对这些类型的功能更改，这些功能更改的出现通常是环境因素而不是规格更改的结果，而在开发过程的后期或测试的结果是？在避免过早优化/ YAGNI /过度设计设计解决方案的风险之间，如何设计解决方案来缓解可能（但不一定是）可能的问题，而不是开发一个可能更有效但又没有针对此问题准备更简单的解决方案，这两者之间如何平衡？一切可能的事情？ 编辑：疯狂的埃迪的答案包括“您吸纳它并找到实现新复杂性的最便宜的方法。” 这让我想到了问题中隐含的东西，但我没有具体提出。 一旦遇到困难，就可以进行必要的更改。您是否执行了使项目尽可能接近进度但可能会影响可维护性的事情，还是回到了体系结构并在更详细的级别上对其进行了重新设计，该级别可能更易于维护，但会在开发过程中推迟一切？