¿El principio YAGNI es realmente bueno para el desarrollo de software?

YAGNI (No lo vas a necesitar) es un buen principio rector a tener en cuenta.

Pero no debería ser una religión. Muchos problemas son subconjuntos de algún problema general, y resolver el problema general, con su subconjunto como un ejemplo especial, a menudo puede conducir a un código más limpio y mejor diseñado que en realidad es más rápido de escribir.

Pero no siempre. A veces puedes volverte loco tratando de generalizar un problema, cuando realmente el caso especial que tienes puede resolverse más fácilmente, y en realidad es todo lo que se requiere de ti.

Entonces, como de costumbre, la respuesta depende de los detalles.

Una de las realidades molestas del desarrollo de software es que después de haber creado su producto, alguien en algún lugar decidirá que necesita características adicionales. A menudo, estos parecen fáciles, incluso triviales. Pero si su software está demasiado especializado, puede ser muy difícil expandirlo para hacer cosas adicionales. Por otro lado, si las cosas nuevas son solo casos adicionales del problema general que resolvió, agregarlas puede ser realmente trivial.

La máxima expresión de lo contrario de YAGNI es la programación orientada a objetos en sí. OOP resuelve un problema general: cómo colocar una nueva funcionalidad de una manera que no lo obligue a rediseñar un programa completo. Obviamente, OOP ha demostrado ser extremadamente exitoso y popular, por lo que, de hecho, lo vas a necesitar.

Como con la mayoría de las cosas, la programación realmente depende.

Para llevar mi punto a casa, considere lo siguiente:

Guión

El cliente solicita crear un sistema de gestión de información personal para mantener notas y contactos de clientes y prospectos. Usted ve que, debido a que este es un negocio, es muy probable que se convierta en un sistema CRM. Entonces, ¿vas a agregar más que solo un par de tablas y una interfaz de edición simple? Según YAGNI, no.

Sin embargo, hay algunas cosas que, incluso si no se solicitan específicamente, tienen sentido agregar, como:

• Una forma de discernir entre clientes potenciales y clientes
• Una historia de interacciones con notas.
• Para cada interacción, si condujo a una venta
• Un gráfico de cuántas interacciones por cliente llevó a una venta (es muy probable que esto sea un KPI eventualmente, además de establecer las expectativas correctas sobre cuánto tiempo le llevará a un negocio realizar ventas repetidas)

¿Qué no vale la pena agregar, entonces? Bueno, cualquiera de estos:

• Una interfaz de entrada de pedidos
• Un campo de “valor total del cliente”
• Gráficos (excepto el historial de interacciones)

Tenga en cuenta que la mayor parte de lo que vale la pena agregar no aumenta significativamente el tiempo de desarrollo (si usa las herramientas correctas), mientras que lo que no vale la pena agregar de inmediato agrega mucho tiempo de desarrollo.

Además, me gustaría señalar cómo YAGNI realmente debería ser YAGNIUYAC (no lo necesitará a menos que le pregunte al cliente). Si cree que algo sería útil de inmediato, pregúntele al cliente. A los clientes les encanta ser vendidos en cosas que se dan cuenta de que necesitan 🙂

Creo que depende de la empresa, pero en general YAGNI es bueno porque

• Los desarrolladores de software no tienen suficiente información para hacer llamadas a funciones adicionales, el tiempo empleado podría utilizarse en otro lugar de manera más productiva
• Las características adicionales significan tiempo de desarrollo adicional, tiempo de prueba, tiempo de documentación, tiempo de CR
• No desea una característica no esencial que cause un error importante
• La gente no quiere mantener un código inútil

Imagine una situación en la que tiene la tarea de escribir algún código que aplique cierta lógica y escupe una salida. Lo escribe y decide por su propia cuenta, o con sus colegas ingenieros, que sería bueno tener algunos resultados adicionales.

Tal vez sus mejoras sean buenas, pero a menos que verifique dos veces con la administración del producto, existe una buena posibilidad de que el tiempo dedicado a la mejora sea un desperdicio total que no ofrece ningún valor.

Avance rápido 3 años, está en una empresa diferente y algún otro ingeniero está actualizando o arreglando el código que escribió. Puedo ver totalmente a esa persona preguntando “¿Qué demonios es esta basura y por qué necesitamos todo este código? ¿Alguien usa esto?

Creo que debería ser el principio rector al desarrollar software. Ahora digo guía y no regla porque lo que creo que debería suceder es que escriba el código para hacer exactamente lo que el programa está diseñado para hacer y no más, pero escríbalo de tal manera que pueda extenderlo sin una reescritura completa. Ahora probablemente deba hacer modificaciones, pero no debería ser como eliminar por completo secciones enteras y volver a escribirlas para hacer lo que hizo antes, más los nuevos requisitos. Esto generalmente proviene de la experiencia y la intuición, ya que no hay una forma real de determinar objetivamente cómo hacer que el código sea extensible sin escribir realmente en funciones no solicitadas.