Modificabilidad, capacidad de prueba y desplegabilidad: diseñar para el cambio

Tres cualidades relacionadas con el cambio

La mayor parte del costo de un sistema de éxito se produce después de su primer lanzamiento, a medida que se cambia una y otra vez. Tres cualidades relacionadas describen lo bien que una arquitectura lo facilita. La modificabilidad trata del costo y el riesgo de hacer un cambio. La capacidad de prueba (testabilidad) trata de la facilidad con la que puedes demostrar, mediante pruebas, que el sistema (o una parte de él) se comporta como se pretende, y de la facilidad con la que los defectos se ponen de manifiesto. La desplegabilidad trata de la rapidez, la seguridad y la previsibilidad con que un cambio puede ponerse en producción, y retirarse de nuevo.

Están unidas en un ciclo. Un cambio solo es barato si puedes hacerlo en un único lugar (modificabilidad), saber rápidamente que no has roto nada (capacidad de prueba) y ponerlo en producción sin ceremonias (desplegabilidad). Un sistema modular pero sin pruebas rápidas seguirá cambiando despacio, porque cada cambio necesita semanas de pruebas de regresión manuales. Un sistema con buenas pruebas pero con una ventana de lanzamiento trimestral seguirá entregando valor despacio.

Modificabilidad: cuatro preguntas sobre cualquier cambio

Bass, Clements y Kazman sostienen que la modificabilidad no tiene sentido hasta que dices qué se espera que cambie. Planificar para todos los cambios posibles produce un sistema sobrediseñado, lleno de puntos de extensión que no se usan; no planificar para ninguno produce un sistema en el que cada cambio es una reescritura. Cuatro preguntas precisan el requisito.

¿Qué puede cambiar? Funciones, plataformas (una nueva versión de la base de datos, el paso a otra nube), el entorno (una nueva API de un socio, una nueva normativa), las cualidades (el doble de carga) o la capacidad. ¿Qué probabilidad tiene el cambio? Dedica el esfuerzo de diseño a donde el cambio es probable: los proveedores de pagos, las normas fiscales y las interfaces de usuario cambian a menudo; el concepto de pedido rara vez lo hace. ¿Quién hace el cambio y cuándo? Un desarrollador al programar, un ingeniero de lanzamientos en el despliegue, un administrador mediante la configuración o un usuario final mediante los ajustes. El momento en que se fija una decisión se llama su momento de vinculación (binding time). ¿Cuánto cuesta el cambio? El esfuerzo, el tiempo transcurrido y el dinero necesarios para hacerlo, probarlo y desplegarlo, más el número de otros elementos afectados y el riesgo de introducir defectos.

Responder a esas preguntas da un escenario del tipo presentado en la Sección 2.3: Un desarrollador añade soporte para un nuevo proveedor de pagos, sin cambiar ningún módulo existente salvo la configuración, en 3 días-persona como máximo, incluidas las pruebas, sin aumento de los errores en el proceso de pago.

Tácticas de modificabilidad

Las tácticas de Software Architecture in Practice reducen el costo del cambio limitando hasta dónde se propaga. Se basan en dos ideas antiguas, tratadas a fondo en el Capítulo 3. La cohesión mide hasta qué punto las responsabilidades de un módulo van juntas; el acoplamiento mide cuánto depende un módulo de otro. Un cambio probable debería afectar a un único módulo cohesivo, y ese módulo debería estar débilmente acoplado al resto.

Aumentar la cohesión. Divide un módulo que hace dos tareas sin relación (un CustomerService que gestiona tanto el inicio de sesión como los puntos de fidelidad) y mueve las responsabilidades a donde corresponden, para que un cambio probable caiga en un solo lugar.

