Arquitectura de Software vs. el Caos

La verdad que he tenido ganas de escribir sobre este apartado hace un largo rato ya, pero bueno, es tan larga la tela para cortar que no sé bien por donde comenzar. Hoy... acá... más bien definiré cuales son mis impresiones particulares sobre este tema a nivel general, otro día definiré cuales son, bajo mi puto de vista, las formas de organización de los proyectos más adecuados, y una que otra técnica que nos puede ayudar.
Definir una arquitectura, es casi tan difícil como definir que quiere decir arquitectura. Si la misma IEEE, establece sobre arquitectura que no sabe a priori que es, pero que cuando se la vé se la reconoce. Escuchamos, por ahí, a diario en nuestras empresas, que nos dicen: “esto es problema de arquitectura” o “no se puede escalar... la arquitectura no nos lo permite” o algún que otro enunciado apocalíptico que nos deja pensando.
En el mundo informático, o por lo menos acá en argentina, existe una alta rotación de personal en las empresas informáticas, y tenemos que cambiar de entorno laboral con frecuencia. Y cada vez que que nos sumergimos en un nuevo proyecto, encontramos que abrimos el IDE, hacemos un check out de la aplicación y cuando volvemos con taza de café en mano, empezamos a achinar los ojos y a escrolear el árbol de paquetes en el explorador de proyectos, de la misma manera que un peluquero novato mueve el pelo de un lado al otro sin tener idea de por donde comenzar.
Punto para el caos.
Luego después de unos primeros días de total incertidumbre, y de esfuerzos vanos de nuestros instructores por explicar los inexplicable, realizando capacitaciones teóricas, de lo que escasas veces vamos a encontrar en en la aplicación, nos empezamos a preguntar por que no utilizamos algún ultra-mega-re-contra-probado componente que existe ya en el mercado en lugar de tratar de reinventar la rueda trabajando con nuestro rustico-humilde-eterno-beta componente para realizar la misma tarea?
Punto para el caos.
Bien, ya superamos nuestra angustia, y nuestro sentimiento inicial de junior--, ahora es tiempo de realizar el aporte que dejaremos para siempre como una impronta, como una marca de hierro, en nuestra empresa. ¡Vamos a desarrollar un nuevo modulo de negocio para nuestra empresa! ¡Vamos a sentirnos productivos! ¡Ya estamos en condiciones!. Empezaremos por leer la documentación para entender a que APIs le vamos a “pegar” y las capas sobre las cuales nos “pararemos” para construir. Abrimos el repositorio de documentación, si existe, y ...¡WTF!...vemos que está totalmente vacío o con documentación desactualizada.
Otro punto para el Caos, y podría seguir así por un largo rato.
A esta altura del post, podes estar sintiéndote frustrado, ya que no ves una linea de código, ni documentación técnica que diga como hacer tu arquitectura infalible. Solo viste problemas humanos, sentimientos, emociones, frustraciones. Nada técnico. Púes bien. La mayoría de los arquitectos que he conocido, era personas sumamente capacitadas técnicamente, gurues de la tecnología, hombres que se juntaban a tomar mate con neo en la misma matrix. Pero con, con escasos skills de comunicación y poco human-oriented. Hombres que se sentaban en su propio box en un estado de autismo del cual sacarlo sería pecado capital. Lapidación!
Dies puntos para el caos!

“El silencio de un arquitecto, es el peor enemigo de la escalabilidad de un software”

Somos arquitectos, queremos arquitectear!

Bajo mi puto de vista, cada una de las palabras que vaya a citar acá debe ser tomada en cuenta como un test case, el cual cada diseño que realicemos, cada aporte, cada linea, cada acción debe superar.

¡Responsabilidad!

Todo tiene que tener una responsabilidad acotada y definida, cada clase, cada paquete, cada método, cada proceso, cada documento. Se tiene que poder definir rápidamente los inputs y los outputs, y a que se dedica. Esta es la principal palabra de una arquitectura soñada. Si hacemos un método, nos tenemos que preguntar antes de la primera linea de código, ¿a que se va a dedicar este método? En lugar de escribir una cascada de ifs de 100 lineas de código. Ningún método, clase, paquete, etc, etc, debe ser superman, y hacerlo todo. Si tenemos métodos de 300 lineas de código, algo estamos haciendo mal. ¿Estamos trabajando Orientado a objetos, o estamos estoreando lineas de código en un archivo? ¿Cada capa se ocupa de lo que tiene que hacer?

¡Narcisismo!

¿Es nuestro arquitectura narcisista? A la cual podemos ver como un espejo y decirnos lo buen programadores que somos. Lo genios, intelectuales, que utilizamos reflection, recursividad o algún otro recurso “mágico” para realizar una tarea. ¿Son estas tecnologías necesarias? Imaginemos que después de nosotros va a venir otro programador que se va a tener que que pelar los dedos con F5 para poder debuggear nuestro código, en idas y vueltas. ¿Tenemos una arquitectura de 100 capas que nos dará una futura y muy lejana escalabilidad y reutilización? Pero si nuestra empresa tiene una alta rotación de personal, y los requerimientos siempre corren contra el reloj... “the new guy”... va a realizar todos esos métodos? Primero que eso... va a conocerlos? O va a buscar un workaround de código que le permitirá cumplir con los plazos del burndown?. Estudiando nuestra empresa, y sus características, sabremos como se comportará nuestra arquitectura en el futuro. Complejidad innecesaria = narcisismo.

