Código Muerto

Si hay algo que me frusta cuando estoy leyendo código es dedicar un largo rato a entender que hace un método solo para descubrir que en realidad ese método no es utilizado en ninguna parte de la aplicación.

Esto pasa porque muchos programadores se resisten a borrar código aun cuando este ya no cumpla ninguna función (de hecho cuando hicimos el Code Retreat los participantes se resistían bastante). Entonces en vez de borrarlo simplemente lo dejan por ahí, con la esperanza de poder utilizarlo algún día. Después de todo, no cuesta nada,¿no?

Bueno, en realidad cuesta mucho. En primer lugar dificulta la lectura y todos sabemos que los programadores pasamos mucho más tiempo leyendo leyendo y entendiendo código existente que escribiendo código nuevo. Además, debe ser mantenido, ya que es probable que esté utilizando otros métodos que con el tiempo van cambiando.

Por otro lado, aumenta el costo de mantenimiento de la aplicación ya que este crece en forma no linear con respecto al tamaño: el costo de mantener un programa de 1000 líneas de código es más que el doble del costo de mantener uno de 500.

Lo más gracioso de la situación es que aún si se diera el caso donde realmente necesitemos el código borrado, es sencillo recuperarlo mediante nuestro software de control de versiones (y si no están utilizando control de versiones lo mejor que pueden hacer es suspender inmediatamente lo que están haciendo y ponerse a instalar uno).

Todas las variantes de esta costumbre son horribles: variables que no se usan, métodos publicos o privados que nadie llama, código comentado ,clases que no se utilizan,etc. Incluso hay sistemas con features completas o a medio terminar que nunca se pusieron en producción pero cuyo código sigue existiendo y aumentando el costo de desarrollo.

Cuando estamos usando tests de unidad se da una variante un poco distinta que es la de tener dos tests que verifican exactamente lo mismo. Muchas veces nos resistimos a borrar uno de los dos tests porque nos sentimos más seguros por la doble verificación, pero esa sensación es falsa: uno de los tests no nos está sirviendo de nada y debe ser borrado.

El código muerto no se da solo en los lenguajes de programación. sino que se produce también en la miriada de archivos de configuracion que se desparraman y se replican una y otra vez porque en algun momento se utilizaron. Archivos de properties, xml deconfiguración, archivos de configuracion de log4j, de caches distribuidas, de colas mq, etc y etc y etc, que provocan comportamientos no determinados y que hace que una aplicacion quefuncionaba al ser desplegada en otro ambiente deje de funcionar (o viceversa).

En definitiva, es importante darse cuenta de que cada línea de código tiene un costo de mantenimiento y solo debe seguir existiendo si provee un valor que justifique ese costo.