Je suis toujours surpris par les comparatifs d’outils d’analyse de la qualité d’une application qui prétendent définir les critères d’un tel choix, alors que la seule réponse exacte á cette question est que ‘cela dépend’.

Si vous souhaitez acheter une voiture, vous allez bien sûr effectuer votre choix selon un certain nombre de critères qui vont dépendre de l’usage auquel vous destinez votre véhicule. Un coupé décapotable ou une voiture de sport sont des objets certes séduisants mais peu pratiques s’il s’agit de transporter votre famille nombreuse, faire vos courses chez Carrefour, naviguer dans les dunes avec votre planche à voile ou déménager votre vieille tante.

Il en va de même en matière de sélection d’une plateforme d’analyse de la qualité des applications.
Ce post n’a donc pas pour but de définir les 8 critères ultimes de choix d’un tel logiciel, sinon de lister 4 critères souvent rencontrés et (dans le prochain post) 3 critères auxquels on ne pense pas assez. Oui, je sais, le compte n’est pas bon. En fait, le dernier critère, le coût logiciel, sera traité à part.

Nombre de technologies analysées

C’est pratiquement toujours le premier critère de la grille de sélection. Je ne comprends pas pourquoi un outil capable de couvrir 20 langages serait supérieur à celui qui n’en analyse que 5, dès lors que l’un comme l’autre sait analyser le code de vos applications. Aujourd’hui, 50% des applications sont en J2EE et 25% de type Legacy (Mainframe Cobol / SAP). Cela varie plus ou moins selon les pays : certains continents sont plus Microsoft que d’autres, avec un taux de C++ et de .Net plus élevé. Cela varie également selon les secteurs : les banques et les assurances arrêtent de fonctionner demain si Cobol disparaît.

Les éditeurs logiciels le savent bien : ils vont donc centrer leurs efforts sur les technologies les plus rencontrées chez leurs clients et ne vont pas investir sur Powerbuilder ou Delphi.
A moins que vous ne soyez parmi les plus grandes et/ou les plus anciennes entreprises de votre secteur, que vous ayez accumulé les strates technologiques au fil des années, que vous ayez fusionné avec d’autres sociétés, ou que vous ayez souvent changé de stratégies de développement, il est probable que vous ayez plus de 75% de votre portefeuille applicatif sur 2 ou 3 technologies différentes. Et fort probablement J2EE / Cobol / SAP. Et très certainement la partie la plus critique, le cœur de métier de votre entreprise.

Sortez de votre liste de sélection les outils qui ne couvrent pas vos applications. Pour les outils restants, vérifiez dans le détail – á l’aide d’un pilote par exemple – la qualité des analyses réalisées. Vous n’avez que faire des autres langages : cela constitue une simple information, pas un réel critère de choix.

Nombre de métriques

Comme pour le point précédent, centrez vous sur la qualité et la valeur des métriques proposées plutôt que sur leur nombre. C’est bien d’avoir 20 règles de nommage pour tous les types d’objets que comptent vos applications, mais cela ne vaut pas une métrique qui va couvrir un défaut grave de programmation avec un risque important de voir l’application s’arrêter ou provoquer une corruption de données.

Identifiez les 10 à 20 métriques sur lesquelles vous :

• Validez la livraison d’une application (Quality Gate).
• Vérifiez les SLAs de vos providers.
• Faites reposer les process de Continuous Integration / Improvement de vos équipes de développement.

Dans mon expérience, le nombre de métriques ne jouera un rôle que dans deux cas bien précis :

1. Le calcul de la dette technique (nous aurons l’occasion d’y revenir).
2. L’audit de la qualité d’une application que l’on va ‘acquérir’ (reprise de maintenance par exemple) ou afin d’identifier un problème particulier (souci de performance par exemple).

Mais même dans ce dernier cas, il est bien rare de découvrir exactement le bug en question ou un défaut spécifique á l’aide d’une métrique particulière. De plus, ce cas correspond à un contexte de consulting et non pas d’acquisition d’un outil logiciel.

Construisez la liste des bonnes pratiques indispensables pour vos applications : ce sont des standards disponibles sur le marché et normalement la plupart des outils devraient les intégrer. Dans le cas contraire, c’est que le produit est probablement encore un peu jeune sur cette technologie.

Recensez ensuite les métriques intéressantes mais non indispensables, en fonction des cas d’utilisation que vous souhaitez mettre en place. Le reste est du ‘nice to have’.

Possibilité de créer de nouvelles métriques

Alerte : critère dangereux.
Un principe de base en informatique : si c’est disponible, vous allez l’utiliser. S’il est possible de le faire, vous allez le faire. Même si vous n’en avez pas besoin.

