AXA expose sa démarche de « green coding »
Comment limiter l’empreinte environnementale du code ? L’équipe tech d’AXA entreprend de communiquer sur ses pratiques dans ce domaine.
Lors d’une itération, vaut-il mieux utiliser $i++ ou ++$i ? D’un point de vue « green coding », la deuxième option est plus efficace : elle ne génère pas de variable temporaire.
Cette règle figure, comme une quarantaine d’autres, dans la matrice de référence d’ecoCode.
À la genèse de ce projet, il y a une entreprise aquitaine (Snapp, agence de développement d’applications mobiles), en association avec le laboratoire informatique de l’université de Pau et des pays de l’Adour.
À l’arrivée, il y a une extension pour le logiciel SonarQube (qualimétrie du code). Elle implémente les règles en question sous la forme d’analyseurs statiques. Cinq langages sont pour le moment couverts : Java, PHP, JavaScript, Python et Rust.
ecoCode est un chantier en cours. Le niveau d’intégration de la « règle du $i++/++$i » l’illustre : c’est fait pour Java et PHP, mais pas encore pour JavaScript. Autre exemple : l’usage déconseillé de try-catch-finally pour gérer les exceptions (O.K. sur PHP ; à venir sur Java, JavaScript et Rust).
ecoCode dans la boîte à outils d’AXA
Chez AXA, on préfère try-with-resources à try-catch-finally. L’équipe technique vient d’en faire part dans un billet censé inaugurer une « série green coding ». Ayant prévu de consacrer un article aux outils qui soutiennent ses démarches, elle ne les aborde pour le moment qu’en substance. On sait toutefois qu’ecoCode en est un pilier, pour l’analyse pendant le développement.
Lors de l’exécution, VisualVM, notamment, entre en jeu. Il est dédié aux applications Java… et cela va dans le sens du billet d’AXA : l’équipe technique y donne des exemples de « green coding » dans ce langage. Entre autres :
– Pour un calcul de factorielle, privilégier un code itératif à un code récursif, qui n’est pas efficace avec de grandes valeurs
– Concaténer des chaînes de caractères avec la classe String Builder plutôt que directement
– Lors de l’initialisation de collections, préciser la taille au départ, pour empêcher le redimensionnement
– Pour certaines collections, utiliser les itérateurs plutôt qu’une boucle for-each
La réflexion d’AXA touche aussi à l’optimisation de l’usage des ressources. Par exemple avec le multithreading ou le traitement en flux. Elle englobe également la gestion du code en production : réduction des communications réseau, utilisation du mode économie de batterie, stratégies de déduplication et de mise en cache…
Photo d’illustration © Seventyfour – Adobe Stock
