Cuando empezamos con un nuevo proyecto, puede surgir la pregunta si se modifica un código viejo o se empieza desde cero. Reciclar código viejo para un nuevo proyecto ahorra tiempo, porque el código viejo ya está escrito y funciona. Escribir código otra vez también ahorra tiempo, porque es específico a lo que está pedido en el nuevo proyecto y un programador no necesita entender un código viejo difícil de comprender.

El ahorro de verdad está entre restaurar proyectos históricos y reinventar la rueda. Así la cuestión es ¿dónde está el punto óptimo entre reciclar y reinventar? Como en muchas ocasiones, no hay una respuesta fácil y, por lo tanto, no la voy a dar. En este artículo presento a condiciones de entorno a tener en cuenta a la hora de decidir si modifico lo viejo y empiezo de nuevo.

Un criterio es la calidad de documentación. Si un programador quiere aprovechar código de otro, no tendrá más remedio que entenderlo. Una buena documentación, que incluso incluye un razonamiento sobre el diseño y el uso de la biblioteca, es una gran ayuda. Entender código sin documentación sólo es beneficioso para secciones pequeñas de código. De otra forma existe el riesgo de pasar mucho tiempo para entender algo que posiblemente ni se puede usar.

En este contexto conviene saber que la herramienta doxygen permite generar gráficos de llamdas de funciones y herencia de clases a partir de un código existente. Doxygen permite llamar a una herramienta específica para la creación de grafos que se llama DOT.

A veces importa que se puede probar un software cuanto antes – especialmente donde se desean hacer pruebas exhaustivas como en la aeronáutica o la medicina. Otra motivación puede ser querer tener un prototipo funcional en cada momento. Entonces se intenta conseguir un código que compile y haga algo aunque sea poco. En este entorno puede ser preferible partir de un proyecto antiguo que funciona y modificarlo hasta que cumpla las nuevas especificaciones sin que deje de ser un programa funcional en ningún momento.

Algo importante a la hora de reutilizar código viejo es el grado de similitud entre el funcionamiento real y el funcionamiento deseado. Poder utilizar una biblioteca tal cual como es, es un argumento poderoso para utilizar el código viejo. Si, en cambio, hace falta tocar la mitad de las funciones, entonces mejor se aprovecha nada más que el fichero de cabecera.

De hecho, reciclar código no significa necesariamente copiarlo todo. La estructura de datos, la interfaz, un bucle o un comentario de documentación: es perfectamente válido empezar con un proyecto vacío y rellenarlo paso a paso con elementos de un proyecto antiguo. Esta es una manera muy útil cuando ya se sabe que el proyecto viejo contiene muchas partes útiles aunque el programador todavía se pierde entre tantas funciones. A la hora que avanza con su proyecto nuevo, entiende mejor las necesidades y puede buscar más eficazmente lo que necesita en el código viejo. En este caso el proyecto antiguo sirve más bien como un código ejemplo que un programa ya completo.

En general suele ser un buen compromiso utilizar lo viejo si cuesta poco utilizarlo y hacerlo nuevo en el caso contrario. Muchas veces no se cambia sólo la funcionalidad sino, además, otras circunstancias de contorno. En lugar de una conexión de puerto serie se usa un puerto USB, el sistema operativo usa 64 bits y no 32, el estilo de código de ahora es mejor que el utilizado en el código antiguo o quizá se piensa crear la aplicación como una página web y no un fichero ejecutable. En corto: si ya te toca tocar código viejo, hazlo de forma contundente.

Hemos visto que el grado de documentación, la necesidad de hacer pruebas o tener prototipos son circunstancias importantes de modificar lo viejo en lugar de empezar de nuevo. Por la similitud entre lo que está hecho y lo que se quiere hacer se elige hasta que grado se copian componentes antiguas: de módulos enteros via apartados de código a meramente inspiraciones para el nuevo proyecto.

Referencias