Clean Code: Capítulo 1 – Clean Code

El primer capítulo del libro toma el nombre del mismo y comienza con una frase que solo puedo citar literalmente:

«You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers.»

Empieza hablando del mal código, ese que todos hemos escrito alguna vez por ir demasiado rápido, tener presión por acabar, que haya otras prioridades,…  y cuando a pesar de la chapuza funciona, pensamos: ya lo arreglaré más tarde.

«LeBlanc’s law: Later equals never»

Ese mal código poco a poco va creciendo por todos esos «ya lo arreglaré más tarde» que nunca llegan. Mantenerlo es cada vez una tarea más dura: supone entenderlo, añadir complejidad para que siga funcionando (generalmente con más mal código),… lo que hace que cueste más tiempo y productividad baja. ¿Y cual es la solución generalizada? Contratar a más programadores. Programadores que al encontrarse con semejante código que ademas no conocen aumentan su suciedad de manera exponencial, lo que hace que en vez de solucionar el problema, se acreciente, haciendo que la productividad siga cayendo.

Llega un momento en el que el código es imposible de mantener y se procede a re-diseñarlo de lo que se suele encargar parte del equipo mientras la otra parte sigue con el mantenimiento. Pregunta fácil: Si ahora hay menos gente manteniendo ¿costará más o menos? Si no se dirige con sumo cuidado este re-diseño o se decide que «no hay tiempo para eso» y se sigue en el mismo camino, cada vez la situación ira a peor (provocando entre otras cosas que la gente se empiece a ir, especialmente los buenos) y la app acabará colapsando y cerrando. Aún así, un re-diseño no se hace en unas semanas (el autor habla de hasta 10 años) y se corren los mismos riesgos, pero al menos hay luz al final del túnel. Hay técnicas para tratar con esto reduciendo el impacto, de todas maneras no es nada fácil.

Y la culpa, por duro que suene, es únicamente nuestra, porque no somos profesionales.

Compara la situación con la de un cirujano al que un paciente le dice que no pierda el tiempo lavándose las manos. Tu, como cirujano, sabes mucho mejor que el paciente los riesgos que entraña no hacerlo y debes hacérselo saber, aún cuando no lo quiera ver. Hace mucho hincapié en que es muy poco profesional ceder ante la presión de hacerlo mal y rápido por entregar a tiempo. Y que ceder es un error en si mismo, porque hacerlo mal realmente no acelera el proceso ¿quien no ha sucumbido alguna vez ante la presión y al final ha tardado más que si lo hubiera hecho bien?

He de añadir que he personalmente he vivido casos en los que la respuesta ha sido «la prioridad es entregar a tiempo, si lo hacemos habrá tiempo de corregirlo», a lo que uno no sabe como actual; si seguir enrocado y hacerlo bien con el peligro de no entregar a tiempo, o dejarlo pasar y cuando las cosas se compliquen salir con la baza de «te lo dije» confiando en que la próxima vez te hagan caso, porque si te sales con la tuya lo único que se ve es que no has hecho caso, no todo lo que has evitado.

Vale, he entendido que debo escribir Clean Code pero ¿que es exactamente y como lo hago?

No es fácil de explicar, el autor lo compara con pintar: la mayoría sabemos cuando una pintura es buena o mala, pero eso no significa que sepamos pintar. Se puede adquirir un sentido de Clean Code aprendiendo y aplicando muchas pequeñas técnicas, lo que nos permite no solo distinguir si un código es bueno o malo, sino también como limpiarlo.

Para explicar que es, cita a varios autores:

Bjarne Stroustrup, inventor de C++: I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.

Grady Booch, autor de Object Oriented Analysis and Design with Applications: Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.

“Big” Dave Thomas: Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.

Michael Feathers, autor de Working Effectively with Legacy Code: I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by someone who cares deeply about the craft.

Ron Jeffries, autor de Extreme Programming Installed: In recent years I begin, and nearly end, with Beck’s rules of simple code. In priority order, simple code:

• Runs all the tests;

• Contains no duplication;

• Expresses all the design ideas that are in the system;

• Minimizes the number of entities such as classes, methods, functions, and the like.

Ward Cunningham, inventor de Wiki, co-inventor de eXtreme Programming: You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.

Elegante (agradable), eficiente, con manejo de errores completo (atención al detalle), hace una cosa, legible, práctico, mejorable por otros, testeable (mi querido TDD), mínimo, fácil de entender, escrito con cuidado, lees exactamente lo que esperas, bonito,… da una idea aproximada de lo que debería ser.

El bueno de Bob, compara el aprendizaje del Clean Code con las artes marciales: no hay una única verdad y seguramente estés en desacuerdo con algunas cosas de las que enseña, pero éste es su camino y si lo sigues, llegarás a dominar el arte del kung-fu Clean Code.

Hace énfasis en que pasamos más tiempo leyendo código que escribiéndolo, por lo que tiene mucho sentido escribir un código fácil de leer aunque lleve más tiempo escribirlo.

Uno de los últimos puntos del capítulo es una llamada a aplicar la regla de los boy scouts en nuestra profesión.

¿Te imaginas trabajar en un proyecto donde el código mejora conforme pasa del tiempo?