在我看来，敏捷方法鼓励我们保持简单，精益，而不是在需要之前增加复杂性和复杂性。但是，技术变革的速度和数量鼓励使用越来越抽象，复杂和复杂的工具和模式，以复杂的方式解决我们可能尚未（并且可能永远不会遇到）的问题，这些问题包括重要的学习曲线和大量的投入。
答案 0 :(得分：11)
KISS和YAGNI是否与趋势越来越复杂......
汽车有一个加速器和一个制动器，一个可左转和/或右转的方向盘：由驾驶员决定何时使用。
答案 1 :(得分：4)
我会保持答案简短，让专家更好地说明......
我认为KISS适用于您列出的所有内容。你提到了越来越多的抽象和复杂性，我认为这是相互平衡的。
我们今天开发的系统必须很复杂，因为在大多数情况下，复杂问题的解决方案本身就很复杂。但是，为了保持简单，我们使用抽象。即使我们的复杂系统是用8层构建的，我们也可以通过保持每一层简单来跟随KISS。
例如，从列表中选择一两项：
但是，在这两种情况下，整个模式（或系统，如果你愿意） 是复杂且不平凡的。事实上，我们一次只考虑一个小的，简单的部分，然后将它们组合在一起，这样我们就可以在工作时保持我们的心理模型。
答案 2 :(得分：3)
我同意ChrisW's answer。
我们的想法是尽可能地坚持使用KISS和YAGNI，但是当需要时，你需要一个复杂/复杂的解决方案，站在巨人的肩膀上，并使用经过验证的模式来指导你。这些模式和实践旨在简化您的工作，如果使用它们比黑客替代方案更难，您应该坚持使用黑客。只要确保你考虑到可维护性等。
例如，当您构建网站的第一个版本时，它可能包含1或2个主要功能，只有几页。你可能不需要MVC（即使这样开始也许不错） 但是，在添加更多功能并且需要管理数十个页面以及如何在它们之间共享功能之后，您可能需要使用MVC来更好地构建应用程序。
同样地，如果从开始你知道你将不得不处理诸如返回一个共同数据的多个视图之类的事情，MVC通过为你提供一个模式来简化你的问题。
总之，YAGNI现在，但如果您以后需要它，那么使用已知的模式/解决方案KISS。
答案 3 :(得分：3)
叹息。
我们必须拥有越来越复杂和抽象的组件，以满足日益复杂的软件需求。
我们大多数人的脑空间有限。我们必须学会通过使用更复杂的抽象来应对我们有限的大脑。
替代方案不是使用抽象，而是将自己局限于机器代码。
请阅读http://www.cs.utexas.edu/~EWD/transcriptions/EWD01xx/EWD117.html
“尽管存在各种不足， 数学推理提出了一个 如何把握的优秀模特 非常复杂的结构 一个容量有限的大脑。它 似乎值得调查 这些经过验证的方法在多大程 被移植到计算机艺术 用法。在编程设计中 一个人可以让自己成为的语言 主要是通过考虑“什么 机器可以做“。考虑到， 然而，那是编程语言 是用户和用户之间的桥梁 机器 - 事实上，它可以 被视为他的工具 - 似乎只是 同样重要的是要考虑到 考虑“人类可以思考什么”。它 我们将继续这样做 我们的调查。“
答案 4 :(得分：2)
我要做出主观回答（所以起诉我）。我认为，如果你按首字母缩略词编程，那么你将遇到麻烦。
在一天结束时，你正试图为一个企业赚钱，或者希望自己。因此，您做出的每项决策都是基于成本，时间和收益的工程决策。您必须评估技术在实施，维护等方面的使用，并做出最佳选择。
我认为唯一合理的答案是所选择的工具和技术必须与工程的预期目标相匹配。
答案 5 :(得分：1)
这是正确工作的正确工具。问题是建筑师和/或开发人员开始相信特定的方法或技术是“金锤”。那就是当事情变得宗教化，宗教和理性不能很好地融合在一起时;）
哦，顺便说一下，“敏捷”并不一定意味着你不使用你提到的一些缩略词，或者一些实现它们的框架。这些决定通常是在实现开发人员与敏捷相关联的各种事物之前做出的，例如，用户故事，冲刺等。
答案 6 :(得分：1)
首先，首字母缩略词列表并不一定有意义 - 例如，POCO并不比POCO简单得多......
但是，在许多情况下，通过使用IoC，MVC和MVVM等概念，KISS和YAGNI可以最有效地实现 - 只要您正确使用模式。
模式本身并不复杂。可能需要一些学习才能理解模式试图完成的内容，但通常，模式的存在纯粹是为了简化代码，维护或可用性 - 通常都是以上所有。例如，这非常适合保持简单。
答案 7 :(得分：1)
但是，在测试和重构代码时，某些模式（如Ioc）将帮助您实现可测试性和干燥（不要重复自己）等目标。如果您熟悉设计模式，可以在适当的时候应用它们。
答案 8 :(得分：-1)
是
- 这个空间故意留空 -