- Just Enough Software Architecture de George Fairbanks parte de la idea de que el conocimiento de la gramática de un lenguaje o de UML por sí solo no basta para diseñar buenos sistemas orientados a objetos y una buena arquitectura
- La idea central es la arquitectura guiada por riesgos: cuando el riesgo es bajo, se evita el sobre-diseño, y cuando hay riesgos que amenazan el éxito, se aplican técnicas más rigurosas
- Trata la arquitectura no como algo exclusivo de unos pocos expertos, sino como una capacidad que todos los desarrolladores deberían comprender, y explica cómo las restricciones y los pequeños cambios afectan las propiedades del sistema
- En lugar de enfocarse en procesos de desarrollo u operación organizacional, se centra en técnicas de ingeniería, para abordar los trade-offs de diseño en problemas medianos y grandes mediante modelado y análisis de arquitectura
- Está compuesto por dos partes, arquitectura de software guiada por riesgos y modelado de arquitectura, y cubre abstracciones como modelo de dominio, modelo de diseño, modelo de código, encapsulación, componentes y conectores
Capacidad de diseño: más allá del conocimiento del lenguaje y UML
- El autor parte de la inquietud de crear el libro que él mismo necesitaba cuando comenzó en el desarrollo de software
- En ese momento había libros sobre lenguajes de programación u orientación a objetos, pero pocos que trataran el diseño
- Saber las características del lenguaje C++ no basta para diseñar un buen sistema orientado a objetos, y conocer UML tampoco basta para diseñar una buena arquitectura de sistema
Arquitectura ajustada al riesgo
- El núcleo del libro es el risk-driven architecting
- Cuando el riesgo es pequeño, no hace falta un diseño minucioso, y cuando existen riesgos que amenazan el éxito, un diseño improvisado no es suficiente
- Varios defensores de Agile consideran que cierto diseño previo puede ser útil, y este libro trata cómo hacer “la arquitectura suficiente”
- Evita procesos de tipo “one size fits all” y guía a ajustar el esfuerzo de arquitectura y diseño según los riesgos que se enfrentan
- La mayoría de las técnicas pueden graduarse desde un nivel quick-and-dirty hasta un nivel muy riguroso
Hacer de la arquitectura un lenguaje para todos los desarrolladores
- El libro tiene el objetivo de democratizar la arquitectura
- Puede que haya un arquitecto de software en la organización, o que el propio lector sea ese arquitecto
- Muchos arquitectos quieren que todos los desarrolladores entiendan la arquitectura
- Si los desarrolladores no entienden por qué existen ciertas restricciones ni cómo pequeños cambios afectan las propiedades del sistema, su criterio de diseño puede volverse inestable
- La arquitectura no es un tema exclusivo de arquitectos, sino algo relevante para todos los desarrolladores de software
Conocimiento procedimental y conocimiento declarativo
- El libro se enfoca en desarrollar conocimiento declarativo
- Poder golpear una pelota de tenis y saber por qué se puede hacer son cosas distintas; eso corresponde a la diferencia entre conocimiento procedimental y conocimiento declarativo
- Si ya eres un profesional que diseña y construye sistemas, es posible que ya hayas usado muchas de las técnicas del libro
- El libro ayuda a reconocer mejor lo que ya venías haciendo y a ponerle nombre a esos conceptos
- Ese conocimiento declarativo también ayuda a mejorar la capacidad de mentorizar a desarrolladores principiantes
Enfoque en ingeniería más que en procesos
- Quienes diseñan y construyen sistemas de software también deben lidiar con temas como cronogramas, compromisos de recursos y requisitos de stakeholders
- Muchos libros de arquitectura de software ya cubren procesos de desarrollo y estructuras organizacionales
- Este libro, en cambio, se concentra en la parte técnica del desarrollo de software y en la ingeniería necesaria para que el sistema funcione
- Permite crear modelos y analizar la arquitectura para hacer trade-offs de diseño con criterio
- Explica técnicas para razonar sobre problemas medianos y grandes, y también señala dónde aprender con más profundidad técnicas especializadas
Diseño práctico entre múltiples niveles de abstracción
- El libro trata la arquitectura como una actividad de diseño práctica
- La arquitectura de software es un tipo de diseño de software; las decisiones de diseño afectan la arquitectura, y la arquitectura también afecta el diseño
- Los grandes desarrolladores profundizan en los obstáculos para entenderlos en detalle y luego conectan la naturaleza de esos obstáculos con la arquitectura general
- Reflejando ese comportamiento de drill-down/pop-up, cubre modelos en varios niveles de abstracción, desde la arquitectura hasta el diseño de estructuras de datos
Estructura y formatos disponibles
- El libro está compuesto por dos partes
- Part I: Risk-Driven Software Architecture
- Part II: Architecture Modeling
- Algunos capítulos de muestra pueden descargarse en un solo PDF
- El libro electrónico se vende en Google Play e incluye tres formatos sin DRM: ePub, Mobi y PDF, con un precio de $9.99
- La edición en tapa dura está disponible en Amazon
- Google Books y Amazon Search Inside ofrecen versiones con búsqueda de texto completo
Alcance y lo que queda fuera
- El libro se enfoca en la arquitectura de software relacionada con la construcción de software
- Explica técnicas para que el software satisfaga requisitos de ingeniería
- Como las técnicas de ingeniería en sí suelen ser independientes del proceso, el libro también evita atarse a un proceso específico en la mayor parte de su contenido
- No aborda consejos sobre actividades de gestión como las siguientes
- las responsabilidades políticas del arquitecto
- cuándo realizar ciertos tipos de reuniones
- cómo recopilar requisitos de los stakeholders
Part I: Arquitectura de software guiada por riesgos
- Es difícil definir con precisión la arquitectura de software, pero algunas de sus características son claras
- Los desarrolladores de software, al igual que los ingenieros de otras disciplinas, usan abstracciones y modelos para resolver problemas grandes y complejos
- La arquitectura de software funciona como el esqueleto del sistema, influye en los atributos de calidad, es ortogonal a la funcionalidad y afecta las propiedades del sistema mediante restricciones
- La arquitectura es especialmente importante en las siguientes situaciones
- cuando el espacio de soluciones es pequeño
- cuando el riesgo de fracaso es alto
- cuando se enfrentan requisitos difíciles de atributos de calidad
- El enfoque de diseño puede elegirse entre architecture-indifferent design, architecture-focused design y architecture hoisting
- El procedimiento central del modelo guiado por riesgos es simple
- identificar y priorizar riesgos
- seleccionar y aplicar un conjunto de técnicas
- evaluar la reducción del riesgo
- El capítulo 4 muestra la aplicación del modelo guiado por riesgos con el ejemplo del sistema Home Media Player
- comunicación del equipo
- integración de componentes COTS
- garantizar la consistencia de metadatos
- Part I cierra con recomendaciones sobre el uso de modelos y arquitectura de software
- usar modelos para resolver problemas
- agregar restricciones con cuidado
- enfocarse en los riesgos
- distribuir la capacidad arquitectónica en todo el equipo
Part II: Modelado de arquitectura
- Part II se enfoca en ayudar a formar un modelo conceptual de la arquitectura de software
- La estructura básica de modelos es de tres tipos
- modelo de dominio: corresponde a objetos del mundo real
- modelo de diseño: representa el diseño del software que se está construyendo
- modelo de código: corresponde al código fuente
- Se pueden crear vistas (view) como modelos adicionales que muestran detalles seleccionados, y esas vistas pueden agruparse por viewtype
- Crear límites de encapsulación es una técnica importante de la arquitectura de software
- los usuarios de componentes o módulos pueden ignorar el funcionamiento interno y concentrarse en otros problemas difíciles
- quienes implementan componentes o módulos encapsulados ganan libertad para cambiar la implementación sin afectar a los usuarios
- esa libertad solo es posible cuando la encapsulación funciona de manera efectiva, por lo que el libro cubre técnicas para garantizarlo
- Integra técnicas de arquitectura de software provenientes de varias fuentes
- técnicas que enfatizan los atributos de calidad
- técnicas que enfatizan la funcionalidad
- métodos prácticos para crear modelos efectivos
- cómo depurar modelos
- Part II también cubre trampas que pueden aparecer al usar estas técnicas, junto con consejos para usar los modelos de forma efectiva
- El objetivo final es contar con un modelo conceptual rico sobre abstracciones y relaciones, y poder observar sistemas de software como un entrenador observa un partido
1 comentarios
Opiniones de Hacker News
Se dice que si el riesgo de gestión de proyecto es “un desarrollador clave es atropellado por un autobús” y el riesgo de ingeniería de software es “el servidor quizá no escale hasta 1000 usuarios”, hay que distinguirlos, pero en mi experiencia no suelen separarse tan claramente.
La calidad y estructura del código, las pruebas y la documentación, y el uso de herramientas estándar y bien conocidas ayudan en ambos lados.
Por eso muchas veces les planteé a colegas o jefes la hipótesis de “¿y si te atropella un autobús?”, y eso se convierte en un mecanismo de presión para crear software reproducible y comprensible.
Si se quiere evitar la connotación negativa de una lesión o muerte, conviene usar “¿y si te ganas la lotería?”
El punto clave de “ser atropellado por un autobús” es que, independientemente de la personalidad, no hay nada de tiempo para prepararse, y por eso surge la presión de compartir la información hoy.
Lamentablemente, todavía no encontré una expresión positiva que implique lo mismo.
Ambos volvieron más o menos una semana después, así que hace falta otro ejemplo estándar de desastre.
Para transmitir la idea, uso más seguido la expresión “la siguiente persona”.
Una situación peor es el burnout: el número de personas sigue igual, pero mentalmente ya se fueron.
Vi muchas empresas que no aguantan ni siquiera eso, sin que sea una salida permanente.
O también se puede usar una expresión que se enfoque en la motivación de eliminar puntos únicos de falla, como “aumentar el factor autobús”.
Si se hace un análisis de causa raíz, no debería detenerse en “Larry fue atropellado por un autobús / se ganó la lotería”; ese no es el verdadero problema.
La arquitectura por la arquitectura misma es lo peor, porque aumenta innecesariamente la complejidad.
El objetivo final de una buena arquitectura es reducir costos.
Si por la arquitectura toma más tiempo desarrollar y mantener el código, esa arquitectura fracasó.
Siempre es un problema de equilibrio.
Por lo tanto, no hay una única arquitectura correcta: la elección depende del contexto y a veces hay que reevaluarla.
La flexibilidad es especialmente útil porque permite ajustar la arquitectura en cierta medida y mantener la eficiencia incluso cuando cambian las circunstancias.
La reducción de costos puede ser uno de ellos.
“El modelo guiado por riesgos lleva a los desarrolladores a aplicar el mínimo de técnicas de arquitectura para reducir los riesgos más urgentes. Es un proceso de preguntarse insistentemente: ‘¿cuál es mi riesgo? ¿cuál es la mejor técnica para reducirlo? ¿el riesgo ya fue mitigado y ahora puedo empezar o retomar la codificación?’. El modelo guiado por riesgos puede resumirse en tres pasos: 1. Identificar y priorizar los riesgos 2. Seleccionar y aplicar un conjunto de técnicas 3. Evaluar la reducción del riesgo”.
No queremos perder tiempo en técnicas de bajo impacto, ni ignorar riesgos que amenazan el proyecto.
Para crear un sistema exitoso hay que elegir el camino que use el tiempo de la forma más efectiva, lo que significa aplicar técnicas de arquitectura y diseño para tratar riesgos solo cuando el riesgo sea la motivación.
Por ejemplo, “arquitectura” también incluye usar un estilo cliente-servidor en el que el servidor no actúa primero y solo responde a solicitudes del cliente.
Este enfoque puede ajustarse bien al problema, o puede no hacerlo.
https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
Arquitectos técnicos que cobran mucho terminan haciendo poco, mientras imponen patrones horribles que los ingenieros de software tienen que resolver bajo restricciones irracionales como las fechas límite.
Una buena arquitectura permite que más personas participen en el producto.
Si se publicó en 2010, me da curiosidad saber cuánto ha sobrevivido desde entonces.
Me gusta “Design It” porque tiene buenos workshops y actividades para técnicos que necesitan interactuar con stakeholders o clientes.
Para mí es más relevante porque estoy en un rol de consultoría, y también me gusta que no dependa demasiado de estilos de arquitectura ligados a tecnologías específicas que cambian con frecuencia.
Lo digo en términos de principios reales, no de modas.
El autor dedica mucho tiempo a ensayos sobre la mentalidad y trata las técnicas concretas de forma ligera, pero ofrece materiales para seguir leyendo.
Hace que el equipo trabaje las ideas de arquitectura mediante actividades concretas y, al final, deja en claro qué es lo importante.
Mi libro intentó abordar de frente esas grandes ideas, pero quedó claro que, por ser un tema tan abstracto, es difícil desde el punto de vista pedagógico.
¿Qué ideas sobrevivieron desde 2010? Algunos sistemas operativos son microkernel, otros son monolíticos.
Algunas bases de datos son relacionales y otras están centradas en documentos.
Algunas aplicaciones son cliente-servidor y otras son peer-to-peer.
Estas distinciones probablemente sean permanentes, y si vuelves dentro de 100 años, aunque ejemplos como Windows, Oracle o Salesforce hayan desaparecido, seguirás viendo sistemas con esos diseños.
Y también seguiremos hablando de cualidades como facilidad de modificación o latencia.
El campo de la arquitectura de software consiste en identificar estas abstracciones permanentes.
En [2] hay una explicación concisa.
“Resumen: La arquitectura de software es un conjunto de abstracciones que nos ayudan a razonar sobre el software que planeamos crear o que ya creamos. Nuestro campo tuvo pequeñas abstracciones desde hace mucho tiempo, pero tomó décadas acumular abstracciones más grandes, como atributos de calidad, ocultamiento de información, componentes y conectores, múltiples vistas y estilos arquitectónicos. Al diseñar sistemas, enlazamos estas abstracciones para preservar una cadena de intencionalidad y hacer que el sistema diseñado haga lo que queremos. Hace 20 años, Martin Fowler publicó en esta revista el influyente artículo ‘Who Needs an Architect?’. Ahora es momento de que los desarrolladores vuelvan a mirar la arquitectura de software y la vean como un conjunto de abstracciones que nos permiten razonar sobre el software”.
[1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/
[2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...
A Philosophy of Software Design, de John Ousterhout, me resultó útil.
Tiene muchos consejos sólidos y fáciles de entender, además de muchos ejemplos.
No conozco este libro en sí, pero sí conozco el artículo del autor sobre Intellectual Control, y es muy perspicaz.
https://www.georgefairbanks.com/ieee-software-v37-n3-may-202...
https://johnwhiles.com/posts/programming-as-theory
En una empresa anterior circuló el libro Software Architecture for Developers, de Simon Brown: https://leanpub.com/b/software-architecture
Todavía lo tengo en mi lista de lectura y ya me fui de esa empresa, pero me lo recomendaron mucho.
Esa empresa también documentaba la arquitectura con el modelo C4.
Me da curiosidad saber si alguien aquí lo leyó.
Sus charlas de arquitectura [1] y workshops son especialmente efectivos, y el lenguaje de modelado de arquitectura C4 [2] también está ganando impulso en la práctica.
Yo también tengo videos en YouTube [3], pero no son igual de efectivos.
[1] https://www.youtube.com/results?search_query=simon+brown+arc...
[2] https://c4model.com/
[3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...
Creo que “dependiente del riesgo” habría sido un nombre mucho mejor para esta metodología.
¿Por qué a los programadores les gusta tanto la expresión “[X]-driven”?
Este eje impulsa ese engrane, y ese engrane impulsa la rueda, y así sucesivamente.
Es una forma abreviada de decir “cuál es el mecanismo más poderoso en esta compleja máquina de pensamiento”.
Hace unos años hicimos un club de lectura de este libro en la empresa, y me pareció muy repetitivo.
Me pregunto si este libro es un buen recurso para alguien que empieza un proyecto open source no trivial.
O si tiene valor para un fundador individual; me gustaría recibir recomendaciones de libros u otros recursos útiles para un desarrollador solo.
La arquitectura de software se parece a la arquitectura común, pero como en software todavía no existe una figura como Isaac Newton, parece que estamos en un estado en el que no existe la ingeniería civil
Creo que hasta ahora la figura más cercana es Claude Shannon
Porque ni siquiera tenemos unidades de medición
En ingeniería de software todavía estamos en la etapa de “esperar que no se derrumbe”
Esto afecta profundamente la productividad autoinformada
Por ejemplo, una bicicleta puede sentirse más rápida que manejar a 30 millas por hora, con las ventanas subidas, por pequeñas calles suburbanas llenas de señales de alto
Pero, por lo general, el conductor llega mucho más rápido a un lugar a 20 cuadras
Si no hubiera unidades de medición, todos estarían discutiendo que la bicicleta es más rápida
La ingeniería de software está ahora en ese estado
Crear software no se parece en nada a construir puentes o rascacielos; más bien se parece a diseñarlos
En los grandes proyectos de arquitectura primero se diseña y después se construye, y ese diseño es un trabajo enorme
Hay que pensar en todo, ejecutar simulaciones, coordinar con las partes interesadas, entender requisitos y restricciones, y considerar costos de materiales, peso, etc.
En los grandes proyectos de construcción, pueden irse meses o años solo en elaborar el diseño, y el resultado es un plano muy detallado que cubre casi todos los aspectos de la construcción
De hecho, esto se parece bastante a crear software
En este tipo de proyectos de diseño hay mucha incertidumbre y riesgo
Aun así, es mejor descubrir que todo está mal antes de empezar a usar recursos caros como mucha mano de obra, concreto y acero
Pero ¿alguna vez escuchaste a un arquitecto decir que va a hacer un diseño para el diseño con el fin de mitigar eso? Eso no existe
A lo sumo, en algún momento pudo haber habido un boceto o un dibujo en una servilleta
SpaceX incorporó algunos elementos ágiles en la ingeniería, algo que aprendió del desarrollo de software
En software, el plano terminado es ejecutable
El proceso de crear el plano es manual, pero el proceso de producir software a partir de ese plano suele estar automatizado con compiladores y otras herramientas, y es muy barato, por eso los desarrolladores lo hacen todo el tiempo
Claro que antes no siempre fue así
El proceso de crear un plano ejecutable, por supuesto, conlleva muchos riesgos, y puede haber diseños en servilletas o pizarrones por todas partes
Pero la idea de hacer primero un diseño completo y luego una implementación completa, es decir, el modelo en cascada, nunca funcionó bien en software
Salvo algunas excepciones, normalmente no hay un plano para el plano
Si lees el artículo original de Royce sobre la cascada, en realidad la palabra “cascada” no aparece en absoluto, y sugiere vagamente que la iteración podría ser una buena idea
Algo así como hacerlo al menos una vez más
Él entendía perfectamente que era muy probable que el primer diseño estuviera equivocado
Agile eliminó, mediante optimización, esa etapa de bajo valor de crear un diseño para el plano, algo que se vuelve evidente cuando se itera mucho
Solo que, fuera de ciertos ámbitos, en general los ignoramos
Por ejemplo, al mirar por encima este resumen y el índice, parece haber poca o ninguna mención a métricas de rendimiento
¿De qué sirve la arquitectura si no considera lo que realmente hace la computadora?
Incluso desde el punto de vista de la productividad de desarrollo o de la interfaz de usuario, ¿por qué no hay modelos matemáticos que describan la pila mental necesaria para desarrollar, modificar, extender y, más importante aún, usar software?
Los recursos de cómputo, ya sean humanos o de máquina, tienen un impacto real y medible en la interacción con el software como desarrolladores o usuarios; ¿por qué se los considera tan rara vez?
Por ejemplo, el Palacio de Westminster tiene sin duda elementos de ingeniería civil, pero sus rasgos decisivos, como las texturas ornamentadas, la emblemática torre del reloj y la distribución interior, están determinados en gran medida por elecciones funcionales y estéticas
Lo mismo ocurre con muchas partes del software