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
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
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
Nous avons vu dans le post précédent comment installer le plugin Sonar pour Jenkins. Il est temps maintenant d’effectuer notre première analyse depuis Jenkins. Celle-ci portera sur le code source Cobol déjà utilisé lors de notre première analyse avec Sonar et le Java Runner. Continuer la lecture