miércoles, 5 de febrero de 2014

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

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. Comparte tu Conocimiento y Experiencias: Nuestra base de conocimiento fundamental es pequeña comparada con lo que necesitamos para llevar a cabo un proyecto de desarrollo de software exitoso. Todos estamos tratando de crecer para llegar a entender cómo construir sistemas más y más grandes. Para que la industria del software progrese, necesitamos compartir las lecciones aprendidas de los proyectos. No entiendes algo en profundidad hasta que no lo puedes explicar fácilmente. Trata de compartir tus ideas, tus soluciones, tus problemas; si tus ideas y creencias no soportan un debate, es mejor que te enteres lo antes posible y las corrijas.

  2. Asegúrate de que las Cosas Simples sean Simples: Lo menos que queremos es aplicar soluciones complicadas a problemas simples. Si de pronto te encuentras diseñando una solución tan ingeniosa que toma conciencia de sí misma, detente y ponte a pensar: ¿esta solución se ajusta al problema? Si la respuesta es no, reconsidera tus opciones de diseño. Mantén simple lo simple. La sobre-ingeniería a nivel de arquitectura causa los mismos problemas que a nivel de desarrollo, pero sus efectos negativos tienden a multiplicarse. Recuerda esto cuando trates de adivinar requerimientos futuros: el 50% de las veces estarás equivocado y el 49% estarás muy muy equivocado. Soluciona los problemas de hoy con la elegancia justa y necesaria.


  3. Si Tú lo Diseñaste, Debes Ser Capaz de Codearlo: Cuando diseñas la arquitectura de tu proyecto, es necesario que tengas una idea del esfuerzo necesario para implementar cada elemento de dicho diseño. No uses patrones que nunca hayas implementado. No te bases en frameworks en los que nunca hayas programado. No uses servidores que nunca hayas configurado. De lo contrario no podrás brindar buenas estimaciones, no conocerás las debilidades y trampas de tus componentes, perderás la confianza de tus desarrolladores e introducirás riesgo innecesario. Antes que nada, un arquitecto es un desarrollador.

  4. La Variable ROI (Retorno de Inversión): Cada decisión que tomamos en un proyecto puede ser considerada como una inversión. Si para nuestro proyecto el time to market es esencial para los stakeholders, quizá la arquitectura bala de plata que requiere al principio una larga fase de diseño no ofrecerá un ROI tan interesante como una versión alfa rápida. El ROI de cada elección se puede determinar mediante el análisis de sus costes y beneficios y se puede utilizar como una base para tomar decisiones. Éste es un enfoque útil para determinar qué tan pragmática o apta es cada opción.

  5. Tu Sistema es Legacy, Diséñalo para el Mantenimiento: Ten siempre en mente la claridad, la testeabilidad, la correctitud, la trazabilidad. Piensa que un equipo diferente debe abrir el código y averiguar lo que sucede ahí dentro cuando algo no funcione como se esperaba. Un buen diseño se documenta a sí mismo. Todo el software, por más moderno que sea, será legacy en poco tiempo.

  6. Si sólo hay una Opción, Consigue una Segunda Opción: Si sólo puedes pensar en una solución a un problema, estás en problemas. La arquitectura de software trata sobre encontrar la mejor solución posible dada una cantidad de restricciones. La falta de opciones en un arquitecto se puede deber a inexperiencia, en cuyo caso es aconsejable dejar el ego aparte y buscar ayuda, o a la formación mediante el hábito, por ejemplo: un arquitecto que ha aprendido con un único estilo de arquitectura y se ha convertido en su bala de plata para todo.


  7. Entiende el Impacto del Cambio: El cambio puede manifestarse de muchas formas: cambios en los requerimientos funcionales, necesidades de escalabilidad que evolucionan, interfaces que son modificadas, gente en el equipo que va y viene, etc. El papel del arquitecto no es gestionar el cambio, sino garantizar que el cambio sea manejable. Afortunadamente hay muchas herramientas y técnicas para mitigar el impacto: construir en pequeños pasos incrementales, construir casos de prueba repetibles, facilitar la ejecución de las pruebas, trackear dependencias, automatizar tareas repetitivas, etc.

  8. También Debes Entender el Hardware: Para muchos arquitectos de software, el planeamiento de capacidad de hardware es un tema que está más allá de su zona de confort. A medida que una arquitectura evoluciona, los requerimientos de hardware cambian. La mejor opción es trabajar cerca de un arquitecto de infraestructura, invitándolo a formar parte del equipo. Cuando no existe esa opción, podemos basarnos en nuestra experiencia pasada. Hoy en día está la posibilidad de ir escalando horizontalmente a demanda, es una opción, pero para ello debes diseñar tu arquitectura para que sea elástica. Así como el arquitecto de software debe servir de puente entre las demandas del negocio y las soluciones de software, también debe serlo entre el hardware y el software.

  9. Los Atajos de Hoy se Pagan con Intereses Mañana: Es importante recordar que el mantenimiento de un sistema consumirá muchísimos más recursos que su desarrollo inicial. Las malas decisiones tomadas en el inicio de un proyecto se pagarán caro a la hora de rediseñar el sistema para cumplir nuevos requerimientos. Cuando te encuentres con un problema arquitectónico o un defecto de diseño debes insistir en que se corrija ahora cuando es más barato solucionarlo. Cuanto más tiempo se deje arrastrar dicho defecto, mayor será el valor de los intereses.

  10. "Perfecto" es el Enemigo de "Suficientemente Bueno": "Suficientemente bueno" significa que quedan imperfecciones que no impactan en la funcionalidad, mantenibilidad o performance de un modo significativo. La implementación funciona y satisface los atributos de calidad. El código es limpio, conciso y bien documentado. ¿Puede ser mejor? ¡Seguro! Pero no debes caer en la tentación de hacerlo perfecto. Declara la victoria y sigue con otra tarea. ¡El desarrollo de aplicaciones no es un concurso de belleza!


  11. Evita las "Buenas Ideas": Lo peligroso de las buenas ideas es que son precisamente buenas ideas. Cambiar el framework MVC en la mitad del proyecto: ¡sí, vamos a poder usar Ajax! Subir la versión de JPA faltando dos meses para terminar: ¿por qué no?, las Criteria Query son tan cool. Como arquitecto tienes la última palabra, y cedes, porque es tan buena idea, y luego los impactos van destruyendo el sistema, las entregas se van atrasando, el equipo se queda trabajando hasta tarde, fines de semana... Pero todo el sufrimiento vale la pena, ¿no? Era tan buena idea...

  12. Grandes Contenidos Crean Grandes Sistemas: Tener grandes contenidos marca la diferencia entre un sistema hueco y uno relevante. Comparemos Facebook y Orkut, Google y Cuil, Netflix y BlockbusterOnline. Parte del proceso de diseño debería dedicarse a evaluar el inventario del contenido. ¿Hay suficiente contenido disponible? ¿Es fresco el contenido? ¿Fueron contemplados todos los canales (RSS feed, email, etc)? Evalúa el valor de los contenidos y, si los resultados son poco satisfactorios, levanta una bandera roja para advertir a las partes interesadas.