Giro atómico

Los desarrolladores de software son excelentes para reconocer patrones. Tal vez sea una habilidad inherente que nos atrae a esta profesión. O tal vez sea el proceso de escribir software lo que desarrolla esta habilidad. De cualquier manera, «no te repitas» (DRY) es una aplicación natural de esta habilidad.

Sin embargo, la repetición en sí misma no es el enemigo que este principio hace parecer.

No te repitas

Tan intuitivo como «no te repitas» puede ser, El Programador Pragmático lo resume de esta manera:

Cada pieza de conocimiento debe tener una única, inequívoca y autorizada representación dentro de un sistema.

No es difícil imaginar los beneficios de reducir o eliminar la repetición.

• Menos duplicación significa menos código que mantener. Y si el mejor código es no tener código, esto suena como algo bueno.
• Una única fuente de verdad elimina la posibilidad de que las cosas se desincronicen. ¿Ha cambiado alguna regla de negocio? Actualícela en un lugar y listo.
• El código es reutilizable. ¿Tienes un proceso compartido por tres cosas y vas a añadir una cuarta? La mayor parte del trabajo ya está hecho.

A veces repite

Conseguir demasiado celo en reducir la duplicación aparente puede crear más problemas de los que resuelve. Digo «duplicación aparente» porque a veces cosas que parecen similares no están realmente relacionadas. Por ejemplo, dos estructuras de datos con propiedades y tipos idénticos pueden ser iguales estructuralmente pero no semánticamente.

Una estrategia común para reducir el código duplicado es factorizar las partes comunes y esconderlas detrás de una abstracción. Pero un efecto secundario indeseable de esto es que acopla cualquier cosa que utilice la abstracción. Cualquier cambio en la abstracción afecta a todos sus consumidores. Y del mismo modo, la abstracción puede necesitar ser doblada para adaptarse a los requisitos de un solo consumidor.

Este aumento en el acoplamiento también viene con una disminución de la flexibilidad. Digamos que usted tiene un proceso que se utiliza en tres lugares. Es casi el mismo en los tres lugares, con sólo algunas diferencias importantes. Así que implementas el proceso como un único módulo que toma unos pocos parámetros para cubrir las diferencias.

Ajustar el proceso para uno solo de esos casos de uso es ahora imposible: cualquier cambio en uno afecta a los tres. Por supuesto, se pueden añadir más parámetros (o casos especiales) a medida que los casos de uso divergen. Pero rápidamente será imposible distinguir las partes importantes del proceso de la infraestructura que separa los casos de uso.

Preguntas que hacer

Cuando se refactoriza el código existente o se escribe código nuevo que puede estar potencialmente duplicado, me pregunto:

¿Se trata de una sola pieza de conocimiento que se ha duplicado, o es sólo una infraestructura que resulta ser similar?

Así que rebuscaste en el CSS y encontraste una clase que resulta tener los estilos que quieres. Eso probablemente no es una razón suficiente para evitar la definición de otra clase.

¿Cuántas veces se ha repetido esta cosa?

Hasta que una cosa verdaderamente redundante aparezca al menos tres veces, yo sería muy escéptico de cualquier repetición-reducción que aumente la complejidad.

¿Reducir la duplicación ahora hará más difícil personalizar casos individuales en el futuro?

Hay algo satisfactorio en refactorizar un montón de código de copiar y pegar en algo más racionalizado y reutilizable. Pero bloquear el código de forma tan estricta que cualquier cambio introduzca casos especiales no es una buena compensación.

Si reduzco esta duplicación, ¿cuál es la relación entre el tamaño de la abstracción y el número de parámetros que tomará?

Las bibliotecas y los frameworks son geniales porque proporcionan código reutilizable con relativamente pocos parámetros para la personalización. Pero imagine una función específica de la aplicación para presentar un cuadro de diálogo que ha crecido y ahora acepta 20 parámetros. Cualquier beneficio de reducción de la repetición que existía cuando tenía 2 parámetros ya no existe.

Conclusión

Como con muchos principios de desarrollo de software, «no te repitas» es una directriz más que un mantra.