Arquitectura de Software en Forma de Cuentito

 http://images.video.msn.com/flash/soapbox1_1.swf
Video: Software Architecture for Academy Students 

 Leandro Doeyo,  ex director académico de plataforma .NET para América Latina y actual director a nivel global, me visitó los otros días con una consigna: me pidió que cuente el rol de un arquitecto y cómo se llega al mismo pero en una forma que sea entendible por estudiantes universitarios de entre primer y tercer año de carreras afines

Como es ya no para América Latina sino para todo el mundo, hubo que hacerlo en el "latin" de nuestros tiempos smile_embaressed (que de "nuestros" no tienen mucho). Es muy extenso así que traduzco los conceptos más salientes. Parece que venía inspirado ese día, no sé qué me pasó

La entrevista original está en Channel 8. Auspició Yerba Mate Taragüí

 

  • Arquitectura de Software es, quizás, un 20% de las líneas de código de tu aplicación. Pero un 20% que va a estar involucrado en el 80% de la ejecución posterior. Esto es un riesgo y a la vez una oportunidad. Riesgo porque si metés la gamba en ese tan sólo 20%, lo vas a sentir en el 80% del uso posterior que le des. La buena noticia, aún, es que corregir el error implica revisar qué pueda estar saliendo mal en ese no más de un 20% del código, y si lo lograste descular, el arreglo debería alcanzar nuevamente al 80% del uso que de esa aplicación se hace
  • Cómo empecé yo… Me acuerdo que cuando era chico, durante la irrupción de las computadoras domésticas (Atari, Commodore, etc), yo tenía una de las más limitadas (1) y por lo tanto el conjunto de juegos disponible para la mía era bastante inferior al de mis amigos. Probablemente eso me hizo ser más inquieto acerca de cómo los juegos eran construidos (2), de manera de intentar reponer el faltante por las mías. Y fue un desastre: por ejemplo, me acuerdo de haber intentado programar un Pacman sin tener ni idea de lo que una buena arquitectura de aplicación mandaba. Así, te imaginarás, mandaba todas las líneas de instrucción del programa en la medida en que se me iban ocurriendo, una atrás de la otra, todo pegado, todo seguido… Y se dió la lógica: el juego transcurría súper lento, los fantasmas terminaban traspasando las paredes…
    (Leando interrumpe) Bueno, estaba bien, no? Para algo eran fantasmas…
    (Risas) Esa podría ser una posible explicación de mi fracaso… digo, a modo de excusa, no? Pero lo cierto es que sí: mis controles vía teclado también eran atendidos tarde, así que yo también me llevaba puestas las paredes del laberinto, recién después la compu se apiolaba entonces me blockeaba pero para eso yo ya estaba en cualquier lado… Fallo general y con eso mi primera frustración, pero a la vez la más remota ocasión en la que sentí que quizás debería intentar seguir una carrera y convertirme en un programador profesional. Y aunque yo ni lo sabía exactamente, lo que intimamente quería era aprender a ser un arquitecto de software
  • Acerca de un escenario real donde se entienda mejor qué papel cumple la arquitectura en un software, tal vez lo pueda ejemplificar con este juego (3)… Si te fijás, la lógica de este juego tiene que preocuparse por el renderizado en tiempo real y para eso hay que hacer montones de operaciones de punto flotante en simultáneo, lo que seguramente te va a requerir cierta infraestructura base: una CPU de alta velocidad, un tocazo de memoria, no creo que zafes de una tarjeta gráfica con sus propias capacidades (4), también te tenés que encargar de reconocer los comandos vía teclado o quizás habilitando un joystick, controlar el movimiento de tus enemigos, las paredes y todo el resto de la escena, de manera de saber si te llevaste por delante algún objeto en tu camino, el sonido… Te podría seguir mencionando pero ya te hacés una idea del vagón de cosas de las que te tenés que ocupar. El rol del arquitecto, entonces, es bosquejar los planos de esta aplicación, de manera de lograr tener una clara idea respecto de dónde quedó cada cosa
  • (Leandro) O sea que como arquitecto no es que tengas, nada más, que planear los componentes de la aplicación sino además ubicarlos correctamente para que la complejidad global sea más administrable, extensible
    (Diego) Nunca más adecuadamente definido. Se trata de eso: de administrar la complejidad y convertirla en algo más simple de entender, sobre todo por quienes luego van a tener que lidiar con la programación durante su existencia
  • Yo no fui arquitecto desde el primer día sino que, mientras estudiaba una carrera de computación científica, conseguí un trabajo como desarrollador junior. Ahí me tocó programar todo el día. Más que nada aplicaciones comerciales. Desde ese momento, llamemosle como "arquitecto junior", ya tuve que ir empezando a plantearme mejores maneras de programar las aplicaciones, ya sea para que corran más rápido, también para que estén más preparadas para cambiar en algún futuro
  • En mi caso personal, ya llevo más de 15 años así, y hacete una idea cuando arranqué (más de 15 años atrás), lo que el estado del arte de ese entonces tenía disponible. He laburado con tecnologías que hoy ya ni existen, pero lo importante es que en la medida en que iba ganando chapa, iba metiendo la gamba, y obviamente, aprendía de esos errores. En realidad así era como crecía, de manera tal que la próxima vez -las veces que me dieron la chance de probar de nuevo- intentara hacerlo de una mejor manera
  • Después de algunos años, con lo ya adquirido, podíamos decir que era un desarrollador senior. Y desde ese momento ya me daban cabida para poder tomar algunas decisiones de arquitectura (5). También, para definir algunas normas respecto de cómo el código debía ser escrito, más que nada para que el resto de los desarrolladores, sobre todo los más junior, no caigan en los mismos errores que yo había caído cuando pasé por esa
  • El siguiente paso ya fue pasar a estrenar el rol de arquitecto. Y de nuevo, otra vez a cometer errores como forma de aprender. En realidad la frontera entre un desarrollador experimentado y un recientemente designado arquitecto es todavía borrosa. Pero podríamos decir que el arquitecto empieza a estar enfocado más en modelos, planes y el proyecto en general en tanto que el desarrollador sigue ocupándose más de la lógica y el día a día. Pero el desarrollador puede asistir al arquitecto dando su opinión sobre los planos, incluso le puede sugerir cosas al arquitecto basandose en lo que él conoce mejor respecto de lo que realmente las tecnologías pueden lograr cuando uno trata de usarlas. De manera que así fue conmigo: en un dado momento ya se me pidió que largue un poco el teclado y me concentre más en decidir cómo modelar ese 20% que iba a impactar después en el 80% de la ejecución
  • El arquitecto tiene que abocarse a aquellas cosas que la aplicación debe aportar como una característica general. Ejemplos de esto son rendimiento (performance) y escalabilidad, que si bien están relacionadas son algo diferentes. "Rendimiento" tiene más que ver con tus ganas de que la aplicación te responda al toque (acordate del juego que te estaba mostrando). En cambio "escalabilidad" tiene más que ver con la capacidad de tu aplicación para recibir una carga incremental de usuarios, administrando y sirviendo a todo el mundo al mismo tiempo
  • Para esto te va a tener que tocar interactuar con otro estilo de arquitecto: el arquitecto de Infraestructura. Este rol se encarga más de planificar el parque de hardware, la red, el software básico como el sistema operativo, la base de datos, y también herramientas de monitoreo que ayuden a controlar que todo eso funcione sin dramas. A este arquitecto no le concierne cómo las aplicaciones fueron desarrolladas o lo que las mismas hacen -en términos de negocio- sino que las ve más como procesos que deben estar ejecutándose en forma "saludable"
  • Esto implica mencionar un concepto importante que es el concepto de Sistemas de Misión Crítica. En términos de negocio, un sistema de estas características es un sistema que tiene que estar disponible cuando el negocio lo requiera. Si por hache o por bé no está disponible (llamalo rendimiento, capacidad, el servidor está abajo, etc), la capacidad operativa del negocio se va a ver seriamente perjudicada: por ejemplo, los empleados van a tener a empezar a trabajar a mano, lapiz y papel, sin acceso a la data. Cuando el sistema vuelva van a tener que reprocesar todo lo que les quedó colgado, y eso obviamente representa una pérdida de productividad
  • Al que quiera recomendación de lo que un arquitecto debe hacer, hay miles de cosas que sugerir pero si yo tengo que resumir en tres, me vienen a la cabeza las siguientes
  • Un arquitecto de soluciones programa todos los días (6), está en la cresta de la ola analizando las diferentes tendencias, probándolas. Programar a diario es una buena manera de estar "en forma"
  • Segundo, probá siempre varias alternativas. Cuestionate las que viniste usando ultimamente, preguntate si no podrá haber una mejor manera. Acá entramos en un terreno donde el pensamiento lateral puede aportar lo suyo, ya que plantea analizar todas y cada una de las variantes disponibles. Incluyendo esas que a primera vista parece que no van para ningún lado. En definitiva, tenés que entender las alternativas que funcionan, por qué funcionan; y las que no, por qué no y consecuentemente por qué deberíamos evitarlas
  • Y quizás la más importante: el software que dura es aquel que está preparado para cambiar. Parece un contra sentido, no? Sin embargo lo que quiere decir en los hechos es que si el usuario te reclama porque la aplicación está corriendo lento y vos descubrís que hay mucho acceso a datos y por ende vas a poner un caché, eso no te debería partir toda la aplicación por la mitad. Acordate siempre del 20%: ese 20% debería estar listo para cambiar cuando haga falta
  • Respecto de recursos relacionados con arquitectura, para poder ir manggiando el tema, fijate que el problema no es que no haya sino el opuesto: por donde empezar de todo lo que hay para ver?
    • La revista MSDN Magazine es sobre desarrollo de software, pero es a la vez la mejor manera de convertirse en un desarrollador senior (7). La revista sale en papel mes a mes, pero está disponible en forma gratuita en su web
    • Para los arquitectos de Infraestructura, la versión análoga es Technet Magazine, donde encontrás recomendaciones para afinar la marcha de Windows Server 2008, SQL Server 2008, etc. La versión web de esta revista, de nuevo: disponible gratis
    • Skyscrapr es el lugar para los aspirantes a arquitectos. En realidad su lema es "donde los arquitectos se convierten en tales"
    • Hasta acá te mostré aquellos sitios pensados para quienes aún no son arquitectos pero que quisieran serlo. Patterns and Practices ya es el sitio de las mejores prácticas de arquitectura, sea para calibrar aplicaciones, rendimiento, escalabilidad, El equipo detrás de este sitio también libera ejemplos de código que te podés descargar y ejecutar en tu propio entorno. Escriben, además, algunos libros que junto al resto son la mejor manera, para un arquitecto junior (8) para pasar al siguiente nivel
    • El sitio oficial de Arquitectura MSDN apunta ya a gente que viene practicando el rol. Contiene cosas de hoy y mañana, sobre conceptos y tendencias como Web 2.0, SOA, etc
    • Y si ya querés hablar del rango más alto de arquitectos, aquellos que están parados ya en la vereda del negocio, mirando a la tecnología que está al otro lado de la calle, viendola como habilitadoras del mismo, tenemos una revista, el Journal de Arquitectura,  a la que te podés suscribir gratis y te mandas la copia en papel sin oblar un níquel. En su portal, todos los números están disponibles en PDF
  • Mi primer sorpresa cuando de la facu salté a la industria fue que, lejos de encontrar que usaban los lenguajes que yo me sabía como C y Pascal, o incluso superiores como yo presentía, en cambio usaban COBOL y otras antigüedades que hasta ese momento yo daba por seguro que estaban muertas. Bueno, estaban vivas y coleando y me tuve que poner a estudiarlas yo si no quería terminar así. Sin embargo la facu cumplió, desde la teoría, con enseñarme aquella visión de la película que después tuve que contrastar con lo que las realidades en la industria me imponían
  • De esta manera quiero motivar a cualquier estudiante en la facu que termine la carrera, que venga a la industria y descubra él también esa delgada frontera entre la teoría y la práctica. Y de paso que nos muestre nuevas formas de pensar que nos permitan perfeccionarnos, a la vez que esté abierto para conocer lo que la experiencia ya enseñó

