Dando un repaso a mi biblioteca he vuelto a topar con un libro que me llamó la atención antaño, leí aunque muy por encima y, hoy dándole otro repaso he pensado, ¡qué razón tiene!
El libro se llama Clean Code es de Robert C. Martin, e intenta arrojar un poco de luz sobre el hecho de programar mejor, o como su título indica, hacer el código más claro, más limpio.
Una de las frases iniciales es (al pie de la imagen que he empleado para este artículo): Estás leyendo este libro por dos motivos. El primero es que eres programador. El segundo, quieres ser mejor programador. Hace mención a la clave de todo buen programa: que sea pequeño; algo que la filosofía de Unix nos dejó claro en su enunciado: hacer programas que solo hagan una cosa, pero que la hagan muy bien.
También comenta un problema que surgió, una experiencia personal, en la que desarrollaron una killer app, que todo el mundo quería, se vendió muy bien y comenzó a crecer, más características, pero también más fallos. El crecimiento fue descontrolado y el código empezó a ser cada vez peor. Esto llevó a la empresa a la quiebra.
En este sentido, podemos incluso ver un gráfico de productividad frente a tiempo cuando el código es desordenado y malo:
Cuanto más aumenta el tiempo de desarrollo del software, más cuesta agregar nuevas funcionalidades.
Seguro que ahora se nos vendrán a la cabeza muchos casos vividos acerca de este hecho, muchas vivencias incluso, código heredado que hemos tenido que mantener, reescribir e incluso nuestro propio código después, haberlo tenido que reescribir igualmente porque, erróneamente, seguimos los principios equivocados.
Las claves para escribir buen código, o código limpio y claro, se relatan en este libro, el cual se hace bastante ameno y en algunos puntos bastante divertido, e incluso revelador. Podemos citar algunos de esos puntos, aunque en modo esquemático:
- Cuestión de actitud, obviamente, si consideras que el código bien hecho es inviable para tu día a día, ese el primer punto que deberías de cambiar, ya que no te estás dando cuenta de que, cuanto más barro echas encima, más lento te desplazas.
- Refactorizar debe de ser una tarea cotidiana o al menos parte del desarrollo de una nueva característica, ya que cuando se introduce nuevo código, cambios o correcciones, muchas veces conviene dar un repaso a todo el código y rehacer algunas partes que puedan no tener sentido... o incluso borrar otras que ya no se usen, para no dificultar la lectura de código que está muerto.
Como decía Bjarne Stroustrup: Me gusta que mi código sea elegante y eficiente. La lógica debe ser directa, clara, para que a los fallos les sea difícil esconderse, las dependencias mínimas para facilitar el mantenimiento, el manejo de errores completo acorde a una estrategia planificada y el rendimiento muy próximo a óptimo para no tentar a la gente a hacer código desordenado con optimizaciones sin base alguna. El código limpio y claro hace las cosas bien.
Hay más comentarios de Grady Booch, Dave Thomas, Michael Feathers, Ron Jeffries y Ward Cunningham. Todos ellos comentando y/o definiendo lo que significa, para ellos, el código limpio.
El libro es muy recomendable, por su contenido, por sus enseñanzas y por ver la forma de progresar y hacer código que tenga un tiempo de mantenimiento mayor, es decir, que sea fácil de mantener, extender y corregir.
