Recientemente comencé a releer Clean Architecture de Bob Martin y encontré dos ideas más que quería compartir. Una de ellas (el tema de este artículo) es la naturaleza dual de la forma en que los desarrolladores de software proporcionan valor y beneficios a través del código.
Cuando implementas (o modificas) una característica en tu sistema estás creando valor alterando o expandiendo su comportamiento. La mayoría de los gerentes de negocio (o incluso desarrolladores) creen que esto es todo lo que hay en el desarrollo de software: Encontrar personas que sepan cómo hacer que las máquinas se comporten de una manera específica y pagarles para que lo hagan. Crea requerimientos y ellos los implementarán.
Hay, por supuesto, otra cualidad importante del software que a menudo pasan por alto: La arquitectura/diseño/forma del sistema. Si has tenido la oportunidad de trabajar en proyectos con arquitecturas de distintos niveles de calidad, sabes el impacto que puede tener en el futuro del desarrollo.
Entonces, ¿por qué es tan importante la arquitectura?
Martin argumenta que la arquitectura del sistema es más importante que su comportamiento. Su argumento es que un sistema con buena arquitectura, incluso si carece de características/features, puede ser fácilmente cambiado para acomodar cualquier requerimiento. Lo opuesto no es cierto: Un sistema con mala arquitectura, incluso si hace todas las cosas requeridas para las necesidades de hoy, está condenado a la obsolescencia.
Y sí, el software es suave, así que tienes razón al pensar que todo software puede (técnicamente) ser cambiado. El problema ocurre cuando los costos de hacer los cambios exceden los beneficios, dejando el sistema prácticamente inmutable. La realidad es que la mayoría de los sistemas, tarde o temprano, se vuelven muy difíciles de cambiar al menos en parte: Algunas clases o valores de configuración se enredan tanto que el cambio se vuelve impráctico.
Una buena arquitectura hace que la dificultad de implementar un cambio sea proporcional a su alcance, no al tipo de cambio. Una arquitectura que desarrolla una fuerte preferencia sobre un tipo específico (o tipos) de cambio, y hace que otros sean muy difíciles, eventualmente hará que el desarrollo continuo sea más difícil, es por eso que las buenas arquitecturas usualmente son agnósticas a la forma/tipo-de-cambio y generalizan bien.
Entonces, si es algo tan malo, ¿por qué sucede?
Creo que es una combinación de factores:
La mayoría de los gerentes de negocio no tienen la experiencia técnica para evaluar la importancia de una buena arquitectura. Desde su punto de vista, lo único que importa es que el sistema haga lo que necesita hacer, sin importar cómo esté escrito. La presión del mercado empuja a los desarrolladores a un tren de pensamiento que va más o menos así: Ok, ahora necesitamos poner estas características en producción antes que la competencia. Más tarde, cuando todo esto esté hecho, tendremos tiempo para refactorizar todo a mejor forma. Alerta de spoiler: nunca sucede. Una vez que el sistema llega a producción las demandas y presión solo aumentan. ¡El equipo ahora es responsable del desarrollo continuo, mantenimiento y operaciones!
Lo que sucede después es algo que podrías haber experimentado, sin importar si eres del sector negocio o del técnico: Los cambios se vuelven más y más difíciles de implementar y el proyecto se ralentiza hasta arrastrarse. Los costos de ejecutar el proyecto aumentan año tras año y reclutar más personas no parece solucionarlo.
Esto es frustrante para todos. La gerencia siente como si solo estuviera proporcionando un flujo de cambios con alcance similar, pero cada vez toma más tiempo ponerlos en producción. Los desarrolladores sienten como si les entregaran un flujo de piezas cada vez más complejas para encajar en un monstruo que se vuelve más complejo y difícil de domar.
Ok, entiendo, pero ¿qué puedo hacer?
No hay una respuesta fácil, pero en la mayoría de equipos exitosos, va más o menos así:
Necesitas recordar que eres el principal interesado cuando se trata de la arquitectura y diseño del sistema. Los gerentes de negocio no están equipados para evaluar la importancia de la arquitectura, ¡es por eso que te contrataron! Tu trabajo no es solo hacer que el sistema se comporte de la manera correcta, sino también velar por la calidad a largo plazo del sistema.
Además, las personas están dispuestas a escuchar cuando las apuestas son altas. Un sistema donde la arquitectura viene en el fondo de la lista de prioridades eventualmente llegará a un punto donde los cambios son imposiblemente caros. Habla con los otros interesados y crea el hábito de balancear el desarrollo de nuevas características, corrección de errores y refactorización.
La realidad es que al final del día, nadie más que el equipo de desarrollo realmente se preocupa por la arquitectura del sistema. Así que elige tus batallas, presiona cuando sea necesario y comunica la importancia (y consecuencias) de mantener el sistema saludable.
Te deseo suerte.