Al principio siempre es difícil entender un proyecto grande y antiguo. La arquitectura es una de las actividades de una evaluación de arquitectos. Por lo general, hay que trabajar con proyectos grandes y antiguos y los resultados deben entregarse 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 que sean realmente útiles para el cliente.
La mayoría de los arquitectos y líderes técnicos se han encontrado con evaluaciones de proyectos similares. Esto puede parecer un proceso semiformal o un servicio separado como se hace en nuestra empresa; de una forma u otra, la mayoría de ustedes se han enfrentado a esto.
El original en inglés para tus amigos que no hablan ruso está aquí: .
El enfoque de nuestra empresa.
Te contaré cómo funciona en nuestra empresa y cómo actúo en situaciones similares, pero puedes cambiar fácilmente este enfoque según las necesidades de tu proyecto y empresa.
Hay dos tipos de evaluación de arquitectura.
Interno – normalmente lo hacemos para proyectos dentro de la empresa. Cualquier proyecto puede solicitar una evaluación de arquitectura por varios motivos:
- El equipo cree que su proyecto es perfecto y esto resulta sospechoso. Hemos tenido casos similares y, a menudo, en proyectos de este tipo todo dista mucho de ser ideal.
- El equipo quiere probar su proyecto y sus soluciones.
- El equipo sabe que las cosas están mal. Incluso pueden enumerar los principales problemas y causas, pero quieren una lista completa de problemas y recomendaciones para mejorar el proyecto.
Externo Es un proceso más formal que una evaluación interna. El cliente siempre viene solo en un caso, cuando todo está mal, muy mal. Normalmente el cliente comprende que existen problemas globales, pero no puede identificar correctamente las causas y desglosarlas en componentes.
Evaluar una arquitectura para un cliente externo es un caso más complejo. El proceso debería ser más formal. Los proyectos son siempre grandes y antiguos. Tienen muchos problemas, errores y código corrupto. En un plazo máximo de unas semanas debería estar listo un informe sobre el trabajo realizado, que debería incluir los principales problemas y recomendaciones de mejora. Por tanto, si nos ocupamos de la evaluación externa del proyecto, la evaluación interna será pan comido. Consideremos el caso más difícil.
Evaluación de la arquitectura del proyecto empresarial.
Un proyecto típico a evaluar es un proyecto empresarial antiguo y grande con muchos problemas. Un cliente viene a nosotros y nos pide que arreglemos su proyecto. Es como con un iceberg, el cliente sólo ve la punta de sus problemas y no tiene idea de lo que hay debajo del agua (en las profundidades del código).
Problemas de los que el cliente puede quejarse y de los que puede tener conocimiento:
- Problemas de desempeño
- Problemas de usabilidad
- Despliegue a largo plazo
- Falta de pruebas unitarias y de otro tipo.
Problemas que muy probablemente el cliente no conoce, pero que pueden estar presentes en el proyecto:
- Problemas de seguridad
- Problemas de diseño
- Arquitectura incorrecta
- Errores algorítmicos
- Tecnologías inapropiadas
- Deuda técnica
- Proceso de desarrollo incorrecto
Proceso formal de revisión de arquitectura.
Este es un proceso formal que seguimos como empresa, pero puedes personalizarlo dependiendo de tu empresa y proyecto.
Solicitud de un cliente
El cliente solicita evaluar 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.
Solution Architect – la principal persona responsable de la evaluación y la coordinación (y a menudo la única).
Pila de expertos específicos – .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.
EN LA MINA – DevOps, administrador del sistema, etc.
Otros expertos – como big data, aprendizaje automático, ingeniero de rendimiento, experto en seguridad, líder de control de calidad.
Recopilación de información sobre el proyecto.
Debe recopilar la mayor cantidad de información posible sobre el proyecto. Puedes utilizar diferentes técnicas según la situación:
- Cuestionarios y otros métodos de comunicación vía correo. La forma más ineficaz.
- Reuniones en línea.
- Herramientas especiales para intercambio de información como: Google doc, Confluence, repositorios, etc.
- Reuniones “en vivo” in situ. La forma más eficaz y cara.
¿Qué deberías obtener del cliente?
Información básica. ¿De qué se trata el proyecto? Su finalidad y valor. Principales objetivos y planes de futuro. Objetivos y estrategias de negocio. Principales problemas y resultados deseados.
Información del proyecto. Pila de tecnología, marcos, lenguajes de programación. Implementación local o en la nube. Si el proyecto está en la nube, qué servicios se utilizan. Qué patrones arquitectónicos y de diseño se utilizaron.
requerimientos 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! Definitivamente deberías tener acceso a los repositorios y a la documentación sobre cómo construir el proyecto.
Acceso a infraestructura. Sería bueno tener acceso al escenario o a la infraestructura de producción para trabajar con el sistema en vivo. Es un gran éxito si el cliente dispone de herramientas para monitorear la infraestructura y el rendimiento. Hablaremos de estas herramientas en la siguiente sección.
Документация. Si el cliente tiene documentación, este es un buen comienzo. Puede que esté desactualizado, pero sigue siendo un buen comienzo. Nunca confíes en la documentación: pruébala con el cliente, en infraestructura real y en el código fuente.
Proceso de evaluación de arquitectura
¿Cómo se puede procesar una cantidad tan grande de información en tan poco tiempo? En primer lugar, paralelice el trabajo.
DevOps debería mirar la infraestructura. Guía técnica hacia el código. Ingeniero de rendimiento para ver métricas de rendimiento. Un especialista en bases de datos debería profundizar en las estructuras de datos.
Pero este es un caso ideal cuando tienes muchos recursos. Normalmente, entre una y tres personas evalúan un proyecto. Incluso puede realizar el presupuesto usted mismo, lo que suele ser el caso si tiene el conocimiento y la experiencia adecuados en todas las áreas del proyecto. En este caso, es necesario automatizar todos los procesos tanto como sea posible.
Lamentablemente, tendrás que leer la documentación manualmente. Con la experiencia adecuada, podrá comprender rápidamente la calidad de la documentación. Qué es verdad y qué claramente no coincide con la realidad. A veces es posible que veas arquitectura en documentación que nunca funcionará en la vida real. Esto es un disparador para que pienses en cómo se hizo en realidad en el proyecto.
Herramientas útiles para automatizar la evaluación de proyectos
La evaluación del código es un ejercicio simple. Puede utilizar analizadores de código estático que le mostrarán problemas de diseño, rendimiento y seguridad. Éstos son algunos de ellos:
es una gran herramienta para un arquitecto. Le mostrará el panorama general, las dependencias entre módulos y áreas potenciales para refactorización. Como todas las buenas herramientas, cuesta mucho dinero, pero puedes aprovechar una versión de prueba de 30 días.
- una buena herramienta antigua. Una herramienta para el análisis de código estático. Le permite identificar códigos incorrectos, errores y problemas de seguridad para más de 20 lenguajes de programación.
Todos los proveedores de la nube tienen herramientas de monitoreo de infraestructura. Esto le permitirá evaluar adecuadamente la efectividad de su infraestructura en términos de costo y rendimiento. Para AWS esto es . Es fácil para Azure .
La supervisión y el registro del rendimiento adicionales ayudarán a encontrar problemas de rendimiento en todos los niveles. Comenzando desde una base de datos con consultas ineficaces, el backend y terminando con el frontend. Incluso si el cliente no ha instalado estas herramientas anteriormente, puede integrarlas en el sistema existente con bastante rapidez para identificar problemas de rendimiento.
Como siempre, las buenas herramientas valen la pena. Puedo recomendar un par de herramientas pagas. Por supuesto, puedes utilizar el código abierto, pero te llevará más tiempo. Y esto debe hacerse desde el principio, no durante el proceso de evaluación arquitectónica.
– una herramienta para evaluar el rendimiento de la aplicación
– servicio de monitoreo del sistema en la nube
Hay muchas herramientas disponibles para pruebas de seguridad. Esta vez te recomendaré una herramienta gratuita de escaneo del sistema.
– una herramienta para escanear aplicaciones web para verificar el cumplimiento de los estándares de seguridad.
Juntemos todo en un todo.
Preparando un informe
Comience su informe con los datos que recopiló del cliente. Describa los objetivos, limitaciones y requisitos no funcionales del proyecto. Después de esto, se deben mencionar todos los datos de entrada: código fuente, documentación, infraestructura.
Próximo paso. Enumere cualquier problema que haya encontrado manualmente o utilizando herramientas automatizadas. Coloque informes grandes generados automáticamente al final de la sección de aplicaciones. Debe haber evidencia breve y concisa de los problemas encontrados.
Priorice los problemas encontrados en la escala de error, advertencia e información. Puedes elegir tu propia escala, pero esta es la generalmente aceptada.
Como verdadero arquitecto, es tu responsabilidad brindar recomendaciones para corregir los problemas encontrados. Describa las mejoras y el valor comercial que recibirá el cliente. Cómo mostrar valor empresarial desde discutimos antes.
Prepare una hoja de ruta con pequeñas iteraciones. Cada iteración debe contener tiempo para completarse, descripción, cantidad de recursos necesarios para la mejora, valor técnico y valor comercial.
Realizamos el estudio de arquitectura y entregamos un informe al cliente
Nunca envíe simplemente un informe por correo. Es posible que no se lea en absoluto, o que no se lea ni se entienda sin una explicación adecuada. En resumen, la comunicación en vivo ayuda a eliminar malentendidos entre las personas. Se debe programar una reunión con el cliente y hablar sobre los problemas encontrados, centrándose en los más significativos. Vale la pena llamar la atención del cliente sobre problemas de los que quizás ni siquiera sea consciente. Como problemas de seguridad y explicar cómo podrían afectar al negocio. Muestra tu hoja de ruta con mejoras y discute diferentes opciones que sean más adecuadas para el cliente. Esto podría ser tiempo, recursos, cantidad de trabajo.
Como resumen de su reunión, envíe su informe al cliente.
en conclusión
La evaluación de la arquitectura es un proceso complejo. Para realizar la evaluación correctamente es necesario tener suficiente experiencia y conocimientos.
Es posible proporcionar al cliente resultados útiles para él y su negocio en tan solo una semana. Incluso si lo haces solo.
Según mi experiencia, muchas mejoras se descargaron en el medio y, a veces, nunca se iniciaron. Aquellos que eligieron el punto medio e hicieron solo una parte de las mejoras más útiles para el negocio con costos laborales mínimos mejoraron significativamente la calidad de su producto. Aquellos que no hicieron nada pudieron cerrar el proyecto por completo después de un par de años.
Su objetivo es mostrar al cliente las máximas mejoras por el precio mínimo.
Otros artículos de la sección puedes leer en tu tiempo libre.
Les deseo un código limpio y buenas decisiones arquitectónicas.
Nuestro grupo de facebook - .
Fuente: habr.com