¡Aburrimiento!

Toda idea que se nos cruce para realizar un componente, es probable que ya haya sido pensada. Debe existir por ahí. Bien, frente a una cuasi igualdad de características técnicas, ¿cual de todos los componentes utilizar? ¡el más nuevo, lo nuevo es mejor!
10 punto más para el caos!
Trabajamos en una empresa inmersa en un mercado laboral, con un conocimiento circundante, ¿debemos realmente malgastar tiempo de un recurso en capacitación sobre ese nuevo componente, que desconocemos, del cual existe escasa documentación, o que no tiene una comunidad de soporte amplia al rededor del mundo? O debemos escoger, ese que en una entrevista laboral al preguntar al postulante si ya tiene experiencia en el, nos conteste con una sonrisa y un rotundo - ¡Si! Es probable que ese componente tenga una comunidad amplia al rededor del mundo, con actualizaciones constantes, con documentación en nuestro idioma y cientos de blogs con tips para realizar una tarea. Lo demás, lo nuevo, lo aprendamos en casa, allí podremos hacer pruebas en nuestro sandbox personal sin afectar el proyecto. No agreguemos factores de riesgo, por mas aburridos que estemos.

Comunicativa

¿Es nuestra arquitectura capaz de darse a entender por si misma? De tal forma que solo nos necesite como meros heraldos de presentación. Que al abrir el proyecto nos brinde una idea general de donde esta cada cosa. Que a la hora de que alguien tenga que escribir un método sepa cual es la clase, o la capa en la cual debe ir. ¿Documentamos lo que hacemos? Los frameworks y componentes que mayor éxito tienen en el mercado son aquellos que mejor documentados están. Nadie quiere perder preciosas horas de investigación averiguando que tenia en la cabeza el programador a la hora de hacer el código. Siempre nos repetimos a nosotros mismos, y muchas veces sin razón alguna, más allá de la falta de documentación, que sería mas fácil hacerlo de nuevo que continuar el trabajo de otros. Las wikis suelen ser herramientas muy útiles a la hora de mantener tan “viva” nuestra documentación como nuestro código.
El conocimiento es una de las bases del poder, y teniendo en cuenta esto, existen personas en las empresas que buscan ser los “únicos” que entiendan la forma de hacer las cosas. Pero después, estas personas se marchan buscando nuevos horizontes laborales, y el conocimiento se pierde, y la semilla del caos ha sido sembrada. Es por ello, que documentar no solo se transforma en una ventaja competitiva, si no también en una necesidad de supervivencia.

Autocrítica

Nada es perfecto, todo es perfectible en el tiempo. Pero al igual que un rió, el código fluye. Los requerimientos cambian, el conocimiento se actualiza. Debemos criticar con periodicidad nuestro código. Lo que la industria llama “Refactorizar”. Esto es como agregarle agua a un pozo tapado con tierra. Siempre nos va a dar lugar para agregar un poco más, y va a hacer a nuestro código mas solido. De lo contrario, la deuda técnica se incrementará dia a día, y solo nuestro esfuerzo servirá para pagar los intereses de esta deuda. Nos debemos preguntar, esta clase se tendría que llamar así? ¿Estos métodos subclaseados, podrían subirse al parent en el árbol de herencia? Estos métodos de la misma clase comparten muchos código, ¿no debería sacarlo a uno private y parametrizarlo? Debemos crear ciclos de desarrollo-refactorizacion-desarrollo etc. Es como el chequeo médico para determinar la salud de nuestra arquitectura.

Eutanasica

Debemos entender que cualquier arquitectura que diseñemos tendrá un ciclo de vida. Se realizará para un momento determinado del tiempo. Con un conocimiento sobre el mercado, una visión empresarial y un nivel de conocimiento técnico determinado. Las grandes arquitecturas viven por años, aquellas que son chequeadas, analizadas, y tratadas periódicamente ante cualquier síntoma. Otras, no soportan la deuda técnica y se cancerizan rápidamente en el lapso de uno o dos años. Nos debemos preguntar, ¿donde estaremos en seis meses a este paso? ¿Podemos liderar el mercado técnico con esta arquitectura?¿podemos alcanzarlo?¿Ha cambiado la visión de la empresa? ¿hemos aprendido suficiente? Si estas preguntas no pueden ser resueltas rápidamente, o si no nos gusta la respuesta, es hora de ir preparando una “muerte digna” de nuestra arquitectura. Ir planificando una migración, dejar un grupo de soporte, mientras una nueva esta en camino. No esperar hasta que el agua nos llegue al cuello.

Son varios los items de la check list, pero es un principio.

Conclusión

Pensar en una arquitectura como algo meramente técnico, es partir desde bases erróneas. Por supuesto que un arquitecto debe ser una persona técnicamente idóneo, ya que debe entender lo que su equipo técnico esta sugiriendo, y saber tomar decisiones técnicas todos los días. Pero pensar que eso es los más importante, o que es lo único que debe tener, es concebir que el mejor albañil que conocemos es capaz de diseñar el empire state. Debemos entender que en este edificio abstracto que vamos a diseñar será habitado por personas, y no mayoritariamente por clientes, si no más bien por los desarrolladores, y toda clase de staff informático con lo que convivimos diariamente. Abramos las puertas, preguntemos como quieren vivir. Revisemos nuestra empresa, nuestro proyecto.