🔭 👴 🍨 Cómo leer y corregir 100,000 líneas de código por semana 🥚 🥇 🕚

Al principio, siempre es difícil entender el proyecto grande y antiguo. La evaluación de la arquitectura es una de las actividades del arquitecto. Por lo general, debe trabajar con proyectos grandes y antiguos, y los resultados se deben proporcionar en una semana.

Cómo evaluar un proyecto con un tamaño de 100k o más líneas de código por semana mientras se proporcionan resultados realmente útiles para el cliente.

La mayoría de los arquitectos y esos líderes se han encontrado con evaluaciones de proyectos similares. Puede parecer un proceso semiformal o como un servicio separado como se hace en nuestra empresa, de todos modos la mayoría de ustedes se han ocupado de esto.

El inglés original para sus amigos que no hablan ruso está aquí: Evaluación de arquitectura en una semana .

El enfoque en nuestra empresa.

Le diré cómo funciona en nuestra empresa y cómo actúo en tales situaciones, pero puede cambiar fácilmente este enfoque de acuerdo con las necesidades de su proyecto y empresa.

Hay dos sabores de la evaluación de la arquitectura.

Interno : generalmente lo 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 esto es sospechoso. Tuvimos tales casos y, a menudo, en tales proyectos, todo está lejos de ser perfecto.
El equipo quiere probar su proyecto y sus decisiones.
El equipo sabe que todo está 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 la evaluación interna. Un cliente siempre viene solo en un caso cuando todo está mal, muy mal. Por lo general, el cliente comprende que existen problemas globales, pero no puede determinar correctamente las causas y desglosarlas en componentes.

Evaluar la 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 viejos. Tienen muchos problemas, errores y código torcido. Un informe sobre el trabajo realizado debe estar listo dentro de unas pocas semanas como máximo, donde debe haber los principales problemas y recomendaciones para mejorar. Por lo tanto, si nos ocupamos de la evaluación externa del proyecto, la interna será un par de tonterías. Considere el caso más difícil.

Evaluación de la arquitectura de un proyecto empresarial.

Un proyecto típico de evaluación es un proyecto empresarial grande y antiguo con muchos problemas. Un cliente viene a nosotros y nos pide que arreglen su proyecto. Es como con un iceberg, el cliente solo ve la punta de sus problemas y no sabe qué hay debajo del agua (en la parte posterior del código).

Problemas de los que el cliente puede quejarse y que puede conocer sobre ellos:

Problemas de desempeño
Problemas de usabilidad
Despliegue largo
Falta de unidad y otras pruebas.

Problemas que el cliente probablemente desconoce, pero que pueden estar presentes en el proyecto:

Problemas de seguridad
Problemas de diseño
Arquitectura incorrecta
Errores algorítmicos
Tecnología inadecuada
Deuda técnica
Proceso de desarrollo inválido

Proceso de evaluación de arquitectura formal

Este es un proceso formal al que nos adherimos en la empresa, pero puede ajustarlo usted mismo dependiendo de su empresa y proyecto.

Solicitud del 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 los expertos necesarios. Dependiendo del proyecto, estos pueden ser diferentes expertos.

Solution Architect es la principal persona 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 expertos técnicos según el proyecto y las tecnologías de
expertos en la nube : estos pueden ser arquitectos en la nube de Azure, GCP o AWS.
Infraestructura : DevOps, administrador del sistema, etc.
Otros expertos son big data, aprendizaje automático, ingeniero de rendimiento, experto en seguridad, líder en control de calidad.

Recopilación de información del proyecto

Debe recopilar tanta información como sea posible sobre el proyecto. Puede usar diferentes técnicas según la situación:

Cuestionarios y otros medios de comunicación por correo. La forma más ineficiente.
Reuniones en linea.
Herramientas especiales para el intercambio de información como: Google doc, Confluence, repositorios, etc.
Reuniones "en vivo" en el lugar. La forma más efectiva y costosa.

¿Qué se debe recibir del cliente?

Información básica. ¿De qué trata el proyecto? Su finalidad y valor. Los principales objetivos y planes para el futuro. Objetivos y estrategias comerciales. Los principales problemas y el resultado deseado.

Información sobre el proyecto . Pila tecnológica, frameworks, 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.

No requisitos funcionales . Todos los requisitos relacionados con el rendimiento, disponibilidad, usabilidad del sistema. Requisitos de seguridad, etc.

Juskeys básicos y flujos de datos.

Acceso al código fuente . ¡La parte más importante! Definitivamente debe obtener acceso a repositorios y documentación sobre cómo armar un proyecto.

Acceso a infraestructura . Sería bueno tener acceso al escenario o la infraestructura de producción para trabajar con un sistema en vivo. Esto es un gran éxito si el cliente tiene herramientas para monitorear la infraestructura y la productividad. Hablaremos de estas herramientas en la siguiente sección.

Documentación . Si el cliente tiene documentación, este es un buen comienzo. Puede estar desactualizado, pero sigue siendo un buen comienzo. Nunca crea la documentación: verifíquela con el cliente, en una infraestructura real y en el código fuente.

Proceso de evaluación de arquitectura

¿Cómo, entonces, procesar una cantidad de información tan grande en tan poco tiempo? En primer lugar, paralelizar el trabajo.

DevOps debería analizar la infraestructura. Los llevo al código. Ingeniero de rendimiento ver métricas de rendimiento. Un especialista en bases de datos debe profundizar en las estructuras de datos.

