¿Escribes tu mejor código a la primera? No me lo creo!

 

 

La mayoría de gente con la que he trabajado programando, cuando tenían que hacer alguna aplicación, una parte, API, clase o lo que fuera, lo escribían y ya está. Incluso yo hasta hace no mucho tiempo, escribía el código que mejor me salía a la primera y ahí lo dejaba, a veces orgulloso de él y todo :S . Por suerte, después de unos años de experiencia he aprendido que esto no debe ser así. 

No nos deberíamos limitar a  escribir un programa de principio a fin a la primera. Más importante aún, no deberíamos esperar ser capaces de escribir programas limpios y elegantes a la primera. Si algo he aprendido durante todo el periplo que ha supuesto mi carrera estudiantil y profesional, es que la programación es un arte más que una ciencia. Para escribir un código limpio, primero debemos escribir código sucio y luego limpiarlo.

Esto no debería ser una sorpresa para nadie. Escribir código limpio, es una cuestión de refinamientos sucesivos. Primero debemos escribir una primera versión, después revisarla, corregir lo que creamos conveniente, a continuación, volver a revisar y volver a refinar, y así sucesivas veces. Tener un ciclo de refactorizaciones sucesivas.

Un símil muy bueno se puede hacer con los polinomios de álgebra, donde los descomponemos en factores y los factorizamos paso a paso para hacerlos más simples y comprensibles sin modificar su resultado para llegar a una solución. Bien, pues con el código debemos hacer lo mismo, llegar a una solución lo más comprensible y simple para todo el mundo que vaya a meter mano a ese código.

La mayoría de los programadores jóvenes (con pocos años de experiencia en este tema) no están de acuerdo con esta técnica y no sigue este consejo muy bien. Ellos creen que el objetivo principal es conseguir que el programa funcione, dando igual como esté escrito por dentro. Terminando así con un código ilegible, código espagueti, o como le queráis llamar. Solo preocupa que funcione lo requerido y poder pasar así rápidamente a la siguiente tarea. Parafraseando a Uncle Bob “Los programadores más experimentados saben que esto es un suicidio profesional”.

El principal problema de que un programador se acostumbre a hacer refactorizaciones sucesivas de su código y cuidarlo con mucho más mimo, es que supone un esfuerzo y este esfuerzo no se ve plasmado en funcionalidades para el proyecto. A pesar de ello, si utilizamos esta forma de programar refactorizando, como técnica de desarrollo a lo largo del proyecto, conseguiremos que nuestro código sea de calidad y mucho más legible, ya no solo para nosotros, sino también para el resto de programadores del equipo. La experiencia dice (y no solo la mía) que este tiempo empleado en cada refinamiento sucesivo, será recuperado repercutiendo con creces en el avance del proyecto en el futuro.


Deja un comentario

IMG_4939IMG_4206IMG_4462IMG_4961IMG_4484IMG_4491IMG_4500IMG_3869IMG_4507IMG_3936IMG_4622IMG_4358IMG_4765IMG_4494
%d personas les gusta esto: