Troisième article de notre série sur la création de métriques personnalisées, et pourquoi la possibilité de définir ses propres métriques dans un outil d’analyse de code n’est pas le critère important que tout le monde croit.

Nous avons vu dans le premier article que les métriques les plus simples à créer n’étaient pas les plus nombreuses et dans le second de cette série que les métriques les plus intéressantes et importantes étaient également les plus complexes à implémenter, voire même parfois (ou souvent) impossibles à réaliser.

Dans ce dernier post, nous allons aborder cette question de personnalisation sous l’angle des technologies applicatives, avant un dernier article qui nous servira à résumer le tout et à identifier les bonnes questions.

Métriques personnalisées et technologies

Quand on me demande s’il est possible de créer des métriques avec tel ou tel outil, je réponds ‘Pourquoi faire ?’. Le plus souvent, vous n’obtiendrez pas de réponses très précises, ce qui n’est évidemment pas bon signe quant à l’existence d’un besoin réel.

La question plus précise est en fait : ‘Pour quelles technologies ?’.

Java

Java reste le langage le plus utilisé dans les entreprises, celui pour lequel existe le plus d’applications. Les bonnes pratiques de programmation sont bien connues, normalisées et nombreuses. Bien sûr, il existe des débats de puristes pour savoir si l’usage de telle ou telle instruction constitue ou non une violation à une bonne pratique, mais soyons sérieux, tout le monde est d’accord sur les métriques les plus importantes à vérifier.

Les règles correspondantes existent depuis longtemps dans nombre d’outils, au point que les plus connus s’intègrent assez facilement (SonarQube sait travailler avec Findbugs, PMD, Checkstyle par exemple). En fait, il existe tellement d’outils qui incorporent tellement de règles que vous avez la possibilité de spécialiser celles-ci selon vos priorités, et les objectifs qui vous sont fixés :

• Applications nouvelles et critiques : vous souhaitez partir à la chasse aux bugs potentiels afin de délivrer des applications robustes et performantes, et limiter les problèmes pour vos utilisateurs.
• Applications anciennes et éprouvées : quelques problèmes et retards sur la nouvelle version ne sont certes pas souhaitables, mais votre priorité – et ce sur quoi vous êtes jugés – est de contrôler les coûts de maintenance et de ne pas exploser votre budget. Vous privilégiez les bonnes pratiques de programmation qui impactent la maintenabilité de vos applications.

Donc, si vous m’avez bien compris, il n’y a aucune raison de vouloir programmer ses propres règles en matière de Java, sauf à vouloir se faire plaisir bien sûr, et jouer à l’apprenti-gourou.

Autres nouvelles technologies

Par autres nouvelles technologies, j’entends les langages autres que Java : C++, C#, .NET, etc. Je dois dire que je ne suis pas un spécialiste de ces langages, mais j’ai quand même analysé quelques applications de ce type (pas mes préférées je dois dire), et je sais que la plupart des règles de qualité applicative sont assez proches de celles qu’on trouvera en Java. Je veux dire : un IF est un IF et une boucle est une boucle, donc nous allons retrouver les mêmes bonnes pratiques de structuration de code par exemple. Ensuite, il y a toujours dans tous les langages certaines instructions spécifiques qu’il n’est pas recommandé d’utiliser.

Je pense d’ailleurs que l’offre en matière d’outils et de ‘repository’ de règles est de plus en plus abondante et de qualité pour ces langages. Donc les principes précédents concernant la customisation de règles Java restent selon moi applicable : ne pas réinventer la roue.

Frameworks

En fait, il existe un unique cas acceptable selon moi : les frameworks ‘maison’. Imaginons que vous travaillez dans le cadre d’une architecture SOA, avec un middleware développé et maintenu en interne, et encapsulant des appels à des requêtes ou traitements Mainframe-Cobol ou d’un ERP quelconque. Il est bien évidemment souhaitable que tout le monde utilise le framework et que personne ne développe ses traitements de son côté.

