Como comenté en la anterior entrada estoy leyendo el libro Clean Code. Bueno realmente son dos, uno más técnico, más de código y otro, que todavía no he empezado, que parece más filosófico. No se porqué Amazon los ha juntado en un único libro, me parece un poco más incómodo.
Siempre me ha interesado el tema de la calidad en el código, tan ignorada hasta hace poco, así que este libro al principio no me aportaba mucho, porque expone conceptos que ya conozco, pero poco a poco va mejorando.
Me ha resultado especialmente interesante el capítulo sobre la documentación que estoy leyendo. A pesar de lo que pueda parecer de que va a proponer documentar todo, no lo hace. Propone que mejor que trabajar en explicar, es decir documentar, un código complejo o difícil de entender, lo que hay que hacer es trabajar en hacer que el código sea autoexplicativo.
Comparto con el autor el planteamiento de que hoy día los entornos de desarrollo permiten hacer tareas que antes no se podían. Me explico.
Antiguamente cuando se trabajaba con IDE que eran poco más que un editor de texto con resaltado no era posible hacer refactorización, es decir cambiar el código para que siga haciendo exactamente lo mismo, pero de forma más eficiente u ordenada. Tampoco se había generalizado el TDD, que te permite cambiar el código y ejecutar todas las pruebas para comprobar que funciona todo. Así que cuando conseguías hacer que tu código funcionase no tocabas ni una coma, que ya se sabe: «Si funciona no lo toques»
Tampoco estaba tan extendido el empleo de repositorios de código, con lo que volver a una versión anterior era más farragoso.
Pero a día de hoy todas estos temas están superados, el problema es que seguimos con muchas de las inercias de cuando había más limitaciones.
Me resulta parecido a utilizar Windows 8 que a pesar de su nueva interface la he seguido utilizando como las versiones anteriores…
Me parece muy recomendable para cualquier programador, sobre todo los más noveles, el leer el libro Clean Code