Un breve análisis de la "visualización de código" | Equipo técnico de JD Cloud

1. ¿Qué es la visualización de código?

La visualización de código es el proceso de crear representaciones gráficas del código fuente para ayudar a comprenderlo y analizarlo.

Comprensión personal: al utilizar medios gráficos (diagrama de arquitectura, diagrama de dependencia, rastreo distribuido, diagrama de clases, diagrama de llama, CallGraph, etc.) para hacer que el código sea observable en ciertas características, se utiliza para ayudar a los desarrolladores a comprender y analizar proyectos o construcciones. Algunas herramientas de automatización.

2. ¿Por qué se necesita la visualización del código?

Escenario 1: dificultad para comprender la lógica del código

El proyecto tiene una gran cantidad de código y una rápida iteración de requisitos, por lo que los documentos compilados cada vez quedarán obsoletos rápidamente. Es extremadamente difícil para los nuevos estudiantes comenzar y para los veteranos es difícil tener una comprensión integral de la lógica comercial general del proyecto y, a menudo, necesitan reorganizar la lógica.



Escenario 2: El impacto del cambio es difícil de evaluar

La demanda era modificar la lógica de la página A, pero debido a que el código de fondo tenía mucha lógica común y el nivel de llamada era muy profundo, se descubrió después de conectarse que afectaba la lógica de la página B, lo que provocó una conexión en línea. accidente.



Escenario 3: La reconstrucción del proyecto carece de un punto de partida

Los proyectos antiguos han pasado por largas iteraciones y múltiples cambios de equipo, lo que ha dado como resultado una lógica de código interno muy confusa y nadie puede comprender completamente toda la lógica. Sin embargo, la demanda de nuevas iteraciones comerciales continúa y el costo de las modificaciones de los proyectos originales es cada vez mayor. Se necesita urgentemente una reconstrucción para lograr una mayor eficiencia en I+D.



Otros escenarios: la regresión de casos automatizada a menudo no puede cubrir la nueva lógica; es difícil solucionar problemas en línea y localizar rápidamente el código de error...

3. ¿Cómo lograr la visualización del código?

Call Graph es una representación gráfica de la relación entre diferentes llamadas a funciones en un programa. Muestra cómo interactúan las funciones de un programa, lo que permite a los desarrolladores comprender el flujo del programa e identificar posibles problemas de rendimiento.

A continuación se explica el esquema de generación de Call Graph, una forma de visualización de código, que se puede dividir en análisis estático y dinámico:

3.1 Análisis estático del programa

1) Generar basado en el código fuente

Antes de explicar el proceso de uso del código fuente para generar CallGraph, primero revisemos el conocimiento relevante de los principios de compilación.

 

La parte frontal del compilador está relacionada principalmente con el idioma fuente e incluye principalmente:

Análisis léxico : también llamado escaneo, su tarea principal es escanear los caracteres del programa fuente línea por línea de izquierda a derecha, identificar cada palabra, determinar el tipo de palabra y convertir las palabras identificadas en una representación unificada en la máquina. — — Forma simbólica. Se puede comparar con el proceso de combinar letras inglesas en palabras.



Análisis de sintaxis : también llamado análisis sintáctico. El analizador identifica varias frases de la secuencia de tokens generada por el analizador léxico, construyendo así un árbol de sintaxis y determinando si el programa fuente es estructuralmente correcto. Se puede comparar con palabras en inglés que se combinan en oraciones.



Análisis semántico : utilice la información del árbol de sintaxis y la tabla de símbolos para verificar si el programa fuente es consistente con la semántica definida por el lenguaje, como: verificación de tipos, análisis sensible al contexto, etc. Se puede comparar con comprobar si una oración en inglés tiene sentido (por ejemplo: Dog is cat, esta oración es gramaticalmente buena pero semánticamente incorrecta). También recopila la información de atributos del identificador y almacena esta información en el árbol de sintaxis o tabla de símbolos para su uso en el posterior proceso de generación de código intermedio.

Código intermedio : una representación intermedia que contiene información de la cual se pueden derivar todos los datos sobre un programa. El mismo código intermedio puede reutilizar la lógica del optimizador y utilizar directamente funciones de fondo del compilador relacionadas, lo que hace que cada enlace sea más independiente y más fácil de expandir. Estructuralmente, existen IR gráfico, IR lineal e IR híbrido.

La parte de back-end del compilador está relacionada principalmente con el lenguaje de destino, incluido el optimizador de código y el generador de código de destino. Esta parte tiene poco que ver con la generación de CG. Sin más detalles sobre los principios, los estudiantes interesados ​​pueden aprender sobre LLVM y Graalvm .



Con el conocimiento básico de los principios de compilación, echemos un vistazo al proceso de producción de CG a partir del código fuente:



Se puede encontrar que el análisis es en realidad una reproducción del proceso de interfaz del compilador, en el que AST, CFG y CG se cuentan como gráfico IR. Las herramientas de análisis de código fuente listas para usar incluyen Antlr / javaparser /soot, etc. A continuación se utiliza la herramienta javaparser como ejemplo para describir brevemente el proceso de generación:

Paso 1 : Importe el código fuente y los paquetes de dependencia del proyecto que deben analizarse y utilice herramientas para analizarlos.



Paso 2 : use el modo de visita para obtener toda la información del método y del método de llamada





Paso 3 : seleccione un método inicial y genere CG según el método y la relación de llamada

