Audit d’une application Legacy en C – Microsoft Word 1.1a (I)

C_Analysis_Word0Microsoft a publié cette semaine le code source de Word 1.1a (1990) via le Computer History Museum : http://www.computerhistory.org/atchm/microsoft-word-for-windows-1-1a-source-code/.

Il s’agit d’une des premières versions de Word for Windows, de Janvier 1991 :
http://blogs.technet.com/b/microsoft_blog/archive/2014/03/25/microsoft-makes-source-code-for-ms-dos-and-word-for-windows-available-to-public.aspx.

Je me suis amusé à analyser le code source de cette version. J’étais curieux de voir quels seraient les résultats tant d’un point de vue quantitatif – nombre de lignes de code, niveau de complexité, etc – que qualitatif : violations aux bonnes pratiques de programmation, défauts de type Blockers, Criticals, etc. Lire la suite

Résultats Qualilogy 2013

Qualilogy_Results2013Les résultats de l’annuelle ‘SonarQube 2014 unofficial survey’ sont parus : http://onlysoftware.wordpress.com/2014/02/03/sonarqube-2014-unofficial-survey-results/

Son auteur, Patroklos Papapetrou, est un SonarQubiste distingué et très compétent, puisque co-auteur de la bible « SonarQube In Action ».

Comme j’ai remarqué des différences notables avec mon blog, notamment dans l’origine géographique des participants à cette enquête, j’ai décidé d’effectuer quelques statistiques concernant la fréquentation de Qualilogy pour l’année 2013.

Je sais à peu près quelles sont ces tendances puisque je suis assez régulièrement ces chiffres, mais je n’avais pas effectué de récapitulatif sur toute une année. Ce sera donc l’objet de ce post. Lire la suite

Analyse PL/SQL avec SonarQube – Evaluer la qualité (3/3)

PLSQL_TechnicalDebtDernier post de notre série sur l’analyse de la qualité du code PL/SQL avec SonarQube.

Evaluer la qualité d’une application ne consiste pas uniquement en l’analyse du code : cela, n’importe qui peut le faire. Le travail du consultant Qualité s’articule autour des questions suivantes : quoi, pourquoi, comment, combien.

  • Quoi : analyser les résultats. Taille et complexité du code, duplications, c’est ce que nous avons vu dans les posts précédents. On examinera les chiffres globaux mais aussi les moyennes, ainsi que les tendances dans le temps si l’on dispose de plusieurs versions. Puis on regarde les principales violations aux bonnes pratiques, en s’intéressant en priorité aux Blockers et Criticals.
  • Pourquoi ces résultats : rechercher les causes des mesures analysées, investiguer l’origine des résultats rencontrés.
  • Comment remédier : proposer un plan d’action. En fait, réaliser plusieurs propositions de plan d’action. Nous verrons ci-dessous que je décline ceux-ci en différents plans à court, moyen et long terme.
  • Combien cela coûte : évaluation du coût de chaque plan. Lire la suite

Analyse PL/SQL avec SonarQube – Evaluer la qualité (2/3)

PLSQLEva2Désolé de vous avoir fait attendre pour la suite de cette série sur le code PL/SQL et SonarQube, mais j’ai été pas mal occupé, entre voyages, travail et mon portable qui m’a lâchement abandonné, en invoquant bien évidemment la loi de Murphy pour justifier de tomber en panne au pire moment.

Rappel sur les posts précédents : après avoir configuré une analyse de code PL/SQL avec SonarQube, nous avons constitué notre propre Quality Profile en orientant les règles Blockers et Criticals sur la robustesse, la performance et la sécurité. A quoi ressemble maintenant notre tableau de bord ? Lire la suite

Analyse PL/SQL avec SonarQube – Evaluer la qualité (1/3)

PLSQL_EvaluationQualité1Un post en guise de synthèse, pour cette série sur l’analyse de code PL/SQL avec SonarQube.

Après avoir configuré notre analyse avec Jenkins, nous avons lancé celle-ci et constaté 17 infractions bloquantes (Blockers) mais zéro défaut critique (Critical) avec le Quality Profile par défaut de SonarQube. En fait, les 5 règles Critical existantes étaient désactivées, ainsi que certaines des autres règles de différentes criticités : 58 sur un total de 132. Lire la suite

Analyse PL/SQL avec SonarQube – Majors

PLSQL_MajorsNous continuons cette série sur l’analyse de code PL/SQL, avec aujourd’hui les règles de type Major.

Nous avons vu précédemment comment organiser notre environnement et configurer notre analyse de code avec Jenkins et SonarQube.

Nous avons créé notre propre Quality Profile, puis examiné les règles de type Blockers et Criticals, toutes orientées Robustesse (Reliability) et Sécurité. Lire la suite

Analyse PL/SQL avec SonarQube – Criticals

PLSQL_CriticalDans le post précédent de cette série sur l’analyse de code PL/SQL avec SonarQube, nous avons examiné les régles Blockers existantes dans notre Quality Profile.

Nous avons rencontré à cette occasion 3 violations aux ‘best practices’ de programmation PL/SQL dont les conséquences sont d’une gravité telle qu’aucune tolérance n’est envisageable pour celles-ci. Ce qui justifie donc leur statut de ‘Blockers’.

Nous avons également constaté un total de 18 défauts pour ces 3 règles, donc ce nombre limité nous laisse supposer que celles-ci sont connues de l’équipe de projet

Enfin, ces défauts ont pour conséquence un bug de logique applicative dans l’application – une opération qui ne sera jamais effectuée car la condition correspondante ne sera jamais rencontrée – voire un crash pur et simple. Lire la suite

Analyse PL/SQL avec SonarQube – Blockers

PLSQL_BlockersCriticalDans le post précédent, nous avons créé notre propre Quality Profile PL/SQL en activant toutes les règles existantes dans SonarQube, au nombre de 132. Puis nous avons ensuite relancé l’analyse créée précédemment.

Nous allons ainsi pouvoir travailler avec l’ensemble des règles du Quality Profile par défaut de SonarQube et sélectionner celles qui nous intéressent afin de créer un tableau de bord ‘PL/SQL’ pour notre environnement de démo. Lire la suite

Analyse PL/SQL avec SonarQube – Le Quality Profile PL/SQL

SonarQubePLSQL3Après avoir configuré notre première analyse PL/SQL depuis Jenkins, nous avons lancé celle-ci, et nous pouvons donc maintenant regarder les résultats dans le tableau de bord SonarQube.

Ceci sera l’occasion d’examiner et d’expliciter dans nos prochains posts, les règles proposées par SonarQube en matière de bonnes pratiques de programmation PL/SQL. Mais tout d’abord, regardons ce que nous propose le ‘profile’ PL/SQL de SonarQube. Lire la suite

Analyse PL/SQL avec SonarQube – Configuration

SonarQubePLSQL2Nous avons vu, dans le premier post de cette série sur l’analyse de code PL/SQL avec SonarQube, comment j’organise mon environnement d’analyse, avec :

  • un dossier C:\SRC\ contenant tous les projets,
  • un sous-répertoire dédié au projet,
  • différents sous-répertoires dont un ‘..\Source’ avec le code source à analyser.

Dans le cas de notre analyse PL/SQL, ce code se trouvera donc dans un dossier ’C:\SRC\Demo\PLSQL\Source’.

Voyons maintenant comment créer et configurer une analyse SonarQube de ce code, avec Jenkins. Lire la suite