Dette Technique : décryptage des usages des professionnels de l'IT

En ce début d'été, Tocea a mené un sondage auprès de 101 professionnels du développement logiciel sur les outils, processus et moyens qu'ils ont mis en œuvre au sein de leurs équipes pour contrôler et réduire la Dette Technique de leurs applications. Analyse des tendances et décryptage.

Cette période estivale est souvent l’occasion de prendre un peu de recul sur l’année écoulée, faire la rétrospective des succès et échecs, s’inspirer de ce qui se fait ailleurs… Les équipes de développement, n’échappent pas à la règle. Dès lors que l’on parle de Dette Technique et de qualité du code –disciplines finalement assez récentes– tout élément d’analyse issu du terrain est bon à prendre.
Je partage donc ici les résultats d’un sondage mené par Tocea auprès de 101 professionnels IT, mettant en lumière les processus, outils et bonnes pratiques qu’ils ont mis en place pour piloter et réduire la Dette Technique de leurs applications.

Ce sondage, mené auprès de 101 professionnels du développement logiciel, est constitué d’entreprises de tailles et de profils technologiques différents : les équipes entre 6 et 10 personnes sont les plus représentées, avec 29 % à elles seules. Elles sont suivies de près par les équipes de 5 développeurs ou moins. Les équipes de 11 à 100 personnes représentent quant à elles 33% des sondés.
Enfin, notons la présence de grosses équipes, qui comptent plus de 100 développeurs. Ces équipes représentent 11% des sondés.

Côté technologies, la plupart des équipes utilisent le tiercé Java (83 %), SQL (68 %) et Javascript (67 %). Les autres langages les plus couramment cités sont PHP, C#, C/C++, dont l’utilisation oscille entre 16 et 20 %. On observe aussi quelques utilisations sporadiques de COBOL, Ruby, Scala…

Maintenant que le décor est planté, passons au cœur du sujet : comment ces équipes que nous avons interrogées gèrent la qualité de leur code ? Quels outils et processus sont majoritairement adoptés et font de facto office de bonnes pratiques pour piloter et réduire la dette technique de leurs projets ?

L’Open Source domine le domaine de l’analyse de code

Sans surprise, les outils open source sont les plus utilisés : Sonar (39 %), Checkstyle (34 %), Findbugs (33 %), PMD (29 %). Puisque gratuits, ces outils peuvent être rapidement embarqués dans la boîte à outil du développeur, et représentent un premier niveau de maturité nécessaire pour contrôler la qualité du code.

Les outils propriétaires (Cast, Coverity, Scertify, Klockwork…) sont quant à eux utilisés dans 15 % des organisations interrogées. En prolongement de l’utilisation d’outils Open Source, l’outil commercial offre le plus souvent une couverture fonctionnelle plus étendue. En effet, ils permettent d’effectuer des analyses plus évoluées et plus précises, en supportant une plus grande variété de technologies.

Pour approfondir la question, et si vous êtes un lecteur de mes tribunes, je vous invite à (re)lire « Outils d’analyse de code : Pure Player ou Tout en un ? ». Des outils commerciaux comme Scertify permettent aujourd’hui de tirer parti de ces incontournables du monde libre, tout bénéficiant de fonctionnalités d’utilisation et d’analyse plus pointues :

Forte intégration au poste du développeur et à l’Usine Logicielle (via l’intégration continue),
Règles de programmation à forte valeur ajoutée (Hibernate, Spring, Owasp…)

La complexité du code : un élément clé de la dette technique

Les indicateurs impactant le plus fortement la qualité et la dette technique d’une application :

Complexité du code (cité en premier dans 35 % des cas)
Couverture de code / Tests unitaires (22 %)
Copier/coller (16 %)
Conformité aux standards (10 %)
Code mort (9 %)
Taux de commentaire (8 %)

La complexité du code est perçue comme l’indicateur impactant le plus lourdement la qualité d’une application, dans la capacité des développeurs à maintenir et faire évoluer le code. Elle est suivie par la couverture de code par les tests unitaires, citée en premier dans 22 % des cas.

Remarquons que ces deux métriques sont intimement liées : en effet, il est difficile d’avoir une bonne couverture de code sur un code complexe, riche en « if » imbriqués et autres conditions logiques (while, else, switch, for…).

La standardisation des règles de programmation est fonction de la taille de l’équipe

