El código limpio no es lo importante

Diego Martin | 11 Aug 2020

Image Clean Code

En 2008 Robert C. Martin, uno de los firmantes del manifiesto Agile y que es conocido en la industria como "Uncle Bob", publica uno de los libros más relevantes para la industria del software: Clean Code - A Handbook of Agile Software Craftsmanship.

En este libro, el "tío Bob" hace hincapié en la importancia de escribir código limpio por aquello de que el código se escribe sobre todo para ser leído y mantenido por otros compañeros o incluso por el mismo programador en el futuro. Si el código no es limpio, no será mantenible, no se entenderá bien. Aunque aquí se puede encontrar un breve resumen del mismo, creo que la siguiente cita es la reseña más significativa.

Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way.

A priori es difícil oponerse a semejantes principios, y ese tampoco es precisamente el objetivo de este post. El problema aparece cuando estos principios dejan de ser herramientas y pasan a convertirse en el objetivo, cuando la mayor parte del esfuerzo se dedica a la limpieza de la solución en vez de a la conveniencia de la misma.

Los programadores somos muy dados a aferrarnos a sólidos principios irrefutables que nos guíen en la inmensidad del caos que nos rodea. Quizás debido a nuestra mente técnica, buscamos el determinismo, en todo. No hay nada más aterrador que un programa que funciona solo a veces. Y esto no es malo, ni mucho menos, pero ocasiona una tendencia natural a la intransigencia.

Cuando yo estudiaba ingeniería informática en la universidad allá por el 2002, tenía la sensación de que la industria del software se centraba mucho, demasiado, en la eficiencia computacional. Estudiábamos y analizábamos algoritmos y el orden de su complejidad (la gran 'O'). Lo que primaba era que los problemas se solucionaran desde una perspectiva muy matemática, y por eso las matemáticas eran fundamentales en la carrera. Creo recordar que yo tuve 5 asignaturas diferentes de matemáticas. En cuanto al proceso de desarrollo software, lo que se llevaba era definir los requisitos en documentos contractuales cuidadosamente elaborados que definían todas y cada una de las funcionalidades del programa a entregar al cliente. La técnica (que no lenguaje) UML era "el futuro". Hoy en día esto ya suena bastante a anticuado, y la experiencia fue demostrando poco a poco que el desarrollo del software no era equiparable a las ingenierías clásicas. La metodología "waterfall" y las "big bang releases" (disculpen los anglicismos) estaban condenadas a desaparecer porque conllevaban un riesgo tremendo de insatisfacción en el cliente que esperaba meses pacientemente a que le entregaran su producto para descubrir, en los peores casos, que lo entregado no era lo esperado. Momento en el cual, los departamentos legales entraban en acción e iban revisando uno por uno el contrato de requisitos para ver quién tenía la culpa. Y, claro, así no se hacían amistades muy duraderas.

La mayoría de los proyectos software fracasaban y los datos apuntaban a que la mayor parte de las veces el problema estaba en el manejo de expectativas del cliente y en la mala comunicación. Llegó entonces la revolución Agile. Lo importante empezaba a ser la comunicación y la colaboración. Con entregas más pequeñas y constantes de valor, nos asegurábamos de que el cliente tenía una visión clara de cómo iban las cosas y de que se podría reaccionar a tiempo si algo se desviaba de lo pactado. Se abría la puerta al feedback, al prototipado y a una serie de técnicas cuyo objetivo era fomentar un canal de comunicación fluido con el cliente. La documentación seguía existiendo, pero con un papel mucho menos relevante. Los requisitos ya no estaban definidos al dedillo ni eran inamovibles, de hecho podían cambiar a medida que las necesidades del negocio o las prioridades cambiaban. Los desarrolladores comenzaban a abarcar más y más aspectos del ciclo de vida del software, se convertían en verdaderos ingenieros.

Es entonces cuando aparece el libro de Clean Code poniendo a los desarrolladores en el centro. Ya no solo somos ingenieros, somos verdaderos artistas. ¡Lo que nos faltaba para alimentar nuestro ego! Se acabó eso de hacer las cosas deprisa y corriendo, se acabó lo de la jerarquía donde los requisitos nos llegan desde arriba ya definidos. Ahora se pueden discutir, pulir, modificar. Lo importante es la calidad del código. "Mira, esto no sé si es lo que quiere el cliente, los requisitos son muy vagos porque el product owner no es muy ducho, pero he usado varios patrones de diseño y he seguido a rajatabla los principios SOLID." (vale, estoy exagerando, pero un poco de dramatismo en esta época revolucionaria no viene mal).

La agilidad es un gran avance respecto a lo que había. Pero no hay que olvidar que surgió en un momento en el que la industria del software estaba gravemente lastrada por la rigidez descrita anteriormente. Los valores agiles son estupendos, se fomenta la colaboración, la valentía para discrepar, la satisfacción y la autonomía de los equipos de desarrollo. Aquí llega e