sábado, 13 de julio de 2013

97 Cosas que Todo Arquitecto de Software Debe Conocer

Hay un libro llamado así: 97 Cosas que Todo Arquitecto de Software Debe Conocer. No lo he leído, pero su Wiki me parece más que interesante.


En este primer post dedicado al tema, comparto los primeros 15 principios expuestos en la Wiki:
  1. Nunca pongas tu CV antes que las Necesidades del Sistema: El mejor activo de tu carrera es una larga lista de clientes satisfechos dispuestos a recomendarte porque hiciste lo correcto para ellos y para el proyecto. Este "fondo de comercio" te servirá muchísimo más que el último chiche brillante en el último lenguaje brillante o el último paradigma brillante.

  2. Simplifica la Complejidad Esencial y disminuye la Complejidad Accidental: La Complejidad Esencial representa la dificultad inherente a cualquier problema (ejemplo: la complejidad de un dominio). La Complejidad Accidental surge de las piezas tecnológicas que construimos para mitigar la Complejidad Esencial (ejemplo: la complejidad de un framework).

  3. Es probable que tu mayor Problema no sea Técnico: La mayoría de los proyectos son construidos por personas; y esas personas son la base del éxito y el fracaso.

  4. La Comunicación es la Reina; la Claridad y el Liderazgo, sus humildes servidores: Olvida los documentos Word de 100 páginas; nadie va a leerlos. Usa herramientas de modelado, diagramas simples que puedan cambiar frecuentemente, reúne al equipo en una pieza y comunica tus ideas en pizarrones, sácales fotos a los pizarrones y compártelas. El arquitecto debe ser también un líder. Ten a los desarrolladores de tu lado, trabaja con ellos, déjalos expresar sus ideas, genera un ambiente cómodo de trabajo. Haz lo mismo con los demás miembros del equipo: testers, analistas de negocio, líderes de proyectos, etc.

  5. Arquitecturar es Balancear: La Arquitectura de Software abarca mucho más que las clásicas actividades técnicas que hacen a la profesión; también involucra los requerimientos de negocio  de todos los stakeholders del proyecto. Es trabajo del Arquitecto poder balancear los aspectos más técnicos con las prioridades de otras áreas orientadas al negocio y a la rentabilidad del software a construir y mantener.

  6. Busca el Valor en las Capacidades Requeridas: A menudo, los clientes y los usuarios finales señalan lo que piensan que es una solución viable a un requerimiento, mezclando lo que es el dominio del problema con el dominio de la solución. Para evitar esto, es aconsejable organizar una serie de workshops y reuniones donde los arquitectos se enfoquen en las necesidades del cliente, ayudándolos a descubrir el "por qué" del requerimiento. Estas discusiones deberían evitar los aspectos técnicos, para que los clientes y usuarios puedan enfocarse en el dominio del negocio que conocen y no en el dominio del desarrollo de software.

  7. Administrando Requerimientos de Software

  8. ¡Ponte de Pie!: Si estás comunicando tu visión hacia otras personas, ¡ponte de pie! Así sea una revisión formal o una discusión informal, ¡ponte de pie! Sobre todo si los demás están sentados. Ponerse de pie automáticamente transmite autoridad y confianza en uno mismo. El contacto visual y el lenguaje corporal son elementos muy importantes de la comunicación. Cuando uno se pone de pie, tiende a controlar mejor la voz, hablando claro y fuerte, y reduciendo la velocidad a la hora de remarcar conceptos importantes.

  9. Los Rascacielos no son Escalables: A menudo comparamos a la Ingeniería de Software con la  Ingeniería Civil. Sin embargo, nadie en su sano juicio empieza a construir una obra de Ingeniería Civil sin saber cómo será cuando esté terminado. Agregar pisos adicionales a un edificio existente es costoso y de un riesgo incalculable, por lo que nos esforzamos por evitarlo. Una vez diseñado, no se supone que un rascacielos pueda cambiar de ubicación. Por eso es que, en contraposición con el proceso de cascada, hoy en día contamos con procesos ágiles de desarrollo, en los que podemos ir desplegando continuamente, a la vez que vamos refactorizando, corrigiendo e incluso reescribiendo funcionalidades que a priori no estaban definidas, iterando de forma flexible con el fin de poder satisfacer las necesidades del negocio a medida que el software se va construyendo.

  10. Estás negociando con más frecuencia de lo que Piensas: Lo último que quiere un negociador es hacer concesiones en la primera demanda. Cuando el líder de proyecto nos pregunte si realmente es necesario ese nuevo servidor, tenemos que hacerle entender las terribles desventajas de no tenerlo y negociar, siempre negociar, para que la peor opción técnica siempre sea el último recurso.

  11. Cuantifica: "Rápido" no es un requerimiento, tampoco "flexible", tampoco "extensible", ya que definidos de esta forma no hay manera de medirlos. Una de las grandes responsabilidades del rol del Arquitecto es conseguir que el sistema alcance estos Atributos de Calidad y balancear el constante conflicto e inconsistencia entre ellos. Sin criterios objetivos, el Arquitecto está a merced de los caprichos del usuario o de las obsesiones de los programadores. ¿Cuántos? ¿En qué plazo? ¿Con qué frecuencia? ¿Qué tan pronto? ¿Aumentar o disminuir? ¿En qué proporción? La próxima vez que alguien te diga que el sistema necesita ser "escalable", pregúntale cuándo cree que va a aumentar el número de usuarios, en qué cantidad, por qué.


  12. Una Línea de Código Productivo es más Valiosa que 500 de Especificación: Las Especificaciones por sí solas no tienen valor. El objetivo final de un proyecto de software es funcionar en producción. El diseño no es más que un medio para un fin, no un fin en sí mismo. La arquitectura siempre debe ajustarse a las restricciones del mundo real.

  13. No hay una Única Solución para Todos los Problemas: Un gran problema en la industria del software es que las personas son a menudo responsables de la solución de problemas que requieren más Sentido Contextual (a.k.a. Sentido Común) del que han acumulado. El conocimiento más importante de Patrones de Software es el de comprender cuándo aplicarlos y cuándo no. Los Arquitectos deben desarrollar y ejercer el Sentido Contextual en la formulación y solución de problemas.

  14. Nunca es Demasiado Pronto para Pensar en Performance: La gestión de los Atributos de Calidad es una de las competencias principales del Arquitecto de Software. Sin embargo, es muy común que se cometa el error de testearlos demasiado tarde dentro del ciclo de desarrollo, y muchas veces esta tarea se delega al equipo de Operaciones. Si el rendimiento es un requerimiento importante, entonces las pruebas de performance deberían planearse y ejecutarse lo antes posible. Tener en cuenta la performance en fases tempranas nos da la ventaja de ir atacando los issues arquitecturales de forma incremental, armar el ambiente cuando todavía es relativamente sencillo, y tener métricas de calidad actualizadas a lo largo de todo el ciclo de desarrollo.

  15. La Arquitectura de la Aplicación determina el Rendimiento de la Aplicación: Muchos Arquitectos de Software creen que cambiando de vendor de infraestructura, o tuneando la existente, será suficiente para resolver los problemas de performance de una aplicación, y utilizan benchmarks para avalar su decisión. Pero si sobre esa infraestructura se despliegan aplicaciones ineficientes, no preparadas para la carga esperada, entonces ningún vendor o tuning alcanzará el rendimiento deseado y la escalabilidad seguirá siendo inalcanzable.

  16. Commitear y Salir Corriendo es un Crimen: Escenario: desarrollador se tiene que ir temprano, commitea, se va y deja el sistema de build roto. Esto es grave porque los desarrolladores que quedan no pueden sincronizarse con el repositorio; saben que, si lo hacen, sus copias locales también se romperán. Aquí es donde el Arquitecto, quien ha puesto mucho esfuerzo en la creación de una arquitectura flexible, en enseñar a los programadores prácticas ágiles como el desarrollo basado en pruebas, y en configurar un servidor de Integración Continua, debe fomentar una cultura en la que no está bien malgastar el tiempo de los demás, ni cortar el flujo de trabajo. Para esto, el Arquitecto debe brindar un build system rápido y cómodo, con mocks que simulen conexiones con sistemas externos, servidores livianos para las pruebas de integración, bases de datos en memoria, dependencias mínimas, módulos desacoplados, y lo que haga falta.