Pero este es un caso ideal cuando tienes muchos recursos. Típicamente, un proyecto es evaluado por una o tres personas. Incluso puede realizar una evaluación usted mismo, lo que a menudo sucede si tiene el conocimiento y la experiencia adecuados en todas las áreas del proyecto. En este caso, debe automatizar todos los procesos tanto como sea posible.

Desafortunadamente, tendrá que leer la documentación manualmente. Con la experiencia adecuada, puede comprender rápidamente la calidad de la documentación. Lo que es verdad allí y lo que claramente no coincide con la realidad. A veces puede encontrar una arquitectura de este tipo en la documentación que nunca funcionará en la vida real. Es un factor desencadenante para que pienses, pero cómo se hace en realidad en el proyecto.

Herramientas útiles para automatizar la evaluación de proyectos.

Evaluar un código es un ejercicio simple. Puede usar analizadores de código estático para mostrar problemas de diseño, rendimiento y seguridad. Aquí hay algunos de ellos:

Estructura 101 es una gran herramienta para un arquitecto. Le mostrará el panorama general, la relación entre los módulos y las áreas potenciales para la refactorización. Como todas las buenas herramientas, cuesta mucho dinero, al mismo tiempo puede usar la versión de prueba de 30 días.

SonarQube es una buena herramienta antigua. Herramienta para el análisis de código estático. Le permite identificar códigos incorrectos, errores, 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 correctamente la efectividad de la infraestructura en términos de costo y rendimiento. Para AWS, este es un asesor de confianza . Para Azure, es solo un asesor de Azure .

La supervisión y el registro de rendimiento adicionales pueden ayudarlo a encontrar problemas de rendimiento en todos los niveles. Comenzando desde una base de datos con consultas ineficientes, un backend y terminando con un frontend. Incluso si el cliente no ha instalado estas herramientas antes, puede integrarlas rápidamente en su sistema existente para identificar problemas de rendimiento.

Como siempre, las buenas herramientas valen la pena. Puedo recomendar un par de herramientas pagas. Por supuesto, puede usar código abierto, pero necesitará más tiempo para esto. Y esto debe hacerse por adelantado, y no en el proceso de evaluación de la arquitectura.

New Relic : herramienta de evaluación del rendimiento de la aplicación
Datadog : servicio de monitoreo hermano basado en la nube

Hay muchas herramientas para las pruebas de seguridad. Esta vez le recomendaré una herramienta de escaneo gratuita del sistema.

OWASP ZAP es una herramienta para escanear aplicaciones web para cumplir con los estándares de seguridad.

Poniendolo todo junto.

Estamos preparando un informe

Comience su informe con datos del cliente. Describa los objetivos del proyecto, limitaciones, requisitos no funcionales. Después de esto, todos los datos entrantes deben mencionarse como código fuente, documentación e infraestructura.

El siguiente paso. Enumere todos los problemas que haya encontrado manualmente o utilizando herramientas automatizadas. Coloque grandes informes autogenerados al final en la sección de la aplicación. Aquí debe ser una evidencia breve y sucinta de los problemas encontrados.
Priorice los problemas encontrados en el error, advertencia, escala de información. Puede elegir su propia escala, pero esto generalmente se acepta.

Como verdadero arquitecto, debe proporcionar recomendaciones sobre cómo solucionar los problemas que ha encontrado. Describa las mejoras y el valor para el negocio que recibirá el cliente. Cómo mostrar el valor comercial derefactorización de la arquitectura que discutimos anteriormente.

Prepare una hoja de ruta con pequeñas iteraciones. Cada iteración debe contener tiempo para la ejecución, descripción, cantidad de recursos necesarios para la mejora, valor técnico y valor para el negocio.

Terminamos la evaluación de la arquitectura y proporcionamos al cliente un informe.

Nunca solo envíe un informe por correo. Puede o no leerse o leerse y no entenderse sin una explicación adecuada. En resumen, la comunicación en vivo ayuda a eliminar los malentendidos entre las personas. Debe programar una reunión con el cliente y hablar sobre los problemas encontrados, enfocándose en los más importantes. Vale la pena prestar atención al cliente a problemas sobre los cuales él ni siquiera sospecha. Tales como problemas de seguridad y explicar cómo pueden afectar a un negocio. Muestre su hoja de ruta con mejoras y discuta las diferentes opciones que son más adecuadas para el cliente. Puede ser tiempo, recursos, cantidad de trabajo.

Como resumen de su rally, envíe su informe al cliente.

Finalmente

Evaluar la arquitectura es un proceso complejo. Para llevar a cabo una evaluación adecuada, debe tener suficiente experiencia y conocimiento.

Es real: proporcionar al cliente resultados útiles para él y su negocio en solo una semana. Incluso si lo haces solo.

Según mi experiencia, muchas mejoras se descargaron en el medio y, a veces, nunca comenzaron. Aquellos que eligieron el término medio para sí mismos e hicieron solo una parte de las mejoras que fueron más útiles para las empresas con un trabajo mínimo, mejoraron significativamente la calidad de su producto. Aquellos que no hicieron nada después de un par de años pudieron cerrar completamente el proyecto.

Su objetivo es mostrar al cliente la mejora máxima al precio más bajo.

Otros artículos de la sección de arquitectura se pueden leer a su gusto.

Le deseo un código limpio y buenas soluciones arquitectónicas.

Nuestro grupo de Facebook es Arquitectura y desarrollo de software .

Cómo leer y corregir 100,000 líneas de código por semana