Arquitectura – Los pecados capitales del arquitecto Parte 2

Pecados capitales del arquitecto
Pecados capitales del arquitecto

Artículos relacionados

PECADOS CAPITALES DEL ARQUITECTO

Continuamos con los últimos 13 pecados capitales:

13. Diseñar una solución compleja

Un mal que se puede presentar en todo diseño es querer tener todo bien definido desde el inicio. Creo que el diseño debe ir evolucionando con el desarrollo. A veces se puede abusar de esto y crear soluciones complejas que no resuelven ningún problema sino que más bien traen otros que pueden afectar el tiempo de desarrollo y el mantenimiento. La refactorización prematura es la raíz de todo mal.

14. No definir estrategias para resolver problemas

Es importante definir qué estrategias se deben seguir para resolver ciertos problemas, aunque parezcan cosas triviales, como: manejo de errores, logs, llamadas a web services, lectura y escritura de archivos, manejo de archivos FTP, cifrar cadenas, etc. Es importante definir estos puntos para que todo el equipo sepa cómo responder ante esos casos y evitar que se generen distintas soluciones para el mismo problema en todo el sistema. Algo que se debe evitar es usar es la frase “pero ya se sabe que se debe hacer de esta forma” recuerden que no todos pensamos igual, así que definir ciertas estrategias para resolver problemas le caería bien a todo el equipo.

15. No saber programar o no conocer principios de diseño

Creo que esta es una de las más graves y es que el arquitecto no sepa programar o no conozca mucho de código (principios de diseño, patrones, etc), en otras palabras que solo sea un arquitecto de papel o de ppt. Con esto no quiero decir que el arquitecto deba programar toda la solución, NO, sino que debe tener el nivel necesario para guiar a todo el equipo de desarrollo, saber cómo resolver problemas y definir estrategias. Creo que a nadie le gusta que alguien le diga cómo hacer algo si no demuestra que en verdad sabe de lo que está hablando.

16. No desarrollar habilidades interpersonales

Las habilidades blandas son aquellos atributos o características de una persona que se relacionan con la capacidad que tiene para interactuar efectivamente con otras personas (colegas, clientes, proveedores, etc) y se aplican tanto dentro como fuera del lugar de trabajo. Por lo tanto, se imaginan trabajar con una persona prepotente, poco humilde, que no escuche otros comentarios, etc…  Creo que no saldrá nada bueno de esta combinación. A continuación listo las habilidades blandas más importantes:

  • Autonomía
  • Liderazgo
  • Capacidad de atención y de escucha
  • Autenticidad
  • Responsabilidad personal y social
  • Capacidad de reflexión
  • Proactividad
  • Pasión
  • Motivación
  • Humildad
  • Aprendizaje continuo
  • Empatía
  • Confianza
  • Gestión de tiempo
  • Capacidad de síntesis y de argumentación
17. No definir una solución base

Empezar el desarrollo y que el equipo no cuente con una solución con la estructura base del sistema en donde se vean reflejadas las decisiones de diseño si es algo preocupante. Para empezar el desarrollo se debe contar con una estructura  que sirva de guía al equipo para que conozcan las estrategias que se van a usar. Reflexión, si se deja que esto lo haga el mismo equipo de desarrollo se puede perder mucho tiempo y no se obtendrá un resultado óptimo, esto ocurre porque aún no tienen la experiencia necesaria o aun no conocen todos los problemas que se deben solucionar a nivel de diseño.

18. No contar con una estructura base para las responsabilidades transversales

Al igual que no es bueno empezar sin una solución base, creo que también no es bueno empezar sin tener librerías que se encarguen de manejar los temas transversales como: logging, encriptacion, validación, manejo de errores, cache, seguridad, etc. Al contar con estas librerías y dejar configurada la solución base el equipo ya no tiene que preocuparse de estos temas; además, evitamos que cada uno implemente una solución distinta para resolver los mismos problemas.

19. No usar indicadores de calidad

Dentro de nuestro control de calidad debemos manejar indicadores para conocer la salud del código.

