domingo, 24 de noviembre de 2013

97 Cosas que un Arquitecto de Software Debe Conocer - Parte 4

Este artículo forma parte de una serie de posts en los que traduzco y resumo los principios del libro 97 Cosas que un Arquitecto de Software Debe Conocer.

Los post anteriores pueden leerse en:
Continuamos con los siguientes 15 principios:
  1. Lucha contra la Repetición: 1) La duplicación es malvada. 2) El trabajo repetitivo frena el desarrollo. La repetición en el código es algo que los desarrolladores finalmente aprenden a filtrar e ignorar al leer el código, pero, incluso aunque los desarrolladores se acostumbren a él, les ralentiza. Como arquitecto, tu responsabilidad es eliminarlo. Para ello, necesitarás frameworks, mejores abstracciones, aspectos o incluso módulos generadores de código. La repetición no va a desaparecer a menos que hagas algo al respecto. Es crucial que los ejemplos que le entregues a tu equipo sean limpios, de intención reveladora, y que no contengan nada más que lo que no puede ser abstraído: el dominio de negocio.

  2. Bienvenido al Mundo Real: El mundo real no es binario. Los clientes cancelan órdenes momentos después de crearlas, los cheques rebotan, las cartas se pierden, las promesas se rompen. Los servicios pueden caerse, ser cambiados sin previo aviso, o no proveer garantía transaccional. Despídete de las viejas y predecibles arquitecturas de pilas de llamadas. Prepárate para responder a los eventos en cualquier momento y en cualquier orden, lanzar peticiones asíncronas y concurrentes, reparar errores mediante compensaciones, reintentos u operaciones tentativas.


  3. No Controles, pero Observa: Construir un sistema flexible deriva en una arquitectura compleja de la cual es difícil obtener el panorama completo. Ser un obseso del control quedó en el pasado. Los sistemas de hoy en día son distribuidos y débilmente acoplados. Los lenguajes de programación modernos soportan reflexión, y casi todas las plataformas proporcionan métricas en tiempo de ejecución. A medida que el sistema se vuelve más configurable, la configuración es otra gran fuente de información. En lugar de diseñar un modelo exhaustivo de la arquitectura, previo al desarrollo, construye una arquitectura flexible, adaptable, y extrae el modelo del estado real del sistema.

  4. Jano, el Arquitecto: Un arquitecto se esfuerza por fusionar la realidad con la visión, el éxito del pasado con el futuro, las expectativas empresariales con las limitaciones del desarrollo. Un buen arquitecto debe tener esas dos cabezas capaces de transportar dos ideas o pensamientos, diferentes metas o visiones, para crear un producto que satisfaga las diversas partes interesadas del proyecto. Un buen arquitecto está abierto a nuevas ideas, herramientas y diseños que mejoren el proyecto, el equipo o la profesión; debe reconocer las buenas ideas y cultivar un ambiente para que crezcan. Como Jano, debe ser guardián de las puertas y los pasillos, abarcando lo viejo y lo nuevo, mezclando la creatividad con la ingeniería, para cumplir los requerimientos y satisfacer las expectativas del futuro.

  5. Los Arquitectos se Enfocan en los Límites y en las Interfaces: Siguiendo el conocido mantra de "Divide y Conquistarás", uno de los trabajos más difíciles del arquitecto es encontrar los lugares naturales para ubicar los límites y definir las interfaces necesarias para construir un sistema de trabajo. Para esto son muy útiles los patrones Bounded Context y Context Mapping del libro Domain-Driven Design. Mientras que el primero ayuda a definir explícitamente el contexto dentro del cual se aplica un modelo, estableciendo límites en cuanto a la organización de los equipos y el uso de partes específicas de la aplicación, como proyectos y bases de datos, el segundo asiste a las relaciones entre esos contextos, forzando a la definición de las interfaces de comunicación entre los mismos. Un Mapa de Contexto es una herramienta poderosa que permite centrarnos en lo que debe estar unido (cohesionado) y lo que debe mantenerse aparte (desacoplado), permitiéndonos "dividir y conquistar" sabiamente de forma comunicativa.

  6. Strategic Domain-Driven Design

  7. Desafía a las Suposiciones; Especialmente a las Tuyas: La suposición es la madre de todas las meteduras de pata. Las buenas prácticas dictan que los arquitectos deben documentar todos los razonamientos detrás de cada decisión, registrando el contexto y los factores que contribuyeron al juicio final. Esta práctica es valiosa porque ayuda a resaltar los supuestos que pueden estar afectando las decisiones importantes sobre el software que se está diseñando. Es importante exponer estos supuestos para futuras re-evaluaciones. Todas las suposiciones deben estar basadas en evidencia empírica relevante. Incluso algo que fue verdad en el pasado, no tiene que seguir siendo verdad en el presente; hasta las buenas prácticas se vuelven obsoletas en algún punto. Constantemente desafiemos los supuestos, justificando nuestras decisiones con fundamentos sólidos, actualizados y relevantes.

  8. Registra tus Razonamientos: ¿Cuál fue la decisión que tomamos? ¿Por qué tuvimos que tomar esa decisión? ¿Qué otras soluciones fueron consideradas y por qué fueron rechazadas? Una bitácora de los razonamientos utilizados para tomar las decisiones es un tipo de documentación que envejece bien, que tarda mucho en desactualizarse. El formato puede variar según el contexto del proyecto, desde notas rápidas en un texto, una wiki o un blog, hasta usar plantillas más formales para registrar todos los aspectos de cada decisión de arquitectura. Es importante que soporte búsquedas así se puede encontrar fácilmente lo que se necesita.

  9. Otórgale Poder a los Desarrolladores: El rol de un arquitecto suele imponer restricciones, pero también tienes la oportunidad de ser facilitador. Asegúrate que los desarrolladores tengan las herramientas que necesitan. El trabajo repetitivo y sin sentido debe ser automatizado siempre que sea posible. Vale la pena asegurarse que los desarrolladores tengan máquinas rápidas para trabajar, ancho de banda suficiente, acceso a software, datos e información. Asegúrate que tienen los skills que se necesitan. Consígueles entrenamiento si lo necesitan. Invierte en libros. Promueve discusiones sobre tecnología. Mantenlos activos en listas, conferencias, incentiva su hambre de aprender. Crea estándares por el bien de la consistencia, y dales libertad para tomar decisiones que no contradigan dichos lineamientos. Protéjelos del trabajo no esencial. La arquitectura debe remover obstáculos, no incrementarlos.

  10. Todo se Trata de los Datos: Una computadora no es nada más que una fantástica herramienta para acceder y manipular pilas de datos. En el fondo, el fin de cualquier algoritmo es transformar datos de una versión a otra. Los datos viven en el núcleo de la mayoría de los problemas. Podemos abordar cualquier lógica de negocio a través de los datos, y así serán más simples de comprender. ¿El sistema está recogiendo los datos correctos en el momento correcto? ¿Quiénes son los que pueden ver esos datos y modificarlos? La funcionalidad es lo que vemos primero, pero son los datos los que conforman el núcleo de todos los sistemas.


  11. Controla los Datos, no sólo el Código: El versionador de código y el servidor de integración continua son herramientas excelentes para manejar la construcción de aplicaciones y sus procesos de despliegue. Pero, ¿qué herramientas usamos para controlar los datos? Por alguna razón los datos suelen ser pasados por alto durante el planeamiento de una arquitectura. Así es que nos encontramos con esquemas incompatibles, datos inconsistentes, violaciones de restricciones, y sumémosle a esto que los problemas de base de datos son tediosos de revertir. Es altísimo el valor de un proceso automatizado de construcción que sea capaz de restaurar los datos a un estado conocido si algo salió mal. Los cambios de base de datos no deben crear un nudo es tu continuum de construcción. Debes ser capaz de construir la aplicación entera, incluyendo la base de datos, como una sola unidad.

  12. No Estires las Metáforas Arquitectónicas: Cuando las metáforas se extienden demasiado tiempo a veces pueden volverse en contra del arquitecto. Al cliente puede comenzarle a gustar más la metáfora que el sistema propuesto, por ejemplo, en la que no hay limitaciones reales. O el equipo de desarrollo puede pensar que la metáfora es más importante que el problema de negocio real y así comienzas a justificar decisiones extrañas. El sistema entregado puede contener reliquias de nombres de antiguas metáforas rotas, testimonios arqueológicos de conceptos que fueron refactorizados hasta mutar en abstracciones completamente distintas. La moraleja es: no te enamores de tus metáforas, úsalas con fines exploratorios de comunicación y no dejes que se vuelvan en tu contra.

  13. Enfócate en el Soporte y el Mantenimiento: El soporte y el mantenimiento nunca deben ser pensamientos tardíos. Dado que más del 80% del ciclo de vida de una aplicación se gasta en el mantenimiento, debemos prestar mucha atención a los problemas de soporte y mantenimiento cuando diseñamos. Para un arquitecto es fácil pensar como desarrollador, ya que la mayoría en el pasado fuimos desarrolladores y no administradores. Dificultades típicas que podemos encontrar en un ambiente de producción: requests que no pueden volverse a mandar para reproducir un problema, usuarios y CEOs enojados porque encuentran bugs, imposibilidad de debuggear, despliegues que deben planificarse, coordinarse con distintas áreas, imposibilidad de detener la aplicación para testear un bug, nivel de log mucho más bajo que en el entorno de desarrollo, etc. Para que las aplicaciones puedan sobrevivir sin sus desarrolladores, se debe: 1) entender que desarrollo y soporte requieren skills diferentes, 2) involucrar a un líder de soporte lo más temprano posible en el proyecto, 3) nombrarlo como un integrante fundamental en el equipo, e 4) involucrarlo en el planeamiento del soporte de la aplicación.

  14. Prepárate para Elegir Dos: A veces renunciar a una propiedad puede conducir a una mejor arquitectura. Las propiedades deseables suelen venir en grupos de tres y tratar de definir y construir un sistema que soporte las tres puede resultar en un sistema que no hace nada bien. Famoso es el ejemplo del teorema CAP (consistencia, disponibilidad y tolerancia a fallos). Tratar las propiedades como doctrinas religiosas no nos dejará pensar en el problema. Empezamos a hablar de desviaciones arquitectónicas en lugar de principios de diseño y a confundir dogmatismo con gobierno. Seamos siempre escépticos. Evaluemos las ventajas y desventajas, y abandonemos propiedades que son muy costosas de implementar. Seamos creativos.

  15. Prefiere los Principios, los Axiomas y las Analogías antes que las Opiniones y los Gustos: Si lo haces, documentar y comunicar tu arquitectura será más simple. Una arquitectura con principios claros libera a su arquitecto de revisar todo y estar en todas partes. No necesitarás ser un adicto al trabajo para asegurar que otros implementen, adapten, extiendan, manipulen tu arquitectura correctamente. En cambio, las opiniones y los gustos sólo conducen a discusiones políticas en las que la autoridad suele ganar. Los principios y axiomas le dan a la arquitectura consistencia a través del tiempo.

  16. Comienza con un Esqueleto Caminante: Una estrategia muy útil para implementar, verificar y evolucionar la arquitectura de una aplicación es empezar con lo que Alistair Cockburn llama un Walking Skeleton, una mínima implementación de punta a punta de tu sistema (arquitectura ejecutable) en donde intervienen todos los componentes arquitecturales principales. Una vez que el esqueleto está en su lugar, es el momento de ponerlo a rodar. Esto significa hacerlo crecer incrementalmente, agregándole funcionalidades completas. El objetivo es mantener el sistema en funcionamiento, a la vez que crece el esqueleto. Esto va muy de la mano con lo que se suele llamar Arquitectura Ágil o Arquitectura Evolutiva, donde el esqueleto evoluciona en un proceso de diseño continuo, mostrando sus falencias en etapas tempranas del proyecto para que los cambios sean menos costosos. Fail fast, fail cheap.
Fuente: Rinat Abdullin @abdullin