Regla N°5 de la Ingeniería de Software: No te repitas

"He redactado esta carta más extensa de lo usual porque carezco de tiempo para escribirla más breve.", Pascal

Aunque pareciera que la frase anterior, perteneciente a Pascal (el matemático, no el lenguaje de programación), no tuviera que ver con el tema "No te repitas", quise mencionarla porque igual que dicho tema, representa la idea de que hacer las cosas bien lleva tiempo, y que un aparente volumen superior de "líneas" no representan más trabajo, ni más esfuerzo, sino un conjunto de datos innecesarios (o repetidos) que restan valor al resultado de nuestro trabajo. Por ejemplo la pregunta correcta no sería ¿que pesa más un kilo de paja o un kilo de plomo?, sino ¿que es mas manejable un kilo de paja o un kilo de plomo?

La regla "No te repitas", hace referencia a que no se deben repetir porciones de código, con funcionalidades iguales, "casi iguales", o parecidas a los largo del código. Aunque técnicamente funcione y de el resultado correcto, aumenta el grado de "degeneración del software" (el tiempo en que se echa a perder un software, hasta que ya no es útil su funcionalidad).

Recuerdo una vez en que me toco auditar un sistema auxiliar en que se tenía que hacer una serie de sencillas copias desde una fuente de información a otra, aplicándole una serie de transformaciones. Las fuentes eran diversas y los destinos también, en este caso se cayó en el ejemplo de "casi se parece", mas sin embargo, si se elijo hacer un proceso completamente independiente para cada fuente de información, pensando en la sencillez de hacerlo así, por la rapidez y por resultar así más cómodo. Inevitablemente se aplico la regla "Va a cambiar" y la regla "Va a fallar". A lo largo del proyecto cambiaron en multitud de ocasiones el formato y las características de las fuentes de datos de los orígenes y de los destinos, teniendo que modificar una y otra vez todo el código fuente y replicando ese código a cada uno de los escenarios "que casi se parecían". Evidentemente todo esto se pudiera haber evitado con una correcta programación orientada a objetos, donde el código "casi igual" se hubiera abstraído para convertirse en la clase base, y las particularidades de cada fuente en clases heredadas.

En el caso anterior solo es un ejemplo sobre como querer hacer algo rápido, acaba convirtiéndose en retrabajos innecesarios e inevitables horas extras.

Un sistema lleno de código repetido, oculta un diseño pobre del sistema, que evidentemente tenderán a "salir a flote" en el peor momento posible.

Algunos motivos de un código repetido son:

• Como mencionaba, un pobre diseño de la solución a resolver (precedido posiblemente por un pobre análisis).
• Un equipo poco integrado y con poca comunicación. Me ha tocado ver que cada integrante de un equipo de construcción, creara exactamente una misma funcionalidad, pero cada uno implementándola de una manera diferente según sus necesidades y criterios.
• Una arquitectura deficiente, que obliga una y otra vez a repetir lo mismo.
• Programadores que quieren tomar atajos, o lo que es lo mismo "pan para hoy y hambre para mañana" (y generalmente "mañana", es el día siguiente, literalmente).
• Falta de comprensión de la programación orientada a objetos: Esta es más frecuente de lo que se pudiera pensar, si bien muchos codificadores tiene claras las bases de la programación orientada a objetos, les difícil situar dichas bases en un contexto practico y real.
• Miedo a tomar el código existente por si llegara a dejar de funcionar: unos tres programadores "miedosos" encadenados y el código será imposible de comprender...

Para evitar tener código repetido, algunas recomendaciones serian las siguientes:

• Tener el principio de abstracción siempre en la mente, buscar siempre lo abstracto y común de cada problema, y paramétrizar (o heredar más bien) las particularidades de cada solución
• Conocer los patrones de software, y buscar soluciones de que nos permitan reutilizar código (o más bien objetos) en ellos.
• Equipos integrados con buena comunicación, que compartan una serie estándares.
• Refactoring para eliminar las partes de código repetidas.