固体原则与YAGNI

Question

坚实的原则什么时候才能成为YAGNI？

作为程序员，我们总是在复杂性、可维护性、构建时间等方面进行权衡。在我看来，做出选择的两个最明智的准则是坚实的原则和YAGNI。如果你不需要它，不要建造它，保持它干净。

例如，当我看固态酒窝系列时，我看到它从一个相当简单的程序开始，最后变成了一个相当复杂的程序(结束所有坚实的原则都是工作的方式，可以在稍后阶段进行修改。但是，如果要解决的问题是一个非常简单的问题，并且是一个丢弃的应用程序，那么怎么办？还是固守的原则总是适用的？

正如评论中所问的：

• 固体原理
• 雅格尼

Answer 1

从屏幕上判断一种方法总是很困难的，因为为演示而选择的问题通常都非常小，因此应用像SOLID这样的原则很快就会使解决方案看起来完全设计过度了。

我认为坚实的原则几乎总是有用的。一旦你精通了它们，使用它们似乎并不是你必须认真考虑的事情。这就变得很自然了。我见过很多一次性的应用变得更多，所以我现在害怕说我要扔掉一些东西，因为你永远不会知道。

我通常采用的方法是，如果我在为特定任务编写一个简单的应用程序，我有时会放弃大名鼎鼎的原则，转而使用几行有效的代码。如果我发现我回到那个应用程序做进一步的改变，我将花时间使它坚实(至少在某种程度上，因为100%的原则应用很少可行)。

在更大的应用程序中，我从小开始，随着程序的发展，我尽可能地应用坚实的原则。这样，我就不会试图把整个设计提前到最后。对我来说，这是YAGNI和固体共存的好地方。

Answer 2

首先考虑一下眼前的问题。如果你盲目地应用YAGNI或SOLID的原则，你以后可能会伤害到自己。我希望大家都能理解的是，没有“一种”设计方法可以解决所有问题。你可以看到这一点的证据，当一家商店出售的帽子广告为“一刀切”，但它不适合你的头。要么太大要么太小。

相反，最好理解SOLID试图解决的原则和问题，以及YAGNI试图解决的原则和问题。您会发现，一个与应用程序的体系结构有关，另一个与整个开发过程有关。虽然在某些情况下可能有重叠，但它们是明显不同的问题。

YAGNI (你不会需要它，古雅的美国缩略语)关心的是节省开发人员的时间，在一座只有3英尺宽的小溪上增加钢筋加固混凝土基础，而一座更简单的木桥就行了。如果我们跨越一英里宽的河流，需要支撑几辆拖拉机拖车，我们当然需要额外的基础工作。本质上，YAGNI告诉你要着眼于更大的图景和设计，以满足当前的需求。它解决了让事情变得过于复杂的问题，因为我们预测了一些客户尚未确定的潜在需求。

SOLID关注的是我们如何确保桥梁的各个部分适当地结合在一起，并能随着时间的推移而保持。你可以把坚固的原理应用到木桥上，也可以应用于钢加固混凝土桥梁。

总之，这两个概念并不一定是相互冲突的。当你遇到一种情况，你相信他们是，是时候看看大的前景。根据你的结论，你可能决定放弃一部分坚实的原则，或者你可能决定你确实需要它。

Answer 3

当它是一个丢弃的应用程序时，不需要坚实的原则；否则它们总是需要的。

SOLID和YAGNI并不矛盾:良好的类设计使应用程序更易于维护。YAGNI只是指出，您不应该为您的应用程序添加这样一个可配置的怪物的能力，它可以在阳光下完成任何事情--除非它真的需要它。

这是有明确定义的边界(SOLID)的汽车类和在客户要求之前具有自我治愈能力(YAGNI)的汽车类之间的区别。