Cuándo preferir una solución generalizada sobre la resolución de casos específicos

En la programación, a menudo nos encontramos con una opción: cubrir cada caso de uso concebible individualmente o resolver el problema general:

Es obvio que resolver el problema inmediato es más rápido, sin embargo, crear una solución generalizada ahorrará tiempo en el futuro.

¿Cómo sé cuándo es mejor tratar de cubrir una lista finita de casos, o hacer un sistema genérico para cubrir todas las posibilidades?

Primero, pasas la sal. Luego pasas el pimiento. Luego pasas el queso parmesano rallado. En este punto, tiene suficiente experiencia para comenzar a desarrollar un sistema general para pasar condimentos.

Funciona en proyectos de software de la misma manera: use sistemas de propósito especial que desarrolle como pasos de aprendizaje para los generalizados, de modo que cuando llegue el momento de comenzar su sistema de propósito general, tenga una mejor confianza en lo que está construyendo, porque Tienes varios sistemas de propósito especial en tu haber.

¿Cómo sé cuándo es mejor tratar de cubrir una lista finita de casos, o hacer un sistema genérico para cubrir todas las posibilidades?

Experiencia.

La única forma de saberlo es haber probado un camino antes, visto cómo te mordió el culo (o has perdido un montón de tiempo). Repite hasta que te muerda menos el culo.

Incluso entonces, realmente no lo sabes ; solo tienes una mejor suposición.

Para construir sobre las respuestas de dasblinkenlight y Paddy3118 , si no tiene varios casos para implementar, ¡entonces no necesita generalizar! La razón por la cual la caricatura de XKCD es divertida es porque ridiculiza la generalización prematura . Cuando se le pide que pase la sal, el personaje invisible salta inmediatamente a "desarrollar un sistema para pasar condimentos arbitrarios" cuando todo lo que el primer personaje pidió fue la sal. Esta es una buena broma para los desarrolladores, ya que creo que todos hemos visto casos de generalización prematura.

El principio opuesto a la generalización prematura es YAGNI (No lo vas a necesitar). Hay muchos materiales sobre esto disponibles en la web, pero básicamente YAGNI señala una serie de riesgos al generalizar sin el beneficio de varios casos de uso reales disponibles, incluida la posibilidad de que los casos de uso múltiple realmente no aparezcan. O, más sutilmente, la falta de casos de uso reales requiere que uno haga suposiciones sobre lo que es necesario en el futuro. Estas suposiciones pueden ser, y a menudo son, incorrectas.

Parece más fácil ser genérico en el pequeño, es decir, no haga una clase para manejar una tabla de búsqueda que asigne enteros a cadenas cuando puede hacer una clase de diccionario razonable que maneje cualquier par de tipos (donde el primer tipo admite algún tipo de comparación).

En una vida anterior, hice muchos proyectos de automatización industrial para maquinaria que manejaba una red continua de material. Acero, aluminio, papel, plástico, .... Lo desenrollas en un extremo y lo enrollas nuevamente en el otro después de hacer algo útil en el medio. En una industria, comienza en el "carrete de pago", no en el "desenrollador". Si usa la terminología incorrecta, entonces es un idiota a los ojos de varios millones de dólares del cliente. Te sorprendería lo poco que se puede abstraer para la reutilización de un proyecto a otro. OTOH, a menudo se puede crear un marco o plantilla como punto de partida. Se personalizaría para el trabajo en cuestión, pero al menos tenía el beneficio de aprender de proyectos anteriores. Y todos en el equipo sabían desde dónde comenzábamos.

Hazlo una vez, hazlo dos veces, hazlo tres veces, generaliza.

¡Uno, dos, muchos!

En el segundo caso deberías estar pensando en la generalización. Al solicitarle el tercero, debe proporcionarlo desde el código generalizado y usar el primer y segundo caso previamente resuelto individualmente como casos de prueba.