Application Legacy en C – Refactoring ou réingénierie ? (III)

Word_Refactoring_Reingenierie3Nous avons cette application Legacy en C, la première version de Word publiée par Microsoft en 1990, pour laquelle nous nous proposons de chiffrer le coût de différentes stratégies : refactoring ou reengineering, par la même équipe de développeurs ou au contraire, par une autre équipe et donc avec un transfert de connaissances. Lire la suite

Madrid DevOps – Intégration Continue

Madrid_DevOps2Madrid DevOps est un groupe de professionnels dédié à … DevOps, comme on peut l’imaginer. Il existe un ‘Meetup Group’ où trouver les informations les plus récentes, principalement au sujet de nouvelles réunions, chaque mois.

Le 10 avril dernier, la présentation de Manuel Recena Soto et Antonio Manuel Muñiz de ClinkerHQ, s’intitulait ‘Continuous Integration’. Je leur ai posé quelques questions au sujet de cette présentation, que vous pouvez trouver ici https://speakerdeck.com/clinkerhq/integracion-continua (en espagnol). Lire la suite

Application Legacy en C – Refactoring ou réingénierie ? (I)

WordCLegacy_UseCases1Suite de notre série sur l’analyse du code source de Word 1.1a, la première version de ce traitement de texte publié par Microsoft en 1990.

Dans le premier post, nous avons vu les métriques quantitatives de taille (LOCs), de complexité (CC), le niveau de commentaires et de duplication. Le second post était consacré aux différentes Issues’ de type Blocker, Critical, Major et Minor. Lire la suite

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

C_Analysis_Word2Nous avons examiné  dans le post précédent, les premiers résultats de l’analyse du code source de Word 1.1a (1990).

Nous avons compté 349 fichiers, ce qui n’est pas énorme, mais avec une taille assez élevée : en moyenne plus de 470 LOC (Lines Of Code), et nombre d’entre eux bien au-delà des 1 000 LOC. Les métriques de complexité sont élevées également, et le taux de commentaires assez bas, mais c’était probablement normal à l’époque, il y a plus de 40 ans.

Le très faible niveau de duplication amène à penser que tous les composants nécessaires à l’implémentation d’une même fonctionnalité se retrouvent dans un même fichier, ce qui explique donc la taille et la complexité de nombre d’entre eux. Il semble que le mot d’ordre ait été : priorité à l’efficacité, au second plan la lisibilité et la compréhension du code.     Lire la suite

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