Ventajas: Independiente del idioma y altamente escalable. Desventajas: la precisión es deficiente y es necesario ajustarla; la velocidad de análisis es lenta; es difícil dominar herramientas que no sean del lenguaje Java.

2) Basado en la generación de código de bytes

El desarrollo personalizado de funciones del lenguaje puede generar resultados más rápidos. El código de bytes de Java en realidad se puede considerar como un IR lineal y el proceso de análisis es similar. Al mismo tiempo, Java tiene una gran cantidad de herramientas de manipulación de códigos de bytes (ASM, Javaassit, bcel, etc.), lo que facilita el análisis de códigos de bytes.

La idea básica es obtener la información de firma de clase y método del archivo .class, y luego encontrar la instrucción de invocación en el código de bytes para obtener la firma del método de llamada. Con base en estos dos datos, se puede construir el CG. Al mismo tiempo, debido a que el código de bytes contiene la firma completa del método, no es necesario introducir archivos jar dependientes para el análisis como el análisis del código fuente, por lo que la eficiencia del análisis será mucho más rápida.



A continuación se utiliza la herramienta bcel como ejemplo para describir brevemente el proceso de generación:

Paso 1 : analice el proyecto de destino, puede usar directamente el paquete jar empaquetado



Paso 2 : use el modo de visita para obtener toda la información del método y del método de llamada





Paso 3 : seleccione un método inicial y genere CG según el método y la relación de llamada

Ventajas: alta precisión de análisis; rápida velocidad de análisis. Desventajas: escalabilidad deficiente relacionada con el lenguaje.

PD: Recomiendo un complemento de idea llamado call graph , que se implementa en función de la capacidad psi de idea . Cuando la cantidad de código del proyecto no es grande, el análisis es bastante preciso.



3.2 Análisis dinámico del programa

También conocido como análisis de programas en tiempo de ejecución, generalmente se implementa en función del método del agente. No lo explicaré aquí por ahora. Escribiré un artículo aparte para explicar el principio cuando tenga la oportunidad. Los estudiantes interesados ​​pueden probar AppMap .



4. ¿Cuáles son los escenarios de aplicación?

Escenario 1: Cambiar la identificación del riesgo

Antecedentes : Identificar los riesgos que plantean los cambios en la infraestructura, los cambios externos al sistema y los cambios dentro del sistema.



Escenario 2: pruebas precisas

Antecedentes : las pruebas precisas se definen como una serie de operaciones que utilizan medios técnicos para recopilar, almacenar, calcular, resumir y visualizar los datos generados durante el proceso de prueba para, en última instancia, ayudar al equipo a mejorar la eficiencia de las pruebas de software y mejorar y optimizar el rendimiento general. calidad del proyecto. Para obtener una explicación detallada, lea los capítulos segundo y tercero de Pruebas precisas.





Escenario 3: Guardia de Arquitectura

Antecedentes : Nos enfrentamos a muchos desafíos en la gobernanza arquitectónica.

1) Existe un desajuste entre el diseño y la implementación. Existe una gran diferencia entre la arquitectura de software diseñada y la arquitectura implementada real. Esta diferencia a menudo requiere que la codificación esté en línea o incluso que se descubra después de un período de tiempo;

2) Sin normas/incumplimiento de normas. Como desarrollador senior, hemos desarrollado una serie de especificaciones, pero no muchos miembros del equipo están dispuestos a cumplir;

3) La cantidad de código es enorme y es difícil identificar problemas. En un sistema creado por una docena o docenas de microservicios, a menudo resulta difícil descubrir rápidamente las intrincadas relaciones entre ellos;

4) Pueden ocurrir errores en todos los niveles del modelo arquitectónico. Como acoplamiento API entre servicios, acoplamiento entre códigos, acoplamiento de bases de datos, etc .;

5) Los propios arquitectos y desarrolladores carecen de una gran experiencia. Sé que hay un problema, pero no puedo decir cuál es el problema y no sé cómo mejorarlo.

Por lo tanto, necesitamos una plataforma/herramienta que nos ayude a resolver estos problemas.

Caso : ArchGuard

Proporciona un análisis visual basado en el modelo C4 (contexto, contenedor, componente y código) y proporciona algunos indicadores de monitoreo del estado de la arquitectura.





5. Ampliar la lectura

(Descargo de responsabilidad: algunas imágenes son de Internet y han sido eliminadas)

Autor: Tecnología Jingdong Xie Xiao

Fuente: Comunidad de desarrolladores de JD Cloud Indique la fuente al reimprimir

Lei Jun: La versión oficial del nuevo sistema operativo de Xiaomi, ThePaper OS, ha sido empaquetada. Una ventana emergente en la página de lotería de la aplicación Gome insulta a su fundador. El gobierno de Estados Unidos restringe la exportación de la GPU NVIDIA H800 a China. La interfaz de Xiaomi ThePaper OS está expuesto. Un maestro usó Scratch para frotar el simulador RISC-V y se ejecutó con éxito. Kernel de Linux Escritorio remoto RustDesk 1.2.3 lanzado, soporte mejorado para Wayland Después de desconectar el receptor USB de Logitech, el kernel de Linux falló Revisión aguda de DHH de "herramientas de empaquetado ": no es necesario construir la interfaz en absoluto (Sin compilación) JetBrains lanza Writerside para crear documentación técnica Herramientas para Node.js 21 lanzadas oficialmente
{{o.nombre}}
{{m.nombre}}

Supongo que te gusta

Origin my.oschina.net/u/4090830/blog/10120313
Recomendado
Clasificación