Reducir el acoplamiento. Encapsular: oculta el funcionamiento interno de un módulo detrás de una interfaz explícita, siguiendo el principio de ocultación de información de David Parnas (1972), para que quienes lo llaman no puedan depender de lo que puede cambiar. Usar un intermediario: pon algo entre dos partes para que ninguna conozca directamente a la otra: un adaptador, un intermediario de mensajes (message broker), un canal de publicación-suscripción, un repositorio delante de una base de datos o un API gateway. Restringir las dependencias: decide qué módulos pueden llamar a cuáles (reglas de capas, un módulo visible solo para su propio paquete) y hazlo cumplir con herramientas. Abstraer los servicios comunes: proporciona el comportamiento compartido una sola vez, detrás de una interfaz, en lugar de copiarlo.

Diferir la vinculación. Fija una decisión tan tarde como sea útil, para que el cambio pueda hacerse más adelante y por alguien más alejado del código: archivos de configuración, variables de entorno, plug-ins descubiertos al arrancar, descubrimiento de servicios y feature flags. Cada momento de vinculación más tardío añade maquinaria (configuración que validar, flags que eliminar, interfaces de plug-in versionadas), así que difiere solo las decisiones que realmente varían.

Capacidad de prueba: controlabilidad y observabilidad

Un componente se puede probar cuando una prueba puede ponerlo en un estado conocido, darle entradas elegidas y ver qué hizo. Dos propiedades lo recogen. La controlabilidad es la capacidad de fijar las entradas y el estado interno de un componente desde una prueba. La observabilidad (en el sentido de las pruebas) es la capacidad de ver sus salidas y el estado interno relevante. El código que lee directamente el reloj del sistema, llama a un servicio de pagos real, elige números aleatorios o escribe en una base de datos compartida es difícil de controlar; el código que oculta sus resultados en un estado privado o solo en el texto de los logs es difícil de observar.

Por eso, las tácticas arquitectónicas de capacidad de prueba buscan dar a las pruebas control y visibilidad, y limitar la complejidad. Aísla las dependencias detrás de interfaces y usa luego la inyección de dependencias: el componente recibe sus colaboradores (un reloj, una pasarela de pagos, un repositorio) desde fuera en lugar de crearlos, para que una prueba pueda pasarle un sustituto. Esos sustitutos son dobles de prueba, un término popularizado por Gerard Meszaros: un stub devuelve respuestas predefinidas, un fake es una implementación ligera que funciona (un repositorio en memoria), un mock comprueba que se hicieron las llamadas esperadas y un spy registra las llamadas para hacer aserciones después. Proporciona interfaces de prueba: ganchos para fijar el estado, grabar y reproducir tráfico o ejecutar en un entorno aislado (sandbox). Limita el no determinismo: evita la concurrencia oculta y el estado global, y haz que el tiempo y la aleatoriedad se puedan inyectar. Limita la complejidad estructural: menos dependencias y ningún ciclo significan preparaciones de prueba más pequeñas.

La arquitectura también da forma a la estrategia de pruebas en niveles superiores. En un sistema de servicios, cada límite necesita pruebas de contrato que comprueben que ambos lados están de acuerdo sobre la API, y unas pocas pruebas de extremo a extremo que recorran el camino real. Un diseño con límites limpios permite que la mayoría de las pruebas se ejecuten rápido y de forma aislada, mientras que un diseño enmarañado obliga a usar pruebas de extremo a extremo lentas y frágiles para todo.

class OrderService:
    def __init__(self, gateway, clock):
        self.gateway = gateway   # anything with charge(amount, card)
        self.clock = clock       # anything with now()

    def place(self, order):
        if self.clock.now().hour >= 23:
            return "kitchen closed"
        return self.gateway.charge(order.total, order.card)

# In a test: full control, no network, no waiting until 11 pm
class FakeClock:
    def __init__(self, t): self.t = t
    def now(self): return self.t

class FakeGateway:
    def __init__(self): self.calls = []
    def charge(self, amount, card):
        self.calls.append(amount)
        return "approved"

Desplegabilidad

La desplegabilidad mide con qué previsibilidad y a qué costo pasa un cambio del commit de un desarrollador a producción, y con qué rapidez se puede deshacer. Se convirtió en una cualidad de primera clase solo en la última década, cuando la entrega continua demostró que la frecuencia de lanzamiento y la estabilidad no son opuestas. La cuarta edición de Software Architecture in Practice (2021) le dedicó un capítulo.

