DRY (Don’t Repeat Yourself) es un principio del desarrollo software que establece que «Cada pieza de conocimiento debe tener una única representación autorizada, sin ambigüedades, dentro de un sistema». Si se aplica correctamente, un modificación en un elemento del sistema no requerirá un cambio en otros elementos no relacionados lógicamente.
El problema
Como programadores pasaremos gran parte de nuestro tiempo manteniendo software ya existente y raramente estaremos escribiendo código original. Ya sea por que estemos realizando cambios, refactorizando para mejorar el programa o arreglando un bug. Por tanto, nos conviene planificar y desarrollar nuestros sistemas pensando en ese mantenimiento desde el principio.
Consideremos un elemento de nuestro sistema con más de una representación. En algún punto durante la vida de nuestro sistema haremos una modificación de alguna de estas representaciones lo que la desfasaría del resto y puede hacer que entren en conflicto. En caso de que no sea así, significa que cada vez que cambiemos una representación de un elemento, debemos buscar el resto de representaciones y actualizarlas en consecuencia. Con forme nuestro sistema evoluciona esto deriva en tremendos dolores de cabeza a la hora de realizar cualquier modificación o mantenimiento.
No es algo que se limite solo al código, si no que debe aplicarse al sistema al completo como esquemas de base de datos, test, documentación, etc. Este es el principal problema ya que debemos expresar nuestros elementos de forma que se propaguen por todas las capas del sistema.
Principio DRY y Ortogonalidad
Como solución a este problema, Andy Hunt y Dave Thomas formularon en su libro «The Pragmatic Programmer» el principio DRY. Este principio establece la idea o necesidad de que los diferentes elementos del sistema deben de ser únicos, no solo en el código, si no en todas las capas o dominios del sistema.
La idea de ortogonalidad se basa en que dos elementos no relacionados conceptualmente no deben de estar relacionados en el sistema. De este modo cambios en uno de los elementos no deben de provocar cambios en otros elementos ortogonales. Por ejemplo, un cambio en la interfaz de usuario no debe de provocar cambios en el esquema de la base de datos.
Técnicas e implementación
Hay muchas formas de implementar este principio (generadores de código, transformado de datos, …), pero todas se basan en el mismo concepto: encapsular conceptos en representaciones. Para ello se requiere una gran planificación y dividir nuestra aplicación en componentes que se relacionan. Luego podemos aplicar DRY sobre cada uno de estos componentes.
No repitas tu código
Es un primer paso pero no debe tomarse por una solución completa a este problema. Debemos encapsular nuestro código y no ir repitiendo estructuras y funciones a lo largo de objetos y ficheros. Es algo que me he encontrado en multitud de ocasiones en las que para solucionar un problema, ya solucionado en el sistema anteriormente, se realiza el famoso «Corta-Pega» de grandes trozos de código. Muchos desarrolladores piensan que se ahorra tiempo con este tipo de soluciones o parches pero en mi experiencia acaban convirtiendose en una fuente de problemas y perdidas de tiempo.
Cuando te encuentres escribiendo código que es similar o igual a otro que ya has escrito antes, tomate un momento para pensar en lo que estás haciendo y no te repitas a ti mismo.
Relacionar Bases de Datos y Código: ORM
Los sistemas ORM (Object Relational Mapper) tratan de relacionar objetos o tipos de datos de los lenguajes orientados a objetos con sus representaciones en sistemas de bases de datos relacionales. Aunque su principal intención es la de facilitar la manipulación de consultas adaptándolas a la programación orientada a objetos, en algunos soluciones como Doctrine nos permiten construir y mantener el esquema de base de datos desde una entidad del código. De esa forma podemos tener una única representación de un elemento, el objeto PHP en este caso, cuyas modificaciones se sincronizan con las demás representaciones secundarias como la tabla de datos relacionada.
Generadores de Documentación
Uno de los principales problemas que vamos a encontrarnos al mantener un sistema complejo es el mantenimiento de la documentación. Reconozco que soy el primero que detesto perder el tiempo escribir documentación. Cada cambio en el sistema puede convertir en obsoletas decenas de páginas de documentación. Para evitar este tipo de documentaciones obsoletas (con los que todos hemos tenido que trabajar alguna vez) existen herramientas que generan dicha documentación a partir del propio código. Una de las más conocidas es phpDocumentor. Esta herramienta analiza nuestro código y produce la API de lectura y documentación del sistema.
Si bien no sustituye a una documentación tradicional, es una forma bastante cómoda de tener una documentación básica y siempre actualizada.
Conclusión
En el mundo real sin embargo, conseguir que una aplicación sea 100% DRY es difícil si no imposible. Sin embargo, aplicaciones que no son DRY, denominadas WET («write everything twice», «we enjoy typing» or «waste everyone’s time»), hasta un punto inaceptable son algo bastante común. La dificultad de mantener dichas aplicaciones debería ser más que suficiente para que las evitemos a toda costa.
Como desarrolladores debemos intentar cumplir con ciertos requisitos de calidad y crear software de forma sostenible, que podamos mantener y evolucionar a lo largo del tiempo. Para ello existen este tipo de principios o buenas prácticas.