Indicadores de calidad
Indicadores de calidad

Sino contamos con estos indicadores será complicado saber en qué estado se encuentra nuestro código, lo que trae como consecuencia el aumento de la deuda técnica. Recuerden que velar por la calidad del código es uno de nuestros principales objetivos.

20. No estar con en el equipo de desarrollo (Pecado ajeno)

Aunque lo considero un pecado ajeno, ya que en ciertas etapas del proyecto los gestores o jefes de proyectos deciden mover al arquitecto para que vea otros temas. No siempre esto resulta en una jugada crítica, pero en situaciones donde el equipo no tiene mucha experiencia, no conoce muy bien la tecnología usada o el sistema es muy complejo se llega a convertir en una mala decisión. A veces esto es conocido como el síntoma del Arquitecto ausente. Sucede que el equipo por no preguntar o por no entender bien algunas cosas empiezan a deformar la arquitectura planteada, para el momento en que regresa el arquitecto lo que empezó como un diseño sencillo web de 3 capas se volvió uno de 7 capas en 4 niveles en escritorio.

21. No validar que se este cumpliendo con la arquitectura propuesta

No crean que simplemente por estar con el equipo, día a día, la arquitectura no se puede llegar a deformar, NO, esto es falso. Es necesario contar con herramientas y diagramas que nos ayuden a validar constantemente que se esté cumpliendo con la arquitectura propuesta. Para esto podemos usar cualquier herramienta que genera un diagrama de matriz de dependencias.

Dependency structure matrix
Dependency structure matrix
22. No contar con una herramienta de inspección de código

No se puede velar por la calidad del código a mano porque toma mucho tiempo, no se llegan a detectar todos los problemas y no se tiene el historial de avance en el tiempo para ver la evolución de la calidad. Para esta tarea podemos usar las siguientes herramientas:

23. No contar con una herramienta de integración continua

Contar con una herramienta de integración continua nos va a ayudar a detectar errores de compilación, ejecución de pruebas e integración de código, dependiendo de la frecuencia con que se programe. Para esta tarea podemos usar las siguientes herramientas:

24. No gestionar los ambientes necesarios (desarrollo y pruebas)

Antes de empezar el desarrollo de un proyecto es importante gestionar los ambientes que va a necesitar el equipo en las fases de implementación (desarrollo) y pruebas, por lo general se debe gestionar: servidor de correos, servidor de reportes, servidor de base de datos, servidor web, servidor de cache/sesión, etc.

25. No usar un sistema de control de versiones (VCS)

Para terminar con esta lista, es importante subir todos los artefactos generados (documentos, manuales, código fuente, etc) en las distintas fases del proyecto a un VCS. No se deben guardar los documentos en el correo, tampoco en una carpeta compartida; además, siempre se debe de tener la última versión actualizada en el repositorio para que el equipo u otro arquitecto pueda acceder a ellos. Para esta tarea podemos usar las siguientes herramientas:

Conclusión:

Estos 13 últimos puntos tampoco son una regla de oro, pero al igual que los primeros pecados es importante que los tengamos en cuenta ya que en cierto modo pueden afectar el diseño de la arquitectura y el éxito del proyecto. Entre los más críticos tenemos: no definir estrategias para solucionar problemas, no desarrollar habilidades interpersonales, no conocer de principios de diseño y no usar una herramienta de integración e inspección continua. Finalmente dentro de nuestro proceso de arquitectura se deben realizar los pasos que se consideren más importantes.

Referencias:
Metal Tip:

Este artículo lo escribí escuchando la canción Aces in exile de la banda Sabaton de Suecia, les comparto el enlace.

Anuncios

3 comentarios en “Arquitectura – Los pecados capitales del arquitecto Parte 2

  1. Son muy buenos tus comentarios, puesto que sino se tienen los conociminetos previos o necesarios puede ocasionar mucho retraso en cualquier especificacion, tiene que existir la observancia de todos los aspectos posibles.

    Me gusta

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