Nous avons vu précédemment les défauts bloquants ou ‘Blockers’, ainsi nommés car aucune violation de ce type ne peut se tolérer, et les défauts critiques ou ‘Critical’, suffisamment graves pour nécessiter une correction immédiate, mais pour lesquels une exception peut – et doit absolument – se justifier.

Dans notre Quality Profile SONAR, les ‘Blockers’ portent sur tout ce qui peut interrompre une transaction ou un programme et les ‘Critical’  sur des pratiques de programmation qui présentent un risque pour la performance.

Nous allons terminer cette série sur les bonnes pratiques de programmation ABAP avec les règles restantes, qui vont concerner principalement la maintenabilité du code. Continuer la lecture →

Nous avons vu dans le post précédent les violations les plus graves aux bonnes pratiques de programmation ABAP.

Ces défauts sont bloquants : le code correspondant ne peut aller en production tant qu’une correction n’est pas effectuée. Aucune exception n’est permise : tolérance zéro, car le risque est trop élevé de voir une transaction interrompue et l’utilisateur incapable d’effectuer le traitement souhaité. Continuer la lecture →

Après une interruption due à la réorganisation du blog – j’espère que vous appréciez la nouvelle interface – nous reprenons la série sur l’analyse de code ABAP.

Nous avions vu la dernière fois comment paramétrer notre première analyse de code ABAP, avec Sonar et Jenkins.

Cette semaine, nous allons examiner les premières règles ABAP, tout au moins les plus critiques en matière de bonnes pratiques de programmation. Continuer la lecture →

Après avoir vu dans le post précédent comment récupérer le code ABAP à analyser, à l’aide de l’extracteur fourni par Sonar, nous allons procéder à notre première analyse… mais pas avec le code que nous avons extrait.

En effet, la première fois que je vais paramétrer une analyse pour une nouvelle technologie, je vais effectuer un premier essai avec du code dont je suis certain qu’il ne pose pas de problèmes, du code déjà testé et éprouvé par Sonar, et téléchargeable depuis cette page : Sonar Project Examples.

Cette page renvoie vers d’autres pages au sein desquelles vous pouvez naviguer pour découvrir différents exemples de projets ou simplement clicker sur le lien qui permet de télécharger un fichier compressé.

Continuer la lecture →

Nous continuons notre série de posts sur l’analyse de code ABAP avec Sonar. Aujourd’hui, l’étape préalable à l’analyse : l’extraction du code.

Nous avons vu dans le premier article Sonar & ABAP – Ce qu’il faut savoir, que le code ABAP est stocké dans le workbench SAP, et donc nous allons devoir installer un programme dans ce workbench afin d’extraire le code à analyser et le transférer sur note plate-forme d’analyse Sonar.

Oui, il va nous falloir nous connecter au workbench, afin d’installer et exécuter ce programme. Continuer la lecture →

Nous continuons le post précédent sur les questions à poser afin de préparer la mise en place d’un processus d’analyse de code ABAP, dont nous avons vu que celui-ci reposait en grande partie sur les cas d’utilisation.

J’ai donc invité Walter, Directeur Qualité de Drago Solutions, qui nous accompagne depuis le début de cette série d’articles, à répondre à quelques questions sur ce sujet. Continuer la lecture →

Nous poursuivons notre série sur l’analyse de code ABAP.

Nous avons vu dans le post précédent ce que vous devez savoir sur la technologie SAP et sur le code ABAP.

Nous allons maintenant lister les questions à poser aux équipes de projet afin de préparer l’extraction du code et l’organisation des analyses dans le tableau de bord Sonar. Continuer la lecture →

Après avoir débuté, dans le post précédent, cette série qui traite de l’analyse de code ABAP, avec l’aide de Walter, Directeur Qualité de Vision IT et spécialiste des environnements SAP, nous allons voir aujourd’hui ce qu’il est nécessaire de connaître pour implémenter un processus d’analyse de code ABAP avec Sonar. Continuer la lecture →

Mon blog Qualilogy a bientôt un an (á la fin du mois), et s’il n’est pas encore l’heure de faire un bilan, je constate que la quasi totalité des posts que j’ai rédigés portent sur la qualité du code et des applications et s’adressent majoritairement à deux types de publics :

• Ceux qui connaissent bien les concepts de la Qualité, les différentes métriques et leur utilisation, souvent au-delà du domaine de la qualité de code. Ce sont souvent des consultants ou des responsables Qualité, avec généralement l’expérience de diverses technologies et langages, capables d’interpréter un tableau de bord et de faire des audits. Cependant, ils ne sont pas tous expérimentés en matière d’utilisation d’outils d’analyse de code, et considèrent parfois que le monde J2EE et les outils Open Source restent trop techniques pour eux.

Je me suis attaché à montrer que c’est en fait très simple, même sans connaissances techniques, à travers plusieurs articles décrivant l’installation et l’utilisation des outils Sonar et Jenkins, et les bénéfices des nombreux plugins créés et maintenus par la communauté Sonar.

• Ceux qui au contraire sont utilisateurs, voire experts, dans l’utilisation de ces outils, qu’ils mettent en œuvre chaque jour sur leurs projets ou sur le portefeuille d’applications J2EE de leur entreprise, mais n’ont pas la l’expérience d’autres technologies. Alors qu’en fait, il suffit d’un minimum de connaissances pour analyser du code autre que J2EE.

Voir par exemple, la série Cobol qui débute par ce post Analyse de code Cobol – Ce qu’il faut savoir.

Comme j’avais pour projet de réaliser une série du même type pour la technologie SAP, j’ai demandé sa participation à quelqu’un qui n’est pas seulement un ami, mais également expert dans le domaine de la qualité et du monde SAP et de l’utilisation des outils d’analyse de code. Continuer la lecture →