Vous vous rappelez cette boîte de ‘petit chimiste’ qu’on vous avait offert á Noël, sous prétexte de ce qu’il s’agissait d’un jouet éducatif destiné á éveiller vos instincts scientifiques ? Qui aurait deviné que vous alliez finalement jouer au savant fou á la recherche du mélange le plus détonant de substances diversement colorées.

Le même syndrome se rencontre parfois, chez certains architectes ou responsables Qualité qui reconstruisent ISO 9216 avec leur propre modèle et leurs propres métriques. J’ai souvent vu de telles tentatives abandonnées au bout de 2 ou 3 ans, tout simplement parce que le bénéfice de telles customisations est inférieur aux coûts de développement et de maintenance. Dans le monde Open Source, il est possible que vos nouvelles métriques soient incorporées au sein de l’outil par la communauté. Dans le monde propriétaire, oubliez çà. Il vous faudra porter votre propre modèle tout seul, à chaque upgrade logiciel.

Il existe peu de cas où la nécessité de créer de nouvelles métriques se justifie, principalement lorsqu’il n’existe pas de standards bien définis sur le marché. Cela peut arriver pour quelques rares technologies. Sinon, c’est que l’éditeur logiciel n’a pas intégré les règles correspondant aux bonnes pratiques. Soit vous l’écartez de la liste, soit vous travaillez avec lui pour qu’il incorpore ces règles dans une prochaine version.

Dans tous les cas, mesurez bien le coût que représente le développement de nouvelles métriques et vérifiez bien le besoin. Keep It Simple, ne jouez pas les alchimistes.

Liens entre composants

Certains acheteurs d’un outil d’analyse de code présentent une attitude bien curieuse : ils cherchent à piéger ceux qui leur proposent une solution. « Voyons voir s’ils savent trouver les appels dynamiques entre les couches de mon framework propriétaire ». « Ne disons rien : seront-ils capables d’identifier les liens entre ces composants ?».

Si vous avez un besoin particulier, si vos applications utilisent un mécanisme spécifique, exposez le clairement. Bon nombre de sociétés de service ont créé leur propre version de frameworks Struts ou Hibernate et leurs clients sont maintenant pieds et poings liés avec des composants absolument pas standards. Dans certaines applications Cobol, les programmes, les JCLs et même parfois les transactions CICS ne sont pas appelées directement, mais á travers une table de codification de ces liens.

La plupart des métriques identifient des violations de bonnes pratiques de programmation. En d’autres termes, elles repèrent les syntaxes incorrectes ou incomplètes ou la structuration incorrecte de diverses instructions. Les bonnes pratiques d’architecture ne s’appuient pas sur une syntaxe particulière mais sur les liens entre différents composants au sein de différentes couches de l’application.

Je vois principalement deux intérêts á un outil d’analyse de code qui sait déceler ces liens :

• Réaliser des analyses d’impact : on sort là du domaine de la qualité de code pour rentrer dans celui des outils de rétro-documentation ou d’aide á la migration.
• Vérifier le respect des règles d’utilisation de frameworks, propriétaires ou non.

Je pense que ce second point présente un intérêt véritable. Par exemple, lorsque que vous centralisez l’accès à la couche de données sur quelques composants, ou lorsque tous les objets de la couche de présentation passe par un unique composant pour accéder á la couche de logique métier, vous appréciez de pouvoir recenser les objets qui ne respectent pas cette règle. Parce que la prochaine modification sur l’une de ces couches risque de ne pas être répercutée sur ces objets.

Par contre, cette fonctionnalité n’est véritablement nécessaire que pour les architectures 3-tiers, donc J2EE et .Net principalement. De plus, en cas de frameworks et de bonnes pratiques propriétaires, il vous faudra compter sur un coût de customisation.

Aussi, ces métriques sont celles qui présentent le plus grand nombre de false-positives et nécessite le plus de validations. Il est (relativement) facile de vérifier qu’une syntaxe particulière est respectée ou non, donc les métriques correspondant aux bonnes pratiques de programmation sont généralement fiables. Une métrique qui vérifie les appels entre certains types ou certaines nomenclatures de composants sera beaucoup plus sensible au contexte applicatif et peut nécessiter une vérification systématique des liens après chaque analyse. Pour un coût de mise en œuvre plus important donc.

Enfin, vous rencontrerez probablement une proportion de 1 á 10 entre ces différents types de règles, c’est á dire que les métriques de bonnes pratique d’architecture ne représenteront pas plus de 10% de l’ensemble des règles proposées par l’outil. Et toutes ne seront pas critiques.

Donc encore une fois, vérifiez bien l’adéquation, et le coût, à votre besoin. L’outil le plus complet n’est pas forcément celui qui vous conviendra le mieux.

Inutile d’acheter un Hummer pour faire vos courses en ville : quand vous vous rendrez compte des efforts pour le manœuvrer et le temps perdu á chercher à vous garer, vous risquez vite de le laisser au garage.