Qualité de code : zoom sur notre outil agent Java 100% fait maison !

Objectif : qualité de code Java

Dans la recherche constant de l'amélioration de nos audits et de nos analyses, nous avons décidé de créer un outil nous permettant de mettre en lumière les différentes erreurs courantes lors des interactions avec les bases de données, tout en élevant la qualité de code Java.

On vous en parle dans cet article, bonne lecture !

Qu’est-ce qu’un agent ?

Un agent dans le monde de JavaLangage de développement très populaire ! est un JAR (Java Archive) qui peut observer et modifier les programmes s'exécutant dans la JVM (Java Virtual Machine). Les agents sont très utilisés pour l'observabilité des applications.

Le plus connu est celui d'Open Telemetry.

Pourquoi le développement d'un agent Java ?

Avec le temps, nous avons remarqué qu'il est très facile de faire une analyse statique de la base de données. Nous pouvons facilement vérifier la cohérence du schéma et les problèmes courants de typage des colonnes ou de formalisme.

Cependant, il est plus difficile d'effectuer des analyses sur l'usage de la base de données ainsi que sur les requêtes qui y sont effectuées. En effet, de plus en plus, nous utilisons des ORM (Object Relational Mapping) dans nos applications, ce qui nous permet de nous abstraire de la création de requêtes à la base de données. Nous pouvons donc avoir une base de données parfaitement conceptualisée mais une mauvaise utilisation.

Notre objectif était donc de pouvoir écouter les applications en fonctionnement pour intercepter les requêtes SQLLangage permettant de communiquer avec une base de données., effectuer une analyse dynamique et générer un rapport des anomalies détectées et ainsi contribuer à une meilleure qualité de code Java.

Comment a-t-on réalisé notre agent Java ?

La première étape était de pouvoir récupérer les requêtes SQL lors de l'exécution des applications. Le fait d'utiliser un agent Java nous permet de modifier les différentes classes de l'application. Grâce à cela, nous pouvons modifier la classe qui effectue les requêtes à la base de données et lui dire de nous notifier chaque fois qu'elle va effectuer une requête.

La deuxième étape était de récupérer l'appel API associé à la requête SQL. Nous souhaitions également avoir cette information pour compléter notre analyse.

La dernière étape était de récupérer les informations de connexion à la base de données pour nous permettre de mettre en relation la structure de la base de données avec les requêtes qui sont effectuées.

Une fois en possession de toutes ces informations, nous pouvons commencer à coder l'analyse des requêtes dans leur contexte.

À quoi sert notre outil agent Java ?

Cet agent Java nous sert à détecter différents problèmes au sein des applications. Les premiers problèmes que nous pouvons détecter sont directement liés aux requêtes SQL. Nous souhaitons que, dans toutes les applications que nous analysons, remonter les requêtes qui possèdent une des caractéristiques suivantes :

• Au moins une sous-requête
• Un IN avec plus de 3 entrées
• Une condition de jointure qui ne se base pas uniquement sur des FK (Foreign Key) ou PK (Primary Key)
• Une seule condition WHERE qui n'est pas en lien avec une FK ou PK
• Un attribut dans le ORDER BY qui n'est pas une FK ou PK

La deuxième partie de l'analyse consiste à vérifier la pertinence des requêtes. Nous souhaitons que notre agent remonte une alerte pour tout appel APIUne API est un programme permettant à deux applications distinctes de communiquer entre elles et d’échanger des données. qui possède trop de requêtes SQL ou qui a un mauvais "data ratio". Ce que nous appelons "data ratio" est la division de la quantité de données récupérées par la base de données par la quantité de données retournées par l'appel API. Si le ratio est trop élevé, cela signifie que l'on récupère trop de données de la base de données.

La troisième anomalie que nous souhaitons remonter est celle des problèmes de N+1 au sein des applications. Ce problème est généralement lié à une mauvaise configuration des ORM. Le problème de N+1 survient lorsque l'on effectue 1 requête SQL pour récupérer un des enfants d'une entité. De ce fait, pour N enfants, on effectue N requêtes, plus 1 requête pour récupérer le parent. Cela nous fait donc N+1 requêtes pour récupérer les données. C'est un problème important de performance car cela multiplie grandement le nombre de requêtes à la base de données, alors que le tout peut être récupéré à minima en 2 requêtes. Pour identifier ces problèmes, nous vérifions le nombre de requêtes similaires par appel API.

La dernière anomalie que nous remontons est celle des fuites mémoires évidentes. L'objectif est d'analyser les attributs des controllers et des services, à la recherche de Map ou de List dont la taille augmente entre le début de l'appel API et la fin.

Chacune des anomalies que nous remontons peut parfois avoir une bonne raison d'exister, cependant, nous souhaitons malgré tout avoir ces alertes lorsque nous faisons un audit des applications. Cela nous permet par la suite de vérifier la pertinence de l'anomalie et de la remonter ou non au propriétaire de l'application.

Et maintenant, comment l’agent Java va-t-il être utilisé ?

Actuellement, l'outil nous permet d'effectuer des analyses sur tous les projets Java Spring Boot qui utilisent un SGBD courant (MySQLMoteur de gestion de base de données., MariaDB, PostgreSQLMoteur de gestion de base de données libre de droit., SQLServer et Oracle). Nous utilisons donc cet agent sur tous les audits d'applications Java que nous réalisons ainsi que sur tous nos projets internes pour améliorer la qualité de ces derniers.

Nos objectifs futurs sont de proposer des outils similaires pour tous les langages côté serveur que nous utilisons régulièrement. Nous souhaitons également améliorer cet agent pour lui permettre de prendre en compte un plus grand éventail d'applications, telles que celles développées avec le framework Quarkus ou simplement une application JEEJava Entreprise Edition.

Pour conclure sur l’agent Java made in AXOPEN

Nous avons été assez surpris de constater qu'il n'existait pas d'outil d'analyse nous permettant de mettre en lien le schéma de la base de données avec son utilisation par une application. Nous avons donc créé une première version en Java, qui a été assez simple à implémenter.

Nous sommes très satisfaits du temps investi dans la réalisation de cet agent Java car il nous permet d'améliorer grandement la qualité de nos audits avec des retours très spécifiques et concrets sur la qualité et la performance de l'application.

Les problèmes de performances proviennent presque toujours d'une mauvaise utilisation de la base de données, c'est pourquoi nous avons trouvé un réel intérêt à nous focaliser sur cet aspect de l'application pour l'améliorer au maximum.

Pour tester notre agent Java sur votre projet, n’hésitez pas à nous contacter !