Antes de entrar en qué es Clean Code, déjame que te haga algunas preguntas:
Lo siento mucho, pero esta serie de posts no son para ti. Aquí perseguimos otro objetivo, aquí queremos hacer las cosas bien y para ello nos subiremos a los hombros de gigantes como Michael Feathers, Uncle Bob o Kent Beck, para establecer el Código Limpio como nuestro dogma, el TDD como nuestra forma de vida y quién sabe, quizá en un futuro que el CI/CD no sólo sea algo sobre lo que uno lee en un blog, sino que tengamos la absoluta certeza de que el código que hemos hecho esta mañana se puede pasar a producción directamente sin que nadie pierda el sueño.
Para llegar a ello, en estos posts trataremos de ir explicando pequeños conceptos sobre calidad del código y cómo aplicarlos para que poco a poco nos vayamos acercando a ese ideal de calidad al que todos deberíamos aspirar. Jamás llegaremos a ser los programadores perfectos, pero cada día estaremos un poco más cerca.
Dividiremos los posts en una parte de teoría y una parte práctica de aplicación y como es más frecuente trabajar en proyectos ya asentados, en los que “ponle un -DskipTests para que tire” es lo primero que te dicen al entrar, los ejemplos no los basaremos tanto en crear código limpio como en limpiar código sucio.
¿Qué consideramos Clean Code?
En la introducción del Clean Code, Robert C. Martin pone varias definiciones de código limpio según pesos pesados de la industria. Como los 10 años de experiencia en desarrollo del que escribe no son nada comparando con los grandes, me falta mucho que aprender y no voy a dar una definición absoluta de qué es código limpio. Lo que haré es decir que el código limpio, de momento, es código que da gusto leer, y ya iré mejorando la definición en los sucesivos posts.
¿Por qué es tan importante?
Lo importante es que el código funcione, y si alguien lo lee y no lo entiende es porque esta es una profesión difícil y esa persona no es lo bastante lista.
Tristemente, la mayor parte de los programadores siguen a rajatabla esta frase, de forma consciente o inconsciente, y en muchos casos, la persona que no es lo bastante lista es el propio programador 6 meses más tarde.
Y es que, no haber hecho un buen trabajo trae consecuencias. En el mejor de los casos, vas a perder varias horas intentando descifrar qué hacía aquel método en el que tuviste la genial idea de nombrar los parámetros de entrada como u1 y u2, o perdiéndote, siguiendo el flujo infernal de ese método de 500 líneas con ifs anidados en 5 niveles.
En el peor de los casos, estarás corrigiendo un bug e introducirás otro porque la ausencia de tests no te ha avisado de que tu corrección no está teniendo en cuenta alguna casuística o tendrás que cambiar el validador de importes para que acepte el punto y la coma como separador del decimal y como en el proyecto la costumbre de hacer una pantalla nueva es copypastear una similar y modificarla, pues te has dejado sin aplicar el cambio en media aplicación.
Pensándolo mejor, si consideras que hacer un método de mil líneas que “funciona” es hacer un buen trabajo, igual necesitas más que nadie esta serie de posts.