En ce qui concerne la conformité aux règles de programmation, plus une équipe de développement est grande, plus l’impact ne sera jugé comme important. Nous observons d’ailleurs de grandes différences dans la notation de cet indicateur. Au sein d’une petite équipe, la bride est généralement plus souple sur les standards de programmation. A l’inverse, plus l’équipe est étoffée, plus il devient crucial d’assurer une qualité constante sur l’ensemble des projets. Ce besoin de normalisation est d’autant plus prégnant quand les développements sont externalisés en Inde, Roumanie, Maroc…

L’intégration des outils d’analyse aux processus de développement est un point clé

Près des deux tiers des personnes interrogées utilisent des outils dont le contrôle est intégré à leur processus : que ce soit via le processus d’intégration continue (Maven, Jenkins, Continuum) ou directement dans l’IDE (Eclipse, NetBeans, VisualStudio…). Parmi les autres personnes interrogées, 19 % utilisent des outils nécessitant une action manuelle et/ou en dehors de l’environnement de développement.

Enfin, 5 % des personnes utilisent des revues de code manuelles. De telles revues sont toujours très pertinentes sur des portions de code complexes, et contribuent fortement à la montée en compétence des juniors. Cependant dans 92% des cas, ces revues manuelles sont couplées à des analyses automatiques. Reste 8% des développeurs qui ne font que des revues manuelles (sic !).

Référentiel commun versus règles spécifiques pour chaque projet

Pour les utilisateurs d’outils d’analyse automatique il est intéressant de savoir comment les référentiels de règles de programmation sont gérés. Ces référentiels contiennent l’ensemble des règles qui vérifient que les bonnes pratiques et les standards de programmation sont respectés.

Trois approches, qui correspondent chacune à un niveau de maturité :

Aucun référentiel commun : On trouve des équipes où les développeurs sont libres de choisir individuellement les règles qu’ils veulent vérifier. C’est un bon point de départ, cependant pour de grosses équipes, cela rend difficile la mise en place d’une consistance de la qualité à travers tous les développements. 25 % des sondés utilisent cette approche
Des règles communes à tous les projets : l’approche suivante consiste à utiliser un référentiel centralisé, commun à tous les développeurs et toutes les applications, dès lors que l’outil le permet. Ceci permet d’avoir un niveau de contrôle qualité homogène sur l’ensemble des projets et pour toutes les équipes. 26 % des personnes utilisent cette méthode.
Cependant, certains projets peuvent nécessiter des règles bien particulières, ou des ajustements en fonction du contexte (applications embarquées, frameworks spécifiques, etc.)
Un socle commun de règles + référentiels spécialisés : en conséquence, le niveau de maturité le plus haut est l’utilisation d’un référentiel centralisé, combiné à des spécialisations pour certains projets. 49% des équipes utilisent ceci.

Développeur recherche activement règles Architectures et frameworks !

L’utilisation majoritaire des outils gratuits open source souligne néanmoins une carence exprimée par les développeurs : certains aspects de la qualité logicielle ne sont pas ou peu couverte par les règles de programmation disponibles. Le sujet le plus demandé est l’architecture : 79 % des personnes interrogées souhaitent disposer de contrôles pour vérifier la qualité de leurs architectures.
Les frameworks Java spécialisés, tels que Hibernate, Spring et Struts sont eux-aussi fortement demandés, avec respectivement 48 %, 59 % et 32 %.

Enfin, 30 % des sondés souhaiteraient des règles relatives à la sécurité, par exemple pour détecter les failles OWASP ou d’autres problèmes de sécurité (comme la spécification JavaSec de l’ANSSI par exemple).

11 à 30 % du temps de développement est alloué à la Dette Technique

Pour conclure, nous avons demandé aux sondés la part de temps allouée à la détection et la correction des défauts de qualité. 38 % des équipes affectent 11 à 20 % de leurs efforts. Une moyenne communément admise et partagée par les spécialistes. Toutefois, on remarque aussi qu’un nombre important d’équipes (25 %) attribuent moins de 10 % de leur temps à cette tâche, ce qui est relativement faible. Peut-être les premiers fruits portés par les méthodes agiles !

Cette part de temps allouée à réduire la qualité du code est d’autant plus efficace quand elle repose sur un processus défini, partagé et adopté par les développeurs, et reposant sur des outils intégrés.