Car le jour où le programme appelé sur la couche SOA et les paramètres d’appels à celui-ci sont modifiés, le framework – les APIs pour ce programme – seront également mis-à-jour et les applications pourront continuer de fonctionner. Mais si quelqu’un a fait son petit programme dans son coin, il faudra identifier celui-ci et le modifier (ou le réécrire en utilisant le framework). En admettant que l’on se souvienne de son existence, que son auteur soit encore dans les parages, etc.

Autre cas pas si inusuel que cela : c’est incroyable le nombre de sociétés qui ont développé leur propre version de frameworks Struts ou Hibernate. Ok, la plupart sont des sociétés de services qui ont utilisé ces frameworks propriétaires dans le cadre de développements d’applications pour leurs clients, et s’assurer ainsi des contrats de maintenance à vie pour ces applications. Ou alors, il faut réécrire celles-ci sans le framework. J’ai vu des portfolios Java avec jusqu’à 3 ou 4 frameworks propriétaires différents.

Donc dans ce cas, il est acceptable de supporter le coût de personnalisation de métriques pour un framework personnalisé, afin de s’assurer que celui-ci est bien utilisé. Encore faut-il que lesdites règles soient possibles à implémenter. Comment identifier qu’un traitement n’utilise pas les instructions ou les objets d’un framework alors qu’il le devrait ? Dans le meilleur des cas, il vous faudra identifier toutes les instructions qui vont accéder à une couche (SOA dans notre exemple précédent, couche de données pour un framework type Hibernate, etc.), et que ces instructions se trouvent dans du code ‘développeur’ et non pas du code du framework, ou du code du framework instancié par le développeur, etc.

C’est horriblement compliqué, et il vous faudra travailler au niveau de l’arbre syntaxique (Abstract Metric Tree), en disposant encore une fois des outils et des compétences nécessaires. Le coût de création et de maintenance de ces règles sera assez voire très élevé.

Même le coût d’utilisation de ces métriques personnalisées peut s’avérer important, en cas de false-positives, toujours probables. Je me souviens d’un métrique qui devait vérifier que chaque JSP ou chaque page Html devait être associé à un page d’erreur. Mais la relation avec cette dernière n’était pas toujours directe, et passait parfois par un objet Struts, parfois par un composant spécifique à la gestion des erreurs, etc. La première chose que je faisais était d’aller voir cette métrique car je n’ai jamais autant rencontré de false-positives que sur celle-ci. Et évidemment, si vous annoncez à une équipe Java qu’elle gère mal les erreurs alors que l’erreur, c’est vous qui la commettez, … hum hum.

L4G

Par L4G (langage de 4ème génération), j’entends tous les outils de type client-serveur qui fleurissaient dans les années 80 et 90 : les SqlWindows, Powerbuilder, Delphi, NS/DK (en France), etc.

Il reste encore quelques applications avec ces langages, trop volumineuses pour qu’on pense à les ré-écrire, même si on en parle régulièrement mais que cela ne se fait jamais. Après tout, si cela marche…

Il existe assez peu d’outils d’analyse de code qui couvrent ces outils, et pas suffisamment d’applications et donc de clients pour que cela vaille la peine d’investir pour la plupart des éditeurs logiciels. En général, ces clients ont déjà suffisamment de problèmes à pouvoir vérifier les règles les plus basiques et la customisation de nouvelles règles n’est pas une priorité.

La seule exception – toutes proportions gardées – réside peut-être dans un langage comme Oracle-Forms qui reste assez utilisé. Cela dépend un peu de quel coin du monde on parle, je suis toujours étonné de voir à quel point certains outils sont très utilisés dans certains pays et pas du tout dans d’autres régions du globe. Mais il reste encore pas mal de portfolios très volumineux et critiques d’applications Forms. Cependant, leurs propriétaires, comme précédemment sont le plus souvent satisfaits de pouvoir disposer de bonnes métriques avant de penser à developper les leurs.

