lunes, 3 de marzo de 2014

97 Cosas que un Arquitecto de Software Debe Conocer - Parte 6

Este artículo forma parte de una serie de posts en los que traduzco y resumo los principios del libro 97 Cosas que un Arquitecto de Software Debe Conocer.

Los post anteriores pueden leerse en:
Continuamos con los siguientes 12 principios:
  1. El Negocio V.S. el Arquitecto Enojado: El negocio es nuestra razón de ser. Vivimos para servirlo, no al revés. Escuchar y entender el negocio que nos emplea para resolver los problemas es la habilidad más importante que poseemos. Muestra a los expertos de dominio el respeto que tú mismo esperas recibir. Cuando estás hablando, sólo puedes escuchar algo que ya sabes. Nunca pienses que eres tan inteligente que nadie más tiene algo valioso que decir. No te permitas convertirte en un genio descontento que pasa todo su tiempo tratando de impresionar a los demás, haciendo declaraciones condescendientes acerca de lo mal que está manejada la empresa.


  2. Estire Dimensiones Clave para ver Qué se Rompe: Estíralas de forma individual y luego combinadas para desentrañar los límites invisibles que podrían estar ocultos en el diseño inicial. Puedes sobrecargar el sistema para entender si la infraestructura planificada es escalable, y hasta cuánto. Puedes simular cortes de luz, interrupciones, situaciones inesperadas, incremento abrupto de la cantidad de datos a procesar. Necesitas saber si el sistema puede recuperarse. Sobre la base de estos experimentos, los elementos del diseño original pueden ser reconocidos como problemas que requieren rediseño.

  3. Antes que Nada, un Arquitecto es un Desarrollador: ¿Has visto un juez que no fue abogado, o un jefe de cirugía que no fue cirujano? Para ganarte el respeto y la confianza de tus desarrolladores, tu código es lo importante. Debes demostrarle a los programadores que tú podrías programar la arquitectura que presentas. Como arquitecto, tu principal objetivo es crear una solución viable, mantenible y, por supuesto, que resuelva el problema que debe resolver. Recuerda: lo que diseñes, debes ser capaz de codearlo.

  4. Una Rosa con Cualquier Otro Nombre Terminará como un Repollo: Si no sabes cómo debe ser llamado algo, entonces no sabes qué es. Si no sabes qué es, no puedes sentarte a escribir el código. ClientAPI, ClientBusinessObject, son nombres que se usan para no nombrar nada. Diseñar significa tratar de cumplir con intenciones y los nombres sirven para transmitir dichas intenciones. Si no puedes nombrarlo, no puedes escribirlo.

  5. Problemas Estables obtienen Soluciones de Alta Calidad: La habilidad de un arquitecto se encuentra en dibujar límites alrededor de problemas difusos y diversos, para que pasen a ser problemas estables y auto-contenidos. Un arquitecto debe poder aislar los problemas en porciones estables que tengan alta cohesión interna y estén desacopladas entre sí. Porque si el problema es estable y puede ser resuelto, entonces estará resuelto para siempre. Un problema estable permite crear un sistema con un diseño estable, y un diseño estable permitirá que te concentres en una solución de alta calidad.


  6. Se Requiere Diligencia: Diligencia en el sentido de atención, celo, cuidado. Un arquitecto es diligente con cada tarea y cada objetivo del sistema. La diligencia va de la mano de lo mundano. Los arquitectos eficaces suelen seguir checklist mundanas para recordar lo que ellos ya saben que funciona teóricamente y que suele fallar en la práctica por culpa del hábito. Sin esas checklist, el arquitecto puede caer en el tiempo del software, donde la arquitectura se escapa de los límites de lo visible, no hay progresos medibles y abundan las trampas que hacen girar en círculos a los programadores. La diligencia también requiere aceptar compromisos y disposición.

  7. Hazte Responsable de tus Decisiones: 1) No afirmes que una decisión de arquitectura fue tomada hasta que su justificación no haya sido puesta por escrito y no haya sido comunicada a las personas afectadas directa o indirectamente. 2) Revisa tus decisiones periódicamente, examina los resultados obtenidos, identifica cuáles siguen siendo válidas y cuáles no. 3) Acompaña al equipo durante el desarrollo, asegúrate que las decisiones arquitectónicas se cumplan. 4) Delega algunas tomas de decisiones en otros expertos. Los arquitectos tienen áreas en las que son muy competentes, áreas en las que están bien informados, y áreas en las que son simplemente incompetentes.

  8. No seas un Solucionador de Problemas: Los arquitectos y los desarrolladores aprenden a entrar en el modo de resolución de problemas inmediatamente, pero a veces la mejor solución no es una solución. Muchos problemas de software no tienen que ser resueltos en absoluto. Parecen problemas porque miramos sólo los síntomas. Nos olvidamos de analizar, de interrogar, a los problemas. Debemos aprender a subir y bajar por las capas de un problema, a alto y bajo nivel, para garantizar que las preguntas sean formuladas correctamente y no aceptar simplemente las que nos dan ya formuladas. No debemos ser receptores pasivos de requerimientos.


  9. Elige tus Armas con Cuidado, Renuncia a ellas de Mala Gana: Es un error renunciar a la lista de tecnologías y soluciones preferidas, que ya han demostrado funcionar, sólo por abrazar a las nuevas tendencias. A toda tecnología le llega el momento de ser reemplazada. La tecnología avanza y soluciones más efectivas están en camino. Como arquitectos tenemos que estar al tanto de las tendencias de la industria, pero no tenemos por qué ser los primeros en adoptar las tecnologías incipientes. Antes de abrazar una nueva tecnología, pregúntate cómo el negocio se beneficiará con esa decisión. Es ingenuo pensar que una nueva tecnología no vendrá con sus propias trampas y la adición de problemas que no se han resuelto antes destruirán tus estimaciones. Tratar de predecir de forma temprana las nuevas tecnologías que se impondrán es una apuesta que no deja buena recompensa. Espere a que la tecnología se vuelva mainstream y evite poner en riesgo al proyecto eligiendo algo que no tendrá futuro.

  10. Tu Cliente no es tu Cliente: Los clientes de tu cliente son tus clientes. Si estás escribiendo una aplicación de comercio electrónico, ten cuidado de las cosas que sabes que la gente que va de compras va a necesitar. Tu cliente puede no mencionar estos requerimientos. Es tu trabajo comunicárselos y explicar por qué crees que serán importantes. Si los clientes de tu cliente ganan, tu cliente ganará y tú ganarás también.

  11. Nunca se Verá Así: No importa cuánto hayas pensado, investigado y profundizado tu diseño, nunca se verá igual que en tu cabeza. Siempre un factor externo lo arruinará: información incorrecta, descuidos, suposiciones incorrectas, cambios de requerimientos, de tecnología... Estas alteraciones mínimas pronto se irán acumulando. En poco tiempo tu concepto original se hará pedazos y tendrás que sentarte a diagramar, estrenarás nuevo rediseño, una visión 2.0 más clara, radical y perfecta de la arquitectura, que los factores externos no tardarán en derribar y en poco tiempo volverás a encontrarte gritando: "¡Por supuesto que tiene bugs, nunca fue diseñado para eso!" Este escenario, tan común en proyectos de software, nos deja como moraleja que el diseño es un proceso de descubrimiento. A medida que implementamos vamos descubriendo nueva información. Al aceptar que el diseño es un proceso continuo y empírico en un mundo siempre cambiante, aprendemos que el proceso de diseño debe ser flexible y continuo también.


  12. Elige Frameworks que Jueguen Bien Entre Sí: Elije frameworks que no se solapen. Cada framework o librería de tercero debería cubrir aspectos o lógica de dominio distinta. Dibuja un diagrama de Venn para entender cuánto se solapan. Las intersecciones agregarán complejidad accidental al sistema. Elije frameworks que sean específicos, cuyas funcionalidades tengan una alta proporción de utilidad para satisfacer los requerimientos. Si un framework viene con un montón de funcionalidades, entonces debería proveer una alta cobertura de funcionalidades valiosas en el proyecto.