El otro día me volvió a ocurrir, y van varias veces, y de ahí este post, que en una auditoría – revisión software me ocurría algo similar a esto:

- Pero aquí hay un problema… este software tiene mucho código copy – paste [recuerdo un antiguo caso en que el código repetido era del 55%] – Comenté

- Ya ¿y cuál es el problema de eso? Yo más bien creo que es una buena práctica porque ahorramos tiempo al codificar y así, además, cuando hacemos un buen algoritmo lo repetimos muchas otras veces por el código – Me respondieron.

- …

El código duplicado, código copy paste o código repetido, como nosotros le llamamos (ya que normalmente se hace copy paste del mismo código mucho más de dos veces), es la práctica de hacer un algoritmo y copiarlo idénticamente varias veces por el código. Y esto no es buena idea.

Recuerdo que hace unos años leí bastantes trabajos sobre esta, llamemos, “no buena práctica”, y similares, tanto que estas prácticas fueron uno de los temas importantes de mi tesis doctoral (ahi un resumen por el capítulo 2). Quizás los textos más famosos sobre el código duplicado son de Beck y Fowler y sus “bad smells” (“malos olores”), que ayudan a detectar dónde aplicar las refactorizaciones (que simplificadamente son mantenimientos perfectivos del software).

De manera resumida, duplicar código no es bueno porque:

- Aumenta innecesariamente el número de líneas de código, y está comprobado que a más líneas de código (no necesarias) más complejo es el mantenimiento y más rápidamente crece la entropía.

- Implica que si hay que cambiar ese código repetido… hay que cambiarlo en muchos sitios. Hay que buscar todas las repeticiones. Y si se nos olvida cambiarlo en algún sitio… el software acaba siendo incoherente, “diciendo” cosas diferentes para la misma funcionalidad requerida. Por ello baja la productividad y aumenta la probabilidad de error.

- Normalmente un problema de duplicación de código esconde un problema de, o de falta de, diseño software.

Por ello, duplicar código no es buena idea, más aún hoy que existen muchas herramientas de software libre que detectan facilmente el código repetido, ya que, como comentaba el bad smell de Fowler, al hacerlo introducimos “el peor enemigo de la mantenibilidad software”.

Otras entradas relacionadas con esta:

1. Un case o switch con muchas clausulas, o muchos ifs anidados, tampoco es una buena idea
2. Cita: El objetivo no es escribir código
3. Cinco elementos clave en una buena externalización del desarrollo software (II/II)
4. Cinco elementos clave en una buena externalización del desarrollo software (I/II)
5. Alguna reflexión sobre el conocimiento en ingeniería del software y una lista de malos olores