Una de mis quejas recurrentes acerca de la literatura sobre desarrollo de software
es la inmensidad de libros sobre como programar en determinado lenguaje o tecnología,
pero la escases de libros sobre como programar correctamente.
El libro que nos ocupa el día de hoy Clean Architecture, es un libro que
nos enseña los principios para crear un arquitectura en la que se base un software
robusto, potente, y fácilmente escalable.
Clean Architecture es un libro de Robert C. Martin (conoció habitualmente como Uncle Bob),
publicado en el año 2017.
Me gustan especialmente los libros publicados por profesionales de la industria,
es decir gente cuyo trabajo es hacer software, que sabe lo complicado, ambiguo y
fustrante que puede llegar a ser el desarrollo empresarial de software. Es este
libro vamos a encontrar mucho de eso, partes enfocadas en escenarios y problemas
reales, y anécdotas en las que nos vamos a sentir claramente identificados, todo
ordenado de forma clara e incremental.
Académicamente hablando se extraña mucho este tipo de enseñanzas en carrera universitarias
afines al desarrollo de software. Generalmente (y tristemente), las recomendaciones
bibliográficas en los centro de estudios suelen ser libros llenos de teoría y poco
de realidad. Ojala se incorporara este tipo de libros (y varios más de Robert C.
Martin) a las enseñanzas universitarias.
El libro en sí, se centra completamente en temas arquitectónicos, no profundizando
en ningún lenguaje en particular, salvo en contados casos a nivel de ejemplo.
Comienza con una especia de "origen" en que muestra (de manera muy breve), la evolución
de la arquitectura de software a través de diversas paradigmas y ejemplo, todo esto
con la intención de que comprendamos que es la arquitectura de software.
Entre las muchas definiciones que da el libro sobre la arquitectura me quedo con
esta:
"La meta de la arquitectura de software es minimizar los recursos humanos requeridos
para construir y mantener los requisitos de un sistema".
Yo hubiera quitado "recursos humanos" y hubiera dejado simplemente "recursos".
Recursos de cualquier índole: Humanos, económicos, físicos y de tiempo. Pero creo
que el mensaje se entiende.
La arquitectura de software, nos ayudaría entonces a realizar software más barato.
Así se simple. Me gusta esta forma de verlo, porque es sencilla, y fácil de vender
en un ambiente empresarial donde a veces no se da el valor correcto al desarrollo
de software, y se espera un retorno de la inversión clara y rápida.
Una de las ideas que me resultaron mas interesante del libro, es que el software
tiene dos valores principalmente:
- La funcionalidad.
- Arquitectura.
La funcionalidad es el problema de negocio a resolver, es "lo que deben hacer
el sistema", es el valor a corto plazo.
La arquitectura es la capacidad del sistema para cambiar y adaptarse a necesidades
no descubiertas, es el valor a largo plazo.
¿Cuál aporta más a nuestro sistema? El tío Bob, lo explica en las siguientes frases
(extraídas directamente del capítulo dos):
- Si me das un programa que funciona perfectamente pero que es imposible de cambiar dejara de funcionar cuando los requisitos cambian, y no será posible volver a echar a andar, volviéndose inútil.
- Si me das un programa que no funciona pero que es fácil de cambiar , puedo hacer que funcione y que siga funcionando cuando las necesidades cambien, lo que significa que el programa seguirá siendo útil.
Otros capítulos hablan de principios de diseño como los contenidos en SOLID (dedicándolo un capitulo a cada principio, en
lo que creo que es la mejor explicación que he leído)
En otras partes del libro, se profundiza ya claramente en temas puramente arquitectónicos,
para finalmente presentar una modelo de arquitectura:
En dicho modelo los elementos más centrales representan lo más importante para nuestra
arquitectura, lo que es el "núcleo" de nuestra sistema.
Los elementos exteriores representan (como lo llama Robert C. Martin), los "detalles"
de nuestros sistema, elementos que deben ser fácilmente intercambiables y de los
cuales nuestro núcleo debiera ser independientes.
Los detalles son cosas que pueden elegirse tardíamente en nuestro sistema, y que
no son relevantes para él, si nos figamos detenidamente, estos "detalles" suelen
ser decisiones más relacionadas con "aspectos técnicos" alejadas de nuestro negocio.
Base de datos, Framework, elementos de presentación Web, son elementos que tradicionalmente
son decididos en momentos tempranos de una arquitectura de software, y el "tío Bob"
nos dice que son elementos no relevantes en nuestro sistema (en este punto de la
definición), que se pueden seleccionar al final, y cambiar en el caso que sea necesario
por otros semejantes, incluso se pudieran agregar nuevos detalles, como nuevas interfaces
graficas (móviles, web, escritorio), sin tener un impacto fuerte en nuestro sistema.
Para finalizar Robert C. Martin, nos da un recorrido por su vida profesional, y
vemos como ha ido tomando (desde muy temprano) decisiones arquitectónicas mas o
menos acertadas y el impacto real de dichas decisiones, un capitulo (incluso hablando
históricamente) muy interesante para finalizar el libro.
Clean Architecture: A Craftsman's Guide to Software Structure and Design
es publicado por Prentice Hall en el 2017. ISBN-9780134494166. y puede conseguirse
en Amazon.
