La qualité du code applicatif est un souci constant depuis des lustres. Les ‘bad practices’ de programmation génèrent des défauts qui impactent les utilisateurs et les coûts de maintenabilité des applications. La Dette Technique, simple métaphore à ses débuts, est devenue depuis un outil de mesure de cette qualité et de ces coûts.

Il y a quelques années encore, les logiciels qui permettaient d’identifier ces défauts étaient rares et chers. Aujourd’hui, les outils Open Source tels que Sonar permettent á chacun – équipes de projets, providers, consultants Qualité, etc. – de détecter de manière aisée et à moindre coût ces ‘bad practices’.

Le monde Open Source a longtemps souffert de son image de ‘geek’ parce que ces outils sont d’abord utilisés par des passionnés issus du monde J2EE, technologie majoritaire dans le monde applicatif. Mais les temps changent, et il est maintenant possible d’analyser du code Legacy, tel que Cobol et ABAP avec Sonar.

C’est là l’objectif de notre série de posts : montrer qu’il est possible d’évaluer la qualité d’applications Cobol sans rien connaître du monde Mainframe.

Nous avons vu :

• Les quelques concepts à connaître pour s’asseoir à une table avec des Cobol-ers et savoir quelles questions poser afin de préparer la livraison d’une application Cobol.
• Comment organiser une analyse Cobol avec un Quality profile Sonar.
• Comment définir son propre modèle Qualité et agréger les analyses de différentes applications en une unique View Sonar.

Ces posts ont attisé la curiosité (si j’en juge par le nombre de visiteurs du blog) et attiré nombre de questions concernant le résultat de ces analyses. C’est ce que nous allons voir maintenant : quelles préconisations ou recommandations effectuer sur la base de nos analyses et du tableau de bord Sonar.

Tout d’abord, je ne vais pas effectuer un audit, cela me prend entre 15 et 20 heures pour effectuer un travail un minimum sérieux, et il faudrait un post de 30 ou 40 pages. L’objectif sera de montrer la démarche que j’utilise, et surtout le plus important, comment traduire les résultats en valeur pour nos interlocuteurs, c’est-à-dire en des éléments d’information et de décision.

Nous n’allons pas effectuer une analyse exhaustive des résultats, mais tenter de démontrer à partir de quelques exemples simples comment utiliser le tableau de bord Sonar pour évaluer la qualité du code d’une application.

En préalable, un rappel : nous avons orienté notre modèle Qualité sur la performance et la fiabilité, afin d’identifier les défauts qui risquent d’impacter les utilisateurs. Donc les questions de lisibilité et de maintenabilité des applications ne sont pas notre préoccupation principale. Elles pourraient l’être, mais ce n’est pas le cas, ou en tout cas pas maintenant.

Rappelez-vous : vous n’êtes pas un expert du monde Mainframe mais vous devez démontrer à de tels experts en quoi vos analyses peuvent les aider. Le plus simple pour cela consiste à identifier des défauts graves qui peuvent se corriger facilement, pas à calculer une dette technique qui va se chiffrer en milliers de jours que personne n’a les moyens d’effectuer.

Métriques

Tout d’abord, j’aime savoir à quoi je m’affronte : une mignonne petite application ou un gros monstre affreux, très répandu dans le monde Mainframe. N’oublions pas que la dette technique dans ce monde se mesure en décennies.

Le tableau de bord Sonar nous permet de voir que, parmi les applications analysées, ‘Cobol – Tax’ est l’application la plus volumineuse, suivie de près par ‘Cobol – Big Banking app’. Mais c’est l’application ‘Cobol – Billing’ qui présente la moindre qualité.

Regardons d’un peu plus prés cette application :

Environ 180 000 lignes de code dans moins de 1 400 fichiers : il s’agit d’une application de petite taille. On peut voir que plus de la moitié des lignes se trouve en ‘Data Divisions’, la partie d’un programme Cobol qui permet de définir les données utilisées.

Ceci indique une application orientée ‘données’, probablement une application Batch qui gère des fichiers, par exemple des journaux comptables pour enregistrer durant la nuit les écritures passées sur des comptes en banque. Vous pouvez poser la question à l’équipe Cobol lorsque vous ferez votre présentation. Le plus souvent, je vais jeter un coup d’oeil sur les commentaires dans les programmes afin de vérifier si l’application fait bien ce que je crois qu’elle fait.

La plupart du temps, vos interlocuteurs seront capables de dire si l’application est petite ou importante, complexe ou pas, mais ils ne connaissent généralement pas ces chiffres précisément et ils seront probablement surpris et intéressés lorsqu’ils découvriront la répartition des lignes de code entre les ‘divisions’ dédiées aux données ou aux traitements (Procedure Divisions).

Le niveau de commentaire est faible pour une application Mainframe : la moyenne est plutôt entre 20% (minimum) et 30% (correct). Au moins, ces commentaires se trouvent dans les traitements mais on s’aperçoit qu’il s’agit en grande partie de commentaires ‘blank’ c’est-à-dire vides. De surcroît, nous n’aurons probablement rien pour comprendre les structures de données, pourtant prédominantes dans le code.

Comme on peut le voir, cette application embarque peu de complexité, avec une Complexité Cyclomatique de 17.5 par fichier. Par contre, le nombre de lignes de code dupliquées est très élevé, supérieur à 50%, très certainement à cause des 184 ‘Duplicated files’, soit environ 13% de l’application complète. Quelle est l’origine de ces fichiers dupliqués ? Tout simplement, pour raison de backups. Le monde Mainframe n’est pas le plus avancé en matière de gestion de versions. Le plus simple, lorsque l’on n’est pas sûr de la fonctionnalité que l’on implémente, consiste à mettre le code en commentaires ou plus rapide, à copier le fichier afin d’effectuer l’évolution souhaitée tout en gardant un backup qui permette un éventuel retour arrière.

Message au management : il pourrait sembler tentant au premier abord d’outsourcer cette application car :

• Sa taille réduite implique des coûts d’outsourcing peu élevé.
• Elle est peu complexe donc facile à comprendre.
• Une application batch est rarement une application critique, donc le risque de dépendance vis-à-vis de l’outsourceur est réduit.

Néanmoins, un faible niveau de commentaires équivaut à un transfert de connaissances plus difficile et plus de temps – et donc d’argent – pour le provider qui accepterait un tel outsourcing. De plus, le pourcentage élevé de code dupliqué signifie plus de travail – et donc d’argent – pour répercuter chaque modification sur les blocs de code copié-collé.

Un outsourceur ne peut pas se permettre de perdre de l’argent, donc ces tâches supplémentaires diminueront d’autant le temps imparti pour effectuer la maintenance. Il n’est pas souhaitable de confier ce code à un prestataire sans un travail de refactoring préalable afin de supprimer les fichiers dupliqués et redocumenter cette application, notamment en ce qui concerne les données en fichiers.

La suite dans notre prochain post, qui portera sur les violations rencontrées et nos recommandations finales.

 

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.