Clean Code: Qué Es y Por Qué Deberías Aplicarlo Hoy

“Clean Code” de Robert C. Martin es uno de esos libros que todo desarrollador acaba leyendo tarde o temprano. En su capítulo introductorio Martin expone los principios y prácticas necesarios para escribir código limpio y de alta calidad. Estos son los conceptos que más me interesaron.

WTFs/minuto: la medida de la confusión

Uno de los indicadores más reveladores del estado del código es la cantidad de “WTFs/minuto” que sueltas al leerlo. El término es medio broma, pero funciona: cuenta las veces que piensas “¿qué narices hace esto?” al revisar un fragmento. Cuantos más WTFs, peor estructurado está el código. El objetivo es bajar ese contador al mínimo. Un código limpio se entiende a la primera.

Maestría = conocimiento + trabajo

Martin insiste en que no basta con leer sobre principios, patrones y prácticas. El conocimiento solo es la mitad. La otra mitad es la práctica. Y la práctica duele: es volver a un código tuyo de hace un año y darte cuenta de que lo harías distinto hoy. Esa iteración constante es lo que separa a quien sabe escribir código limpio de quien solo lo ha leído en un libro.

El futuro del código y los programadores

Cada dos por tres aparece un artículo diciendo que los programadores vamos a desaparecer. Martin lo tiene claro: las herramientas cambian, el código no se va a ningún sitio. Alguien tiene que diseñar, revisar y mantener sistemas que funcionen. Lo que sí cambia es el listón: cuanto más potentes son las herramientas, menos margen hay para escribir código mediocre.

Código incorrecto: ya lo solucionaremos

Esta es la mentira que más daño hace en un proyecto. “Esto lo arreglamos después”. Martin la llama la Ley de LeBlanc: “Después igual a nunca”. Y tiene razón. Llevo suficientes proyectos encima para saber que ese TODO que te prometes resolver “cuando haya tiempo” sigue ahí tres años después. Si detectas código malo, arréglalo ya. Mañana ya no te acordarás.

El coste total de un desastre

El código malo se paga con intereses. Martin lo explica bien: trabajar sobre código de baja calidad que ha escrito otro es una tortura. Cada cambio tarda más que el anterior, la productividad cae en picado y, llega un momento, se acerca a cero. Si además metes gente nueva en el equipo, la cosa empeora: nadie conoce los puntos calientes, nadie sabe qué puede tocar sin romper algo. Por eso Uncle Bob dice que escribir código limpio no es rentabilidad, es supervivencia profesional.

Actitud: defender el código

La calidad del código es tuya. No es del cliente, no es del product owner, no es del jefe que te mete prisa. Defiéndela con la misma fuerza con la que defiendes los plazos o los requisitos. Si no lo haces tú, no lo va a hacer nadie.

El enigma de los programadores

Hay una contradicción que vemos todos: sabemos que los atajos ralentizan el trabajo, y aun así los cogemos cuando el plazo aprieta. Martin es tajante aquí: cumplir plazos no exige ensuciar el código. Al revés. La única forma de cumplir plazos de forma consistente es manteniendo el código limpio. Los atajos de hoy son los bloqueos de la semana que viene.

Reconocer y crear código limpio

Una cosa es reconocer código limpio y otra muy distinta escribirlo. Para ilustrarlo, Martin tira de la teoría de las ventanas rotas: un fragmento descuidado invita a descuidar el siguiente. El código limpio hace una cosa y la hace bien. Presta atención a los detalles. Y sobre todo, cuesta tiempo: la simplicidad no es gratis, hay que trabajarla.

La regla del Boy Scout

Esta es probablemente la idea más práctica del capítulo. Deja el código mejor de como lo encontraste. No hace falta refactorizar el módulo entero: renombra una variable mal puesta, extrae un método que estaba oculto en 80 líneas, borra un comentario obsoleto. Pequeños cambios, cada vez que tocas el código. Así no necesitas grandes refactorizaciones, porque el código nunca se degrada lo suficiente como para necesitarlas.

Conclusión

“Clean Code” es uno de esos libros que no envejece. Actitud, conocimiento y práctica: esos son los tres pilares. Si todavía no lo has leído, hazlo. Y si ya lo leíste hace años, dale una segunda vuelta. Yo vuelvo a él de vez en cuando y siempre saco algo nuevo.

PD: En futuros posts iré hablando de los otros capítulos que me parecen más interesantes del libro. Si tenéis cualquier duda podéis poneros en contacto conmigo enviando un DM por twitter.