KISS和YAGNI是否与越来越复杂的模式和实践，如SOA、DDD、IoC、MVC、POCO、MVVM的趋势不一致？

Question

在我看来，敏捷方法论鼓励我们保持简单和精简，在需要之前不要增加复杂性和成熟度。但技术变革的速度和数量鼓励使用越来越抽象、复杂和复杂的工具和模式来解决我们可能还没有(也可能永远不会遇到)的问题，这些问题具有重要的学习曲线和大量的努力投资。

Answer 1

是KISS和YAGNI与越来越复杂的趋势相左...

汽车有一个加速器和一个刹车，还有一个可以左转和/或右转的方向盘:什么时候使用由司机决定。

Answer 2

我将保持我的答案简短，让专家们更好地展示出来……

我想这个吻适用于你列出的所有东西。你提到了不断增加的抽象性和复杂性，我认为这是相互平衡的。

我们今天开发的系统肯定是复杂的，因为在大多数情况下，复杂问题的解决方案本质上是复杂的。然而，为了保持的简单性，我们使用了抽象。即使我们的复杂系统是由八层构建的，我们也可以通过保持每一层的简单来遵循KISS。

例如，要从列表中选择一两个项目：

• SOA并不复杂，因为我们可以将服务调用包装在包装器对象中。这个对象处理连接并进行调用，这很容易做，因为它们只是传递参数。
• MVC并不复杂，因为我们清楚地分离了我们的逻辑。我们有一个简单的控制器来引导请求和设置数据，一个简单的模型来表示我们的域，还有一个简单的视图来显示传递给它的任何数据。

然而，在这两种情况下，模式作为一个整体(或者系统，如果您愿意)是复杂的，并且不是微不足道的。事实是，我们一次只考虑一个小的、简单的部分，然后将它们组合在一起，这让我们在工作时保持我们的心理模型。

Answer 3

我同意ChrisW's answer的观点。

我们的想法是尽可能地坚持使用KISS和YAGNI，但是当需要出现并且你需要一个复杂/复杂的解决方案时，站在巨人的肩膀上，使用经过验证的模式来指导你。这些模式和实践旨在简化您的工作，如果使用它们比hack替代方案更难，您应该坚持hack。只要确保你考虑到了可维护性等。

举个例子，当你建立一个网站的第一个版本时，它可能只包含1到2个主要功能和几个页面。为此，您可能不需要MVC (尽管以这种方式开始可能很好)，但是，在您添加了更多功能，并且您有几十个页面要管理，以及如何在它们之间共享功能之后，很明显，您需要MVC来更好地构建您的应用程序。

类似地，如果您从一开始就知道您将不得不处理一些事情，比如返回公共数据的多个视图，那么MVC通过为您提供一个可遵循的模式来简化您的问题。

总而言之，YAGNI现在，但如果你以后需要它，那就使用一个已知的模式/解决方案来接吻。