什么时候比解决特定情况更偏爱通用解决方案

在编程中，我们经常面临选择：单独覆盖每个可能的用例，或解决一般问题：

很明显，解决当前问题的速度更快，但是创建一个通用的解决方案将在将来节省时间。

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

首先，您要撒盐。然后，您将胡椒粉通过。然后，您将磨碎的帕玛森芝士通过。在这一点上，您有足够的经验来开始开发通用的调味品通过系统。

它以相同的方式在软件项目中起作用：将您在开发过程中开发的专用系统用于通用系统，因此，当需要启动通用系统时，您对所构建的内容会更有信心。您拥有多个专用系统。

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

经验。

唯一知道的方法是尝试过一条路，看看它是如何刺伤您的屁股的（或者您浪费了很多时间）。重复直到您少了一点屁股。

即使那样，你也不是很清楚。您只是有一个更好的猜测。

要建立在dasblinkenlight和Paddy3118的答案的基础上，如果您没有要实现的多个案例，那么就不必一概而论了！XKCD动画片之所以有趣，是因为它讽刺了过早的概括。当被要求传递盐时，当所有要求的第一个角色都是盐时，这个看不见的角色立即跳到“开发一种可以传递任意调味品的系统”。对于开发人员来说，这是个好玩笑，因为我认为我们都已经看到过早泛化的情况。

反对过早概括的原则是YAGNI（您将不需要它）。Web上有许多关于此的资料，但是从根本上来说，YAGNI指出了很多风险，没有手头几个实际用例的好处，其中包括可能不会真正出现多个用例的可能性。或者，更微妙的是，缺乏实际用例需要人们对未来的必要需求做出假设。这些假设可能是，而且经常是错误的。

在较小的范围内通用似乎更容易，例如，当您可以创建可以处理任何一对类型的合理的字典类时，不要创建一个类来处理将整数映射到字符串的查找表（其中第一个类型支持某种类型的比较）。

在以前的生活中，我为处理连续材料网的机器做了很多工业自动化项目。钢铁，铝，纸，塑料…… 您可以在一端进行展开，然后在中间进行一些有用的操作后再将其展开在另一端。在一个行业中，您从“支付卷轴”开始，而不是“放卷机”。如果您使用了错误的术语，那么您在客户数百万美元的眼中就是个白痴。你会怎么一点可以惊奇地发现抽象重用从一个项目到下一个。OTOH，通常可以创建一个框架或模板作为起点。它将针对手头的工作进行定制，但是至少它从先前的项目中学到了好处。团队中的每个人都知道我们从哪里开始。

一次执行一次，两次执行，三次执行，概括。

一，二，很多！

在第二种情况下，您应该考虑泛化。在被要求提供第三种情况时，您应该从通用代码中提供它，并使用先前单独解决的第一种情况和第二种情况作为测试用例。