Si ya fuiste programador por algún tiempo, probablemente ya tuviste que codificar más lentamente debido al código feo y mal hecho. El grado de lentitud varía y a menudo es significativo. Los equipos que se mueven rápidamente en el inicio del proyecto se pueden encontrar marchando a pasos de tortuga algunos meses más tarde. Es aquella situación en la que cualquier cambio, por mas trivial que sea, rompe otras partes del código y se hace con miedo de los efectos que genera.
Conforme el tiempo va pasando el lío y la basura aumentan y se tornan tan grandes y tan profundas que nadie más consigue limpiarlos. Cuanto más lío hay el código crece, y la productividad del equipo cae. Los gerentes piensan que pueden ayudar y hacen lo único que está en su poder: contratar más gente para mantener el sistema. Sin embargo, este nuevo personal no conoce el sistema. Y lo que es peor, conocerlos les va a tomar muchos meses e incluso impactarán sobre las actividades de los desarrolladores que lo conocen (esa es la famosa ley de Brooks: "Incluir a más personas en un proyecto atrasado aún demorará mas el proyecto). Asimismo, generará más lío y más código macarrónico.
Eventualmente, el equipo y/o los gerentes se indignan y dicen que no pueden trabajar mas con esta base de código odiosa. La alta dirección no quiere gastar tanto para rehacer todo el sistema, aunque también sabe y percibe que la productividad es horrenda. Eventualmente, acaban aceptando y construyendo el sistema desde cero, y con las mismas funcionalidades, para reemplazar el antiguo código. Hemos visto esa película varias veces. Ya la vi? Quién ya la vió sabe, por lo tanto, que mantener el código limpio de forma continua no sólo es más barato que dejarlo hecho un lío. Es también una cuestión de supervivencia profesional.
A menudo, los desarrolladores están presionados para hacer el código de cualquier manera, para cumplir sus plazos y cronogramas. Muchas veces también tienen que pasar muchas horas vomitando líneas y líneas de código malo. Tenemos que subrayar otro punto importante, tanto para los desarrolladores como para sus gerentes: NO se cumple el plazo haciendo el código confuso y escribiendo porquerías. Por el contrario, la suciedad va a atrasar instantáneamente el proyecto y lo obligará a pasarse del plazo. La ÚNICA manera de cumplir el plazo y la única forma de avanzar rapidamente es manteniendo el código lo más limpio posible todo el tiempo.
Así que para ser un excelente programador siempre seguí la regla de los Scouts: Deje la zona del campamento, incluso más limpia que como la encontró. Esto es, no solo limpia tu código, sino también el código de otros que necesitas modificar. No precisa ser un gran cambio. Cambiá el nombre de una variable a algo que tiene más sentido, rompé un método que es demasiado grande, eliminá la duplicación de código, refactorizá un conjunto de ifs anidados. Si todos limpiamos un poco el código en cada check-in, la base de código siempre se mantendrá organizada y limpia.
Supongamos que ahora crees que escribir código tosco, malo, apestoso y macarronico genera importantes obstáculos. Vamos a decir que aceptas la idea que la única forma de desenvolverse a una velocidad alta es tener una base de código limpio. Entonces te debes estar preguntándo: "¿Cómo puedo escribir código limpio? Además, ¿cómo puedo determinar si un código está limpio o no?". Bueno, es ahí en donde entra algo que todos los desarrolladores deben hacer más en su carrera: LEER!
Algunos consejos iniciales de libros (hay muchos más, pero es mejor empezar con los mejores :-)!) que te harán un mejor programador (confia en mí y lee los libros de abajo y todos. ... Mas no solo leas....ACTÚA en el día a día usando lo que aprendiste):
- Clean Code de Robert Martin
- Code Complete de Steve McConnell
- Emergent Design de Scott Bain
Vamos a buscar y a obtener una mayor calidad y productividad en el área de IT y todo el mundo saldrá ganando: clientes, proveedores, desarrolladores y Brasil...a también Argentina.