La idea central son los lotes pequeños. Un lanzamiento que contiene un solo cambio es fácil de probar, fácil de razonar y fácil de revertir; un lanzamiento con tres meses de trabajo contiene cientos de cambios que interactúan, así que los fallos son probables y difíciles de diagnosticar. Los lotes pequeños requieren automatización: un pipeline de despliegue que compila, prueba y despliega cada cambio de la misma manera, infraestructura mediante scripts y ningún paso manual que alguien pueda olvidar. Entre las tácticas arquitectónicas están las unidades desplegables de forma independiente (para que el lanzamiento de un equipo no espere al de otro), las interfaces y migraciones de base de datos compatibles con versiones anteriores, los mecanismos de rollback y de roll forward, los despliegues progresivos (lanzamientos canario primero a una pequeña parte del tráfico, conmutación azul-verde entre dos entornos) y los feature flags, que separan desplegar el código de lanzar una función a los usuarios. Los pipelines y las estrategias se tratan en CI/CD y estrategias de despliegue.

El costo de ignorar la desplegabilidad puede ser grave. En agosto de 2012, la empresa de trading Knight Capital desplegó manualmente código nuevo en sus ocho servidores de enrutamiento de órdenes, pero se olvidó de uno. Un flag de configuración reutilizado activó entonces código obsoleto en ese servidor, que inundó el mercado de órdenes, produjo unos 4 millones de ejecuciones en aproximadamente 45 minutos y le costó a la empresa unos 460 millones de dólares estadounidenses. Un despliegue automatizado y verificado, o la eliminación del código muerto, lo habrían evitado cada uno por sí solo.

Medir la entrega: las métricas DORA

El programa de investigación DORA (DevOps Research and Assessment, descrito en Accelerate por Nicole Forsgren, Jez Humble y Gene Kim, 2018, y continuado en informes anuales que ahora se elaboran dentro de Google Cloud) descubrió que un pequeño conjunto de medidas predice el rendimiento de la entrega de software, y que los mejores equipos son rápidos y estables a la vez. El modelo actual tiene cinco métricas de rendimiento de la entrega de software, agrupadas en rendimiento (throughput) e inestabilidad. Sus nombres han evolucionado: el antiguo tiempo medio de restauración pasó a ser el tiempo de recuperación de despliegues fallidos en 2023, y la tasa de retrabajo de despliegues se añadió en 2024.

Dos advertencias. Primera: estas métricas describen el sistema de entrega de un equipo, no a las personas; usarlas para clasificar a las personas invita a hacer trampas. Segunda: son resultados. La arquitectura influye mucho en ellas: los equipos que pueden desplegar su parte de forma independiente, probarla de forma aislada y revertirla rápidamente obtienen mejores resultados, y esa es una de las razones por las que la investigación de DORA relaciona la arquitectura débilmente acoplada con un mayor rendimiento de la entrega.

La mantenibilidad en ISO/IEC 25010

ISO/IEC 25010:2023 agrupa estas inquietudes bajo la característica mantenibilidad, con cinco subcaracterísticas: modularidad (el sistema está formado por componentes discretos, de modo que un cambio en uno tiene un impacto mínimo en los demás), reusabilidad (un activo puede usarse en más de un sistema o para construir otros activos), analizabilidad (la facilidad con la que puedes evaluar el impacto de un cambio, diagnosticar una deficiencia o encontrar las partes que hay que modificar), modificabilidad (el sistema puede cambiarse sin introducir defectos ni degradar la calidad) y capacidad de prueba (se pueden establecer criterios de prueba y realizar pruebas para determinar si se cumplen). La desplegabilidad no tiene una subcaracterística propia en la norma; la instalabilidad y la reemplazabilidad se encuentran bajo la flexibilidad. El modelo es una lista de comprobación, como explica la Sección 2.2; los escenarios son lo que hace concreto cada elemento.