Nous poursuivons aujourd’hui notre évaluation de la qualité du code Cobol analysé avec Sonar.
Dans le post précédent, nous avons étudié les métriques mesurant la taille du code, sa complexité, le niveau de documentation et de duplication, ce qui nous a permis de formuler quelques premières préconisations aux responsables de cette application. Continuer la lecture
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. Continuer la lecture
Une règle est connue ou elle ne l’est pas. Une ‘best practice’ est appliquée ou ne l’est pas. Mais si elle n’est pas appliquée, serait-ce parce qu’elle n’est pas applicable ?
Vous devez présenter les résultats de vos premières analyses Cobol et bien sûr, vous souhaitez que ceux-ci soient les plus pertinents possible afin de prouver la valeur de ces analyses aux équipes de projet, providers, stakeholders, etc.
Ceci suppose de définir un modèle qualimétrique – un ensemble de règles et de niveaux de criticité de celles-ci – qui permette d’identifier rapidement les ‘bad practices’ les plus coûteuses et les plus dangereuses. Evidemment, vous devez éviter de dénoncer comme défaut grave une violation à une ‘best practice’ qui n’est pas en vigueur– par exemple, l’utilisation de code SQL (cf. notre dernier post).
Quelles sont les règles applicables ou non ? Quels seuils de criticité choisir ? Comment ajuster le modèle qualimétrique en un Quality profile Sonar pour nos applications Cobol ?
Nous allons montrer dans ce post comment définir votre propre modèle Qualité, à l’aide d’une View Sonar et d’un widget bien utile. 
Continuer la lecture
Les précédents posts sur la préparation et l’analyse de code Cobol avec Sonar et Jenkins ont attiré quelques commentaires impatients au sujet du résultat des analyses et des règles disponibles dans le dashboard Sonar.
Ces résultats permettent-ils une évaluation de la qualité des applications Cobol ? Quelle valeur pouvons-nous délivrer aux équipes, aux partenaires et au management ? Et pour ceux qui ne sont pas familiers du monde Mainframe, quelles sont les ‘best/bad practices’ en matière de code Cobol ?
Beaucoup de questions, et nous n’allons pas pouvoir répondre á toutes en un seul post. Celui-ci sera donc dédié à la présentation de différentes règles et défauts de qualité, fréquemment rencontrés dans les applications Cobol.
L’objectif est le suivant : vous avez effectué une analyse, les résultats apparaissent dans le tableau de bord Sonar. Et maintenant, par où commencer ? Continuer la lecture
Nous avons vu dans le post précédent comment créer une analyse de code Cobol avec Sonar et Jenkins.
Mais en fait, nous n’avons pas utilisé toutes les régles Cobol existantes dans Sonar. Pourquoi ? Parce que certaines règles sont désactivées car spécifiques à un contexte particulier ou alors nécessitent un certain paramétrage. Par exemple, les règles de nommage ne sont pas standardisées en Cobol, et seront souvent différentes entre différents départements informatiques, voire entre équipes d’un même département.
Il nous faut donc pouvoir gérer différents modéles Qualité, c’est-à-dire différents ensembles de règles selon les projets. Sonar nous offre cette possibilité, grace aux ‘Quality profiles’ qui regroupent les règles actives lors d’une analyse de code.
Nous allons voir, dans ce post, comment créer un nouveau Quality profile comportant toutes les règles Cobol, et l’affecter à un projet existant. Continuer la lecture
Let’s continue our serie about the analysis of Cobol code, with the objective to demonstrate that it is simple and easy to initiate a process of evaluation of the quality of this Legacy code, without being a Mainframe expert.
You already have a platform of code analysis with Sonar and Jenkins. If this is not the case, an earlier serie of posts will explain you how to install these tools:
in our environement.
You are used to analyze Java code or .NET with this platform and you got the idea, or you were asked, to do the same for Cobol applications. The problem: you know nothing of the Mainframe world.
Don’t panic. Our two previous posts explained:
Now is time to implement the process of analysis in our platform Sonar-Jenkins. Let’s play. Continuer la lecture
Nous avons vu la semaine dernière ce qu’il fallait savoir en matière de Mainframe-Cobol, avant de se présenter dans une réunion avec les spécialistes de cette technologie et préparer un processus d’analyse avec Sonar.
Nous allons maintenant examiner les questions à poser afin d’organiser les analyses avec Sonar (que nous verrons dans un prochain article).
Ces questions vous permettront également de préciser les règles de livraison du code source.
J’ai fait quelques posts il y a quelques mois (Sonar – Analyse Cobol avec Jenkins, Open Source & code Legacy) dans le but de montrer que, contrairement à une idée assez répandue, il n’est pas nécessaire d’être un gourou J2EE ou un expert Open Source pour analyser du code Legacy d’applications Cobol (ou ABAP) avec Sonar et Jenkins.
Et je vois pas mal de visiteurs consulter ces pages sur mon blog, ce qui dénote l’intérêt certain pour ce sujet.
Mais quelqu’un m’a dit récemment : « Nous effectuons régulièrement et avec succès des analyses Sonar pour du code J2EE. Nous envisageons également de mettre les applications Cobol dans Sonar et Jenkins, mais je ne connais pas le monde Mainframe ».
Ainsi, ce post (et les suivants) aura pour objectif d’aider à la mise en place d’un processus d’analyse de code Cobol avec Sonar et Jenkins. Continuer la lecture
Cela faisait un moment que nous n’avions pas parlé de Sonar. J’ai été un peu occupé récemment à découvrir de nouveaux territoires (cf. les posts précédents Elasticité des applications, La qualité dans le Cloud) et j’ai donc pris du retard dans la mise-à-jour de de mon environnement Sonar. De surcroît, il y a une nouvelle version 3.0 avec un tas de nouveautés.
Donc et sans plus attendre, le moment est venu d’effectuer un upgrade Sonar. Continuer la lecture
J’ai continué à jouer avec le plugin City Model pour Sonar de eXcentia.
Pour ceux qui ont manqué les épisodes précédents, vous pouvez les trouver ici : City Model, City Model – Nouvelle version, La métrique ABC.
Ce plugin est vraiment très fun. Et tout le monde trouve fantastique une représentation visuelle de son code sous forme d’une cité. Aller à l’essentiel est important lorsque vous devez régulièrement juger de la qualité d’une application. Continuer la lecture