Cobol

Le Cobol est un des langages les mieux normalisés avec Java. C’est logique, si l’on considère que Sun, à l’origine de Java, et IBM, principal fournisseur de hardware et de logiciels du monde mainframe, se sont souciés de mettre à disposition nombre de publications en matière de qualité de code. Donc les règles en ce domaine sont bien connues et normalisées et il est rare d’en déroger. Dans le pire des cas, une règle n’est pas appliquée par une équipe de projet, et sera désactivée dans l’outil d’analyse de code.

Il est m’est arrivé une ou deux fois de rencontrer une société qui avait défini une règle spécifique qui ne correspondait pas à une norme existante. Par exemple : vous savez qu’un programme Cobol va se décomposer en sections et surtout paragraphes, équivalents de procédures ou fonctions réutilisables au sein du même programme. Un client avait édicté une règle selon laquelle il n’était pas possible d’appeler un paragraphe si celui-ci n’avait pas été déclaré et codé précédemment (avant l’appel). La règle se justifiait, et même si personne d’autre ne l’utilisait, il était possible de l’implémenter avec une RegExp. Et le client insistait, donc…

SAP

Cas inverse du précédent. SAP n’a jamais été un spécialiste de la qualité de code. La priorité, c’est de vendre de nouvelles versions, pas de stabiliser du code ABAP existant. Il est même arrivé que SAP préconise l’emploi d’instructions qui représentent un risque pour la performance ou la robustesse de l’application.

Donc beaucoup pour ne pas dire toutes les entreprises avec des programmes ABAP disposent d’un cahier de bonnes pratiques de programmation. On y retrouvera souvent les principales normes existantes, mais pas toujours sous la même forme. Par exemple, une règle édicte de toujours utiliser et tester un code-retour après l’appel à un autre traitement. Mais parfois, cette règle définira précisément quel code-retour correspondra à quelle situation (0 = pas d’erreur, 1 = erreur de tel type, … X = erreur de type X, …). Dans un tel cas, il vous faudra probablement développer une métrique plus avancée que celle déjà existante, qui vérifie non seulement la présence d’un code-retour mais aussi sa valeur.

Vous aurez également des normes importantes qui ne seront pas présentes dans un cahier de règles, et il vous faudra vérifier avec votre client si elles présentent un intérêt pour lui. Il sera souvent à l’écoute, mais pas forcément intéressé à modifier les règles existantes. C’est normal : il va devoir expliquer à tous ses outsourcers que cela fait des années qu’ils travaillent mal sans que personne le sache puisque ces règles n’étaient pas utilisées. Et c’est également dans le monde ABAP que vous allez rencontrer le plus de règles très complexes ou impossibles à automatiser.

Donc en résumé :

• Java et nouvelles technologies : sauf à vouloir jouer au petit chimiste fou en inventant ses propres recettes, il est difficile de justifier la nécessité de nouvelles métriques, sauf si …
• Framework : mais attention, le coût de développement, de maintenance et même d’utilisation de métriques personnalisées pour un framework propriétaire sera élevé, très élevé.
• Autres langages type L4G : peu ou pas de demande.
• Cobol : pareil, mais vous aurez souvent à effectuer un travail de personnalisation du modèle qualimétrique. Sur ce sujet, voir le post suivant votre propre modèle qualité.
• SAP : ABAP est probablement le seul langage pour lequel la personnalisation de règles peut se justifier. Par contre, toutes ne sont pas automatisables, et la plupart sont complexes à implémenter.

Dans tous les cas, la création de nouvelles métriques représente un coût souvent plus élevé qu’on ne le croit. Le prochain article nous permettra d’identifier quels sont les coûts cachés et résumer l’ensemble des questions à se poser afin d’évaluer au mieux le besoin réel et le retour sur investissement.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.