_______________________________
(1) La Texas, la TI-99/4A
(2) Además de volverme resentido, envidioso, ventajero, rencoroso, mulero, bebedor, vividor y pituco
(3) Quake II.NET, disponible con código fuente en http://www.vertigo.com/Quake2.htm
(4) De manera de liberar a la CPU de todo el despliegue gráfico
(5) Un desarrollador senior, no obstante, la mira desde lo que está programando hacia la aplicación en general. Un arquitecto la ve al revés: desde la aplicación como un todo hacia cada componente
(6) O, equivalentemente, analiza código escrito por otros
(7) En la entrevista dije erroneamente "arquitecto senior"
(8) Vuelvo a decir "arquitecto senior" queriendo decir otra cosa

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

5 respuestas a Arquitectura de Software en Forma de Cuentito

  1. Matias dijo:

    Grande dieguin! Claro como el agua, como siempre.
    Te mando un saludo grande aca desde Beijing!!

  2. Johnny dijo:

    Un mostro! Me encato la lata de Taragui insignia de tu office del AST. Pedazo de video! Dos monstruos uno entrevistando al otro🙂.
     
    Ahh ¿Esta Luis?
     
    Abrazo,
    ~johnny

  3. Diego dijo:

    Grande champions de Southworks!!
     
    Un capo Matías que se nos fue a la China a demostrar (humille, maestro humille, boiingg!!) y el amigo Johnny que "cuchame Luí no tá!! Por qué, tene hija vo!?"

  4. Patricia dijo:

    Que grande Diegum! Un excelente profesional y mejor persona!! Muy buena la entrevista. Dan ganas de ir a tomar unos mates.
    Besos para vos y Pau.
    Pato
     
    PD: ay Dios, nadie te maquilló para salir sin ojeras? qué poco detallistas, jajaja

  5. Diego dijo:

    te das cuenta, pato? soy la meijide de la computacion!!   ;-D

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s