KISS 和 YAGNI 是否与 SOA、DDD、IoC、MVC、POCO、MVVM 等日益复杂的模式和实践的趋势不一致？
在我看来，敏捷方法鼓励我们保持事情简单、精益，并且在需要之前不要增加复杂性和复杂性。但技术变革的速度和规模鼓励使用越来越抽象、复杂和精密的工具和模式，以复杂的方式解决我们可能尚未（也可能永远不会遇到）的问题，并需要显着的学习曲线和大量的努力投入。
It seems to me that Agile methodologies encourage us to keep things simple, and lean, and not add complexity and sophistication until its needed. But the pace and volume of technology change encourages the use of increasingly abstract, complex and sophisticated tools and patterns to solve problems that we may not have yet (and may never encounter) in complex ways with significant learning curves and significant investments of effort.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
叹。
我们必须拥有日益复杂和抽象的组件来满足日益复杂的软件的需求。
我们大多数人的大脑空间都是有限的。我们必须学会通过使用更复杂的抽象来应对我们有限的大脑。
另一种选择是不使用抽象，将我们限制在机器代码中。
请阅读http://www.cs.utexas.edu/~ EWD/转录/EWD01xx/EWD117.html
Sigh.
We must have increasingly sophisticated and abstract components to match the demand for increasingly sophisticated software.
Most of us have limited brain space. We must learn to cope with our limited brains by using more sophisticated abstractions.
The alternative is not using abstractions, limiting ourselves to machine code.
Please read http://www.cs.utexas.edu/~EWD/transcriptions/EWD01xx/EWD117.html
我要做一个主观的回答（所以起诉我）。我认为如果您使用缩写词进行编程，那么您将会遇到麻烦。
归根结底，你是在努力为企业赚钱，或者希望为自己赚钱。因此，您做出的每个决策都是基于成本、时间和收益的工程决策。您必须评估技术的使用、实施、维护等成本，并做出最佳选择。
我认为唯一公平的答案是所选择的工具和技术必须与工程的预期目标相匹配。
I'm going to make a subjective answer (so sue me). I think that if you program by acronyms then you are going to run into trouble.
At the end of the day you are trying to make money for a business, or hopefully yourself. As such each decision you make is an engineering decision based on cost, time and benefits. You have to evaluate the use of a technique on the cost of implementation, maintenance etc, and make the best choice.
I think the only fair answer is that the tools and techniques chosen have to match with the desired goal of the engineering.
关键在于为正确的工作使用正确的工具。问题是当架构师和/或开发人员开始相信某种特定的方法或技术是“金锤子”时。那就是当事情变得宗教化的时候，宗教和理性不能很好地结合在一起;)
哦，顺便说一句，“敏捷”并不一定意味着你不使用你提到的一些缩写词，或者一些实现它们的框架。这些决策通常是在实施开发人员与敏捷相关的事物（例如用户故事、冲刺等）之前就做出的。
Its a matter of the right tool for the right job. The problem is when architects and/or developers begin to believe that a particular methodology or technology is a "golden hammer." That is when things become religious, and religion and reason do not play nicely together ;)
Oh and by the way, "agile" does not necessarily mean you don't use some of the acronyms you mention, or some framework that implements them. Those decisions are usually made far in advance of implementing the sorts of things that developers have come to associate with agile, e.g. user stories, sprints, etc.
首先，首字母缩略词列表并不一定有意义 - 例如，没有比 POCO 简单得多的东西......
但是，在许多情况下，通过使用 IoC、MVC 等概念，可以最有效地实现 KISS 和 YAGNI，和 MVVM - 只要您正确使用模式。
模式本身并不复杂。可能需要一些学习才能理解模式试图实现的目标，但通常，模式的存在纯粹是为了简化代码、维护或可用性 - 通常是以上所有内容。例如，这与“保持简单”完美契合。
First off, the list of acronyms doesn't really necessarily make sense - there's not really much simpler than POCO, for example...
However, KISS and YAGNI are achieved most effectively, in many circumstances, by using concepts like IoC, MVC, and MVVM - provided you use the patterns correctly.
Patterns aren't complicated, in and of themselves. It may take a bit of learning to understand what the pattern is trying to accomplish, but often, a pattern exists purely to simplify either code, maintenance, or usability - and usually all of the above. This fits in perfectly with keep it simple, for example.
恕我直言，您（通常）不想从复杂的设计开始。这可能是本地方法而不是服务吗？我还需要 IoC 容器吗？当涉及到设计模式时，这一点尤其重要。
但是，当您测试和重构代码时，某些模式（例如 Ioc）将帮助您实现可测试性和 DRY（不要重复自己）等目标。如果你很了解设计模式，你就可以在适当的时候应用它们。
IMHO, you (generally) don't want to start out with a complicated design. Could this be a local method rather than a service? Do I need an IoC container yet? This is particularly relevant when it comes to design patterns.
However, as you test and refactor your code, certain patterns (such as Ioc) will help you to achieve goals such as testability and DRY (Don't Repeat Yourself). If you know design patterns well, you can apply them at the appropriate time.
是的
——这个空间故意留空——
yes
-- this space intentionally left blank --
汽车有一个加速器和一个制动器，以及一个可以向左和/或向右转动的方向盘：这取决于驾驶员来决定何时使用哪个。
A car has an accelator and a brake, and a steering wheel that can turn left and/or right: it's up to the drivers to decide which to use when.
我会保持我的答案简短，让专家更好地阐述......
我认为 KISS 适用于您列出的所有内容。你提到增加抽象性和复杂性，我认为这可以相互平衡。
我们今天开发的系统一定很复杂，因为大多数时候，复杂问题的解决方案本身就是复杂的。然而，为了保持事情简单，我们使用抽象。即使我们的复杂系统是由八层构建的，我们也可以遵循 KISS，保持每一层简单。
例如，从列表中选择一两项：
然而，在这两种情况下，整个模式（或者系统，如果你愿意的话）都是复杂且不平凡的。事实上，我们一次考虑一个小的、简单的部分，然后将它们组合在一起，这让我们在工作时保持我们的思维模型。
I'll keep my answer short and let the experts lay it out better...
I think that KISS applies to everything you listed. You mention increasing abstraction and complexity, which, I think, balance eachother.
The systems we are developing today must be complex, because, most of the time, the solution to a complex problem is inherently complex. However, to keep things simple, we use abstraction. Even if our complex system is built with, say, eight layers, we can follow KISS by keeping each layer simple.
For instance, to pick an item or two off your list:
However, in both of these cases, the pattern as a whole (or the system, if you will) is complex and non-trivial. It is the fact that we consider small, simple parts one at a time, and then fit them together, that lets us maintain our mental model as we work.
我同意 ChrisW 的回答。
我们的想法是尽可能坚持使用 KISS 和 YAGNI，但是当需要出现并且您需要复杂的解决方案时，请站在巨人的肩膀上并使用经过验证的模式来指导您。这些模式和实践旨在简化您的工作，如果使用它们比 hack 替代方案更难，您应该坚持使用 hack。只要确保考虑到可维护性等即可。
例如，当您构建网站的第一个版本时，它可能包含 1 或 2 个主要功能和几个页面。您可能不需要 MVC（尽管以这种方式开始可能会很好）
但是，在添加更多功能并且有数十个页面需要管理以及如何在它们之间共享功能之后，您可能会明显地需要 MVC 来更好地构建应用程序。
类似地，如果您从一开始就知道必须处理诸如返回公共数据的多个视图之类的问题，那么 MVC 会通过制定供您遵循的模式来简化您的问题。
总之，现在使用 YAGNI，但如果您稍后需要它，则可以使用已知的模式/解决方案来 KISS。
I agree with ChrisW's answer.
The idea is to stick with KISS and YAGNI as much as possible, but when the need arises and you need a sophisticated / complex solution, stand on the shoulders of giants and use proven patterns to guide you. These patterns and practices are meant to simplify your work, if using them is harder than the hack alternative, you should stick with the hack. Just make sure you take into account maintainability etc.
As an example, when you build the 1st version of a website it may consist of 1 or 2 main functionalities and just a few pages. You probably don't need MVC for this (even though it might be nice to start that way)
BUT, after you add a few more features and you have dozens of pages to manage along with how to share functionality between them, it might become apparent that you need MVC to better structure your application.
Similarly, if from the get go you know you will have to deal with something like returning multiple views of a common piece of data, MVC simplifies your problem by laying out a pattern for you to follow.
In summary, YAGNI now, but if you need it later then KISS by using a known pattern / solution.