什么时候更喜欢广义解而不是具体情况？

Question

在编程中，我们经常面临一种选择:分别覆盖每个可以想象的用例，或者解决一般的问题：

显然，解决眼前的问题更快，但创建一个通用的解决方案将节省时间在未来。

我如何知道什么时候最好试着覆盖有限的案例列表，或者建立一个通用的系统来覆盖所有的可能性？

Answer 1

首先，你把盐递给我。然后你把胡椒递给我。然后你把磨碎的帕尔马干酪递给我。在这一点上，你有足够的经验开始开发一个通用的调味品传递系统.

它以同样的方式在软件项目中工作:使用您开发的特殊用途系统，将您的学习步骤扩展到通用系统，因此，当您开始您的通用系统时，您对您正在构建的系统有更好的信心，因为您的腰带下面有几个特殊用途的系统。

Answer 2

我如何知道什么时候最好试着覆盖有限的案例列表，或者建立一个通用的系统来覆盖所有的可能性？

经验.

唯一能知道的方法就是以前试过一条路，看看它是如何咬你屁股的(或者你浪费了很多时间)。重复，直到你的屁股被咬得更少。

即使如此，你也不知道，你只是有一个更好的猜测。

Answer 3

要在百叶窗灯和Paddy3118的答案基础上构建，如果您没有多个要实现的案例，那么就不需要泛化！XKCD漫画之所以有趣，是因为它嘲弄了过早的泛化。当被要求传递盐时，这个看不见的角色立即跳到“开发一个传递任意调味品的系统”，而第一个角色要求的就是盐。对于开发人员来说，这是一个很好的笑话，因为我认为我们都看到过过早泛化的情况。

反对过早泛化的原则是雅格尼 (您不会需要它)。关于这一点，在网络上有很多可用的材料，但基本上YAGNI指出了在没有几个实际用例的好处的情况下进行泛化的一些风险，包括多个用例可能不会实际出现的可能性。或者，更微妙的是，由于缺乏实际的用例，人们需要对未来的需求做出假设。这些假设可能是，而且经常是不正确的。