Por qué no deberías eliminar la duplicación de código demasiado pronto
- Aplicar el principio DRY (Don't Repeat Yourself) de forma demasiado estricta puede provocar una abstracción "prematura" y hacer que los cambios futuros sean más complejos
- Hay que pensar si la duplicación realmente es innecesaria, o si se trata de funcionalidades que evolucionarán de forma independiente con el tiempo
- Aunque una función o clase parezca igual, puede tener contextos y requisitos de negocio distintos
- Más que hacer el código más corto, hay que pensar si el propósito de la función seguirá vigente con el tiempo
- El riesgo de la abstracción: si existe la posibilidad de que una funcionalidad evolucione de manera diferente, la abstracción puede resultar perjudicial.
- Al diseñar una abstracción, no se deben acoplar demasiado pronto comportamientos que a largo plazo podrían evolucionar por separado
- En caso de duda, conviene mantener los comportamientos separados hasta que con el tiempo aparezca un patrón común suficiente que justifique unirlos
- En escalas pequeñas, gestionar la duplicación puede ser más simple que resolver la complejidad de una abstracción prematura
- En las primeras etapas del desarrollo, conviene permitir un poco de duplicación y esperar antes de abstraer
- Los requisitos futuros a menudo son impredecibles
- Vale la pena pensar en el principio YAGNI (You Aren't Gonna Need It)
- Puede que la duplicación no llegue a ser un problema, o que con el tiempo deje claro la necesidad de una abstracción suficientemente bien pensada
10 comentarios
En primer lugar, la aplicación de DRY debería hacerse reduciendo lo que se está repitiendo,
pero si se piensa el código a partir de DRY como criterio previo, parece una aplicación incorrecta.
Entre las opiniones de Hacker News,
la que más me identifica es esta: un malentendido del principio DRY: DRY busca evitar la duplicación de información/conocimiento, no la duplicación de código. Si uno se enfoca solo en la duplicación de código, puede terminar en una optimización innecesaria.
¿No se hacen mucho ese tipo de preguntas durante la etapa de transición? Como no existe el código perfecto, supongo que pensar en esto todos los días es parte de nuestro trabajo. Creo que depende de cada caso.
Últimamente se ven seguido textos con una mirada escéptica sobre estructuras con un alto grado de abstracción.
MSA, código limpio, SOLID, DRY, etcétera...
Me da la impresión de que la gente está sintiendo cierto cansancio con ese tipo de términos.
En realidad, esas cosas no son más que referencias para tener en cuenta cuando uno piensa cómo escribir código fácil de leer, fácil de entender, sin fugas de memoria, sin errores y rápido...
Supongo que lo importante es aplicarlas con mesura y ajustarlas bien a la situación de negocio en la que uno está ahora mismo.
https://velog.io/@kineo2k/…
Es un texto excelente.
Parece especialmente más importante cuando se cambia del modelo en cascada al modelo ágil.
Aunque se supone que es ágil, se intenta predecir demasiado el futuro.
¿Qué tan rápido hay que ir para que sea “precipitado”?
La respuesta es muy simple. Si lo haces desde el principio, es "prematuro".
La pregunta un poco más difícil es cuándo deja de ser "prematuro".
Suena a juego de palabras, pero si simplemente no lo haces desde el principio, entonces ya no sería algo "precipitado", ¿no? ^^;
Sí, especialmente en Agile
Opinión de Hacker News
Aplicación temprana del principio DRY: Es bueno aplicar el principio DRY desde el principio. Es más eficiente usar una base de código común en lugar de manejar datos similares por separado.
Prioridad de las mejores prácticas: No todas las mejores prácticas son iguales. Es importante priorizar la legibilidad y la cohesión. Escribir código es el proceso de elegir la mejor práctica posible.
Malentendido del principio DRY: DRY busca evitar la duplicación de información/conocimiento, no la duplicación de código. Enfocarse solo en el código duplicado puede llevar a optimizaciones innecesarias.
Problema de reutilización: Hay casos en los que una función específica no se reutiliza en otros contextos. Se necesita un mejor enfoque para evitar trabajo duplicado.
Problema de las soluciones DRY complejas: A veces, el código repetido es mejor que una solución DRY compleja. Aplicar DRY demasiado rápido puede provocar problemas estructurales inesperados.
DRY no es una mejor práctica: La repetición suele ser una señal de que se necesita abstracción. Aplicar DRY sin criterio es un error que los ingenieros de nivel intermedio cometen con frecuencia.
Ejemplo simple de código: Dos funciones pueden integrarse en una sola función. Es importante explicar con claridad las ventajas y desventajas del refactoring.
Problemas de mantenimiento del código DRY: El código DRY puede volverse complejo y difícil de mantener. En cambio, el código WET es simple, pero sus cambios son predecibles.
Efectos secundarios del principio DRY: El principio DRY puede volver la base de código más compleja y difícil de mantener. Algunos libros de código limpio han tenido un impacto negativo en la industria.
Generalización y rendimiento: La generalización puede afectar negativamente el rendimiento. Duplicar código adaptado a patrones de datos específicos puede ayudar a optimizar el rendimiento.