Pourquoi l’analyse statique du code concerne également les managers ?

Ring ring, le téléphone sonne. A l’autre bout c’est un client qui se plaint car une page de son site affiche constamment une erreur 500.

Après un simple coup d’œil vous voyez que la cause l’erreur est qu’une variable a été accédée alors qu’elle était « null ». Déjà vu ?

Si vous voulez réduire le nombre de problèmes d’exploitation tout en améliorant la qualité du code, une solution est bien la relecture du code par un collègue mais si votre application existe depuis longtemps (ce qui s’appelle souvent « legacy ») elle remonte, peut-être à une époque où la relecture n’était pas à la mode et donc pas faite du tout sur une partie de code pas négligeable.

La relecture du code, aussi dite « revue du code », est une activité normalement exécutée par un autre développeur qui peut demander beaucoup de temps et qui donc coûter cher.

D’ailleurs, la relecture du code faite par un humain peut être intégrée par une relecture du code menée par un logiciel qui, même si il est moins malin d’un développeur, ne se s’épuise jamais, ne se trompe pas, ne part jamais en vacance et que dans l’espace de quelques minutes peut créer des rapports sur un certain nombre d’axes de qualité d’un logiciel.

Si vous souhaitez une aide pour gérer des très nombreuses classes d’erreur qui pourraient affecter votre application lamba, alors un système d’analyse statique est ce qu’il faut dans votre usine à développement. Le but de cet article n’est pas de vous adresser vers un outil ou l’autre (il en existe beaucoup payants ou gratuits et pour presque tous les langages de développement : Java, .NET, PHP, JavaScript, …) mais plutôt de démontrer les avantages d’un point de vu de l’architecte ou du technical lead ou du manager. Oui parce que s’il est vrai que pour un développeur l’intérêt principal est de relever les erreurs potentielles introduites par ses dernier commits,  il est aussi vrai que l’évaluation, la classification des bugs et la planification de leur corrections sont des armes encore plus puissantes si exploitées par un les acteurs qui ont le moyen de corréler ces problèmes au fonctionnel le plus touché et le rôle de décideurs.

Les types défauts qui pourraient retomber sur votre entreprise si votre logiciel les présente :

  • Sécurité (des données sensibles peuvent être volées)
  • Performance (l’application peut résulter lente sous certaines conditions pas encore rencontrées)
  • Problèmes de design, manque de réutilisabilité du code, code non documenté (coûts de développement qui dépassent toute attente)

Pas besoin de baguettes magiques pour gérer le risque, c’est une capacité que les manager ont déjà. Ce qu’ils n’ont pas forcément c’est une synthèse de données sur laquelle baser ses propres décisions. Avec des bonnes données il devient beaucoup plus facile de comprendre l’état de santé d’un projet, de décider de corriger telle ou telle zone avant la mise en production, d’intégrer des nouvelles ressources ou à la limite de décaler la livraison.

Sedona utilise des outils d’analyse statique dans ses projets et peut emmener l’expertise nécessaire à leur exploitation aussi dans les entreprises qui veulent s’en servir.

You may also like...