Hace mucho que no comento libros. Lo más curioso es que el libro que os traigo hoy siempre fue, en mi cabeza, el primero que debí haber traído. Esa fue la idea originalmente, pero después decidí omitirlo porque, aplicado al desarrollo de puro X++ no tenia tanto sentido. Lo tenía, de hecho, pero sólo podía apreciarse después de leerse el libro, así que era un mal aliciente para fomentar su lectura.
“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.”
Sin embargo me he visto últimamente consultándolo a menudo (y otros que comentaré también) al pensar e investigar sobre Dynamics 365 for Finance and Operations, el nuevo modelo de Extensiones, y el esfuerzo que el equipo de producto está haciendo para hacer el sistema más “extensible“. Os lo resumo: están haciendo el código más limpio, más Clean Code, porque el código limpio es extensible por definición:
Así que me viene al pelo, por fin, hablar de este libro (está traducido como Código Limpio, aunque es más caro que el original en inglés):
La verdad es que es difícil comentar este libro porque prácticamente cualquier desarrollador en cualquier tecnología debería leerlo antes de hacer ninguna otra cosa. Si tienes unas pocas horas de formación al año, leer este libro es probablemente la mejor inversión de ese tiempo, sea cual sea el lenguaje o la plataforma para la que desarrollas, y eso incluye por supuesto Microsoft Dynamics y en particular X++ (y sobre todo en la nueva versión).
El libro trata todos los aspectos de la tarea de escribir código de manera profesional (esto es, código que debe ser mantenido, actualizado, ampliado y rentable), como el propio Martin (también conocido como Uncle Bob) escribe:
“One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand.
Sobre todo la primera parte cubre todos los niveles de la tarea de escribir código que sea fácil de entender (y por tanto, de mantener). Esto es muy importante porque es la base para que después funcione la técnica de extensiones (que hemos heredado de C#):
“Functions should do one thing. They should do it well. They should do it only.”
Incluye todos los aspectos del código, incluyendo los comentarios:
“Redundant comments are just places to collect lies and misinformation.”
Y también los test, acuñando términos como los Clean Tests: F.I.R.S.T (Fast, Independent, Repeatable, Self-Validating, Timely). Durante este recorrido, el texto va profundizando en la forma de pensar que después nos llevara a conceptos más complejos como los patrones de diseño, o los principios del diseño orientado a objetos como S.O.L.I.D.
Si has leído la documentación sobre Extensiones en Dynamics 365 for Finance and Operations, te sonarán al menos dos de esos principios: la O (Open-Clossed Principle) y la L (Liskov Substitution Principle). Tanto si te suenan como si no, pásate por el Dynamics Saturday de Madrid el 19 de Mayo porque hablaremos de ellos y de más cosas interesantes 🙂
También profundizaré sobre estos principios y patrones en los próximos artículos de este blog y el de mi departamento en Microsoft: Dynamics AX in the Field.
Stay tuned!
