Al principio, siempre es difícil entender un proyecto grande y antiguo. La evaluación de arquitectura es una de las actividades del arquitecto. Normalmente, hay que trabajar con grandes proyectos antiguos, y los resultados deben presentarse en una semana.
¿Cómo evaluar un proyecto de 100k o más líneas de código en una semana y al mismo tiempo proporcionar resultados realmente útiles para el cliente?
La mayoría de los arquitectos y líderes técnicos se han enfrentado a este tipo de evaluaciones de proyectos. Puede parecer un proceso semiformado o un servicio separado como se hace en nuestra empresa; de cualquier manera, la mayoría de ustedes han tenido experiencia con esto.
El original en inglés para sus amigos que no hablan ruso está aquí: .
Enfoque en nuestra empresa
Les contaré cómo funciona esto en nuestra empresa y cómo procedo en situaciones similares, pero pueden ajustar este enfoque según las necesidades de su proyecto y empresa.
Hay dos tipos de evaluación de arquitectura.
Interna – normalmente la hacemos para proyectos dentro de la empresa. Cualquier proyecto puede solicitar una evaluación de arquitectura por varias razones:
- El equipo piensa que su proyecto es perfecto y eso es sospechoso. Hemos tenido tales casos y a menudo en esos proyectos nada es perfecto.
- El equipo quiere verificar su proyecto y sus decisiones.
- El equipo sabe que todo está mal. Incluso pueden enumerar los problemas principales y sus causas, pero quieren obtener una lista completa de problemas y recomendaciones para mejorar el proyecto.
Externa – este es un proceso más formal que la evaluación interna. El cliente siempre llega en un solo caso, cuando todo está mal – muy mal. Normalmente, el cliente comprende que hay problemas globales, pero no puede identificar correctamente las causas y descomponerlas en partes.
La evaluación de arquitectura para un cliente externo es un caso más complicado. El proceso debe ser más formal. Los proyectos siempre son grandes y antiguos. Tienen muchos problemas, errores y código defectuoso. El informe del trabajo realizado debe estar listo en unas pocas semanas como máximo, donde se deben detallar los problemas principales y las recomendaciones para mejorar. Por lo tanto, si resolvemos la evaluación externa del proyecto, la interna será un trámite fácil. Consideremos el caso más complicado.
Evaluación de arquitectura de un proyecto empresarial.
Un proyecto típico para una evaluación es un gran proyecto antiguo de empresa con muchos problemas. El cliente viene a nosotros y nos pide reparar su proyecto. Es como un iceberg, el cliente solo ve la punta de sus problemas y no se da cuenta de lo que hay debajo del agua (en lo profundo del código).
Problemas de los que el cliente puede quejarse y de los que puede ser consciente:
- Problemas de rendimiento
- Problemas con la usabilidad de la aplicación
- Despliegue prolongado
- Falta de pruebas unitarias y otras pruebas
Problemas que el cliente probablemente no se da cuenta, pero que pueden estar presentes en el proyecto:
- Problemas de seguridad
- Problemas de diseño
- Arquitectura incorrecta
- Errores algorítmicos
- Tecnologías inadecuadas
- Deuda técnica
- Proceso de desarrollo incorrecto
Proceso formal de evaluación de la arquitectura
Este es un proceso formal que seguimos en la empresa, pero puedes adaptarlo según tu empresa y proyecto.
Solicitud del cliente
El cliente solicita una evaluación de la arquitectura del proyecto actual. La persona responsable de nuestra parte recopila información básica sobre el proyecto y selecciona a los expertos necesarios. Dependiendo del proyecto, estos pueden ser diferentes expertos.
Arquitecto de Soluciones – la persona principal responsable de la evaluación y la coordinación (y a menudo la única).
Expertos específicos de la pila – .Net, Java, Python, y otros especialistas técnicos según el proyecto y las tecnologías
Expertos en la Nube – pueden ser arquitectos de nube de Azure, GCP o AWS.
Infraestructura – DevOps, administrador de sistemas, etc.
Otros expertos – como big data, machine learning, ingeniero de rendimiento, experto en seguridad, líder de QA.
Recopilación de información sobre el proyecto
Deberías recopilar tanta información como sea posible sobre el proyecto. Puedes utilizar diferentes técnicas según la situación:
- Cuestionarios y otros métodos de comunicación por correo. El método menos efectivo.
- Reuniones en línea.
- Herramientas especiales para el intercambio de información como: Google doc, Confluence, repositorios, etc.
- Reuniones 'en vivo' en el lugar. El método más efectivo y caro.
¿Qué se debe obtener del cliente?
Información básica. Sobre qué trata el proyecto. Su objetivo y valor. Objetivos principales y planes futuros. Objetivos comerciales y estrategias. Problemas principales y resultados deseados.
Información sobre el proyecto. Stack tecnológico, frameworks, lenguajes de programación. Despliegue on-premise o en la nube. Si el proyecto está en la nube, ¿qué servicios se utilizan? ¿Qué patrones arquitectónicos y de diseño se aplicaron?
Requisitos no funcionales. Todos los requisitos relacionados con el rendimiento, la disponibilidad y la facilidad de uso del sistema. Requisitos de seguridad, etc.
Casos de uso básicos y flujos de datos.
Acceso al código fuente. ¡La parte más importante! Debe asegurarse de obtener acceso a los repositorios y la documentación sobre cómo construir el proyecto.
Acceso a la infraestructura. Sería ideal tener acceso a la infraestructura de stage o producción para trabajar con el sistema "vivo". Es una gran ventaja si el cliente tiene herramientas de monitoreo de infraestructura y rendimiento. Hablaremos sobre estas herramientas en la siguiente sección.
La documentación. Si el cliente tiene documentación, es un buen comienzo. Puede estar desactualizada, pero sigue siendo un buen punto de partida. Nunca confíes completamente en la documentación: verifica con el cliente, en la infraestructura real y en el código fuente.
Proceso de evaluación de la arquitectura
¿Cómo manejar una cantidad tan grande de información en tan poco tiempo? Primero, paraleliza el trabajo.
El DevOps debe revisar la infraestructura. El líder técnico en el código. El ingeniero de rendimiento debe observar las métricas de rendimiento. El especialista en bases de datos debe profundizar en las estructuras de datos.
Pero este es el caso ideal, cuando tienes muchos recursos. Normalmente, la evaluación del proyecto la realizan entre una y tres personas. Incluso puedes realizar la evaluación tú mismo, lo cual sucede a menudo si tienes el conocimiento y la experiencia adecuados en todas las áreas del proyecto. En ese caso, necesitas automatizar todos los procesos tanto como sea posible.
Desafortunadamente, tendrás que leer la documentación manualmente. Con la experiencia adecuada, podrás entender rápidamente la calidad de la documentación. Qué es cierto y qué claramente no coincide con la realidad. A veces, puedes encontrar una arquitectura en la documentación que nunca funcionará en la vida real. Este es un disparador para que te preguntes cómo se hace realmente en el proyecto.
Herramientas útiles para automatizar la evaluación del proyecto
La evaluación del código es un ejercicio sencillo. Puede utilizar analizadores de código estáticos que le mostrarán problemas de diseño, rendimiento y seguridad. Aquí hay algunos de ellos:
es una excelente herramienta para arquitectos. Le mostrará una visión general, las dependencias entre módulos y las áreas potenciales para refactorización. Como todas las buenas herramientas, cuesta un buen dinero, aunque puede aprovechar una versión de prueba de 30 días.
es una herramienta clásica. Herramienta para el análisis estático de código. Permite identificar código defectuoso, errores y problemas de seguridad para más de 20 lenguajes de programación.
Todos los proveedores de la nube tienen herramientas para monitorear la infraestructura. Esto le permitirá evaluar correctamente la efectividad de la infraestructura en términos de costo y rendimiento. Para AWS, esto es . Para Azure, es simplemente .
Un monitoreo adicional del rendimiento y la recopilación de registros ayudará a detectar problemas de rendimiento en todos los niveles. Desde bases de datos con consultas ineficientes, el backend y hasta el frontend. Incluso si el cliente no ha instalado estas herramientas anteriormente, puede integrarlas bastante rápidamente en el sistema existente para identificar problemas de rendimiento.
Como siempre, las buenas herramientas tienen un buen precio. Puedo recomendar un par de herramientas de pago. Claro, puede utilizar software de código abierto, pero necesitará más tiempo para ello. Y esto debería hacerse con antelación, no durante la evaluación de la arquitectura.
es una herramienta para evaluar el rendimiento de aplicaciones.
es un servicio en la nube para el monitoreo de sistemas.
Hay muchas herramientas para probar la seguridad. Esta vez, le recomendaré una herramienta gratuita para escanear sistemas.
es una herramienta para escanear aplicaciones web en busca de cumplimiento con estándares de seguridad.
Juntamos todo en un solo lugar.
Preparamos el informe.
Comience su informe con los datos recopilados del cliente. Describa los objetivos del proyecto, las limitaciones y los requisitos no funcionales. Después de eso, mencione toda la entrada de datos: el código fuente, la documentación, la infraestructura.
Siguiente paso. Indique todos los problemas que encontró manualmente o con la ayuda de herramientas automatizadas. Coloque los informes generados automáticamente al final en la sección de anexos. Aquí deben de haber pruebas cortas y concisas de los problemas encontrados.
Priorice los problemas encontrados en una escala de error, advertencia, información. Puede elegir su propia escala, pero esta es la más común.
Como verdadero arquitecto, debe ofrecer recomendaciones para resolver los problemas encontrados. Describa las mejoras y el valor para el negocio que obtendrá el cliente. Cómo demostrar el valor para el negocio de de lo que discutimos anteriormente.
Prepare una hoja de ruta con pequeñas iteraciones. Cada iteración debe incluir el tiempo de ejecución, una descripción, la cantidad de recursos necesarios para mejorar, el valor técnico y el valor para el negocio.
Finalizamos la evaluación de la arquitectura y entregamos el informe al cliente.
Nunca envíe simplemente el informe por correo. Puede que ni siquiera se lea o que se lea sin la debida explicación. En resumen, la comunicación cara a cara ayuda a eliminar malentendidos entre las personas. Debería programar una reunión con el cliente y hablar sobre los problemas encontrados, enfatizando los más significativos. Debe llamar la atención del cliente sobre problemas de los que podría no haber sido consciente, como problemas de seguridad, y explicar cómo pueden afectar el negocio. Muestre su hoja de ruta con mejoras y discuta las diferentes opciones más adecuadas para el cliente. Esto puede incluir tiempo, recursos, volumen de trabajo.
Como cierre de su reunión, envíe al cliente su informe.
En conclusión
La evaluación de la arquitectura es un proceso complejo. Para llevar a cabo una evaluación adecuadamente, debe tener suficiente experiencia y conocimientos.
Es posible proporcionar resultados útiles para el cliente y su negocio en solo una semana. Incluso si lo hace solo.
Basado en mi experiencia, muchas mejoras se detenían a la mitad, y a veces ni siquiera comenzaban. Aquellos que optaban por un enfoque equilibrado y realizaban solo algunas de las mejoras más útiles para el negocio con el mínimo de esfuerzo lograban mejorar significativamente la calidad de su producto. Los que no hacían nada podían cerrar el proyecto después de un par de años.
Su objetivo es mostrar al cliente las máximas mejoras al mínimo precio.
Otros artículos de la sección puede leerse en su tiempo libre.
Le deseo código limpio y buenas soluciones arquitectónicas.
Nuestro grupo de Facebook es — .
Fuente: habr.com
