YAGNI原则付诸实施

Question

我最近谈到了这个原则，到目前为止，很明显，做那些你目前不需要的事情是不可行的，因为它们可能不会被使用或者可能被改变。

尽管如此，考虑以下场景:您正在开发一个需要在标签中显示文本的应用程序，该应用程序需要在多个地方/部分显示文本。目标语言是英语，没有实现多语言的要求.此时，如果您需要多语言特性，您可以定义资源文件中的每个字符串(假设它是一个XML文件)，并创建/使用一个类来读取它们，并将它们分配给相应的标签(根据语言)。问题是，由于多语言不是一个要求，YAGNI。

那么，您是否仍然将字符串定义为资源文件并实现读取器，或者在实际需要时对它们进行硬编码并重新编写？

Answer 1

硬代码和重构时，你需要它。时间就是金钱，yadda，拥有未使用的功能值得花费时间/金钱吗？

而且，这并不难做到，因为它是乏味的。当需要时，将该任务移交给初级开发人员。

最后，当时机成熟时，一些自动化工具可能会让您在很大程度上达到目的。例如Eclipse的字符串外设器。

Answer 2

使应用程序多语言确实需要一些额外的开发工作。你可以从一开始就投入精力，每天一点点。或者，当你写了>100K行代码的时候，你可以在之后投入这些努力。事实上，在这两种情况下所需努力的总和并不像你所想的那么大。

第一种方法实际上掩盖了一些人认为第二种方法代价更高的必要努力，但IMHO --这是一种误解。第二种方法实际上向您展示了实际成本，并使它们更加透明。这就是YAGNI原则的意义所在:在你还没有做好投资准备的时候节省隐藏的成本。

尽管如此，从一开始就提供多语言支持的应用程序可能是许多软件产品的正确战略决策，尤其是在有机会向更广泛的受众销售这些应用程序的情况下。但我们不应相信这样的决定完全是免费的。

Answer 3

YAGNI经常反对其他既定原则和/或最佳做法。其他示例包括几个坚实的原则，这些原则主要是关于构建代码以使将来某些类型的更改更容易。但如果你从来不需要做这些改变呢？然后，例如，反演应用程序的两个不同部分之间的依赖关系所涉及的额外工作，以及这种反转所需的不必要的抽象所带来的额外复杂性，都被浪费了。

YAGNI并不意味着我们不应该做这样的事情。这确实意味着我们应该在做之前停下来想一想，认真评估我们将要付出的努力，它有多大可能得到回报，以及它现在比以后容易得多。

在您的字符串外部化示例中，工作量很小，但以后也不难做到，正如Doc所建议的那样。而且，只有您知道将来需要i18n支持的可能性有多大。

就我个人而言，我倾向于把这个特定的任务留到有必要的时候，但我的经验主要是为很少需要这个工具的中小企业构建内部应用程序，并且我使用支持自动重构到外部字符串资源的工具。您的市场和工具可能是不同的，这可能导致不同的决定。