Upgrade SonarQube

Upgrade SonarQubeCela fait un moment que  je n’ai pas mis à jour mon environnement SonarQube. Un bon six mois, voire plus, puisque je suis encore en version 4.2 alors que la dernière version disponible est une 4.5.1 LTS (Long Term Support). Donc une version éminemment candidate à installation.

Cet article sur le blog de SonarSource décrit les buts et objectifs d’une telle version : Walking the Tightrope: Balancing Agility and Stability. La 4.5.1 ne propose pas uniquement des corrections mais également nombre d’évolutions et de nouvelles features.

Lire la suite

3 bougies pour Qualilogy

Qualiloty Analytics 2014Qualilogy a 3 ans, depuis la semaine dernière, puisque j’ai écrit le premier article le 21 novembre 2011.

10 000 visiteurs uniques la première année, 36 000 au bout de deux ans et près de 100 000 pages visitées. Pour ce troisième anniversaire, la barre des 65 000 visiteurs uniques a été passée (à 24 heures près), en 90 000 sessions et 165 000 pages vues.

Encore une fois, ces nombres issus de Google Analytics ne sont pas d’une précision absolue, d’autant que ce dernier s’est parfois mis en grève sur mon blog, mais en tout cas, ils ne sont pas surestimés.  Lire la suite

Application Legacy – Reengineering avec SonarQube (II)

Application Legacy – Reengineering avec SonarQubeNous avons vu dans le post précédent comment entamer un reengineering avec SonarQube en commençant par un redécoupage fonctionnel et le re-design de notre application.

Nous pouvons maintenant descendre un peu plus dans le code afin d’identifier des flux de traitements candidats à restructuration. Lire la suite

Application Legacy – Reengineering avec SonarQube

Application Legacy - Réingenierie avec SonarQubeNous avons défini notre projet de réingénierie comme la réécriture de notre application Legacy dans un nouveau langage ou son portage vers une nouvelle technologie, par opposition à un refactoring qui consiste à réorganiser le code et à en corriger certains défauts afin de rendre celui-ci plus maintenable et de réduire sa dette technique.

Nous avons vu également, à l’aide de SonarQube et du plugin SQALE, différents plans de refactoring plus ou moins ambitieux, depuis la résolution des défauts les plus critiques jusqu’à la réduction de la dette technique afin de ramener celle-ci à un niveau (rating SQALE) ‘A’.

Cependant, pour une même application Legacy, est-il plus intéressant d’effectuer un projet de réingénierie ou ‘simplement’ de refactoring ? Lire la suite

Application Legacy – Objectifs d’un reengineering

Application Legacy - Objectifs d'un reengineeringUn reengineering ne signifie pas toujours dans l’esprit de chacun, la réécriture de notre application Legacy dans un autre langage généralement plus récent, mais c’est néanmoins l’option que nous avons choisie.

Lorsqu’il s’agit ‘simplement’ de réorganiser le code afin de rendre celui-ci plus maintenable, mais sans le porter sur une nouvelle plate-forme logicielle ou hardware – comme par exemple la migration d’une application Mainframe-Cobol vers une architecture Unix – je préfère parler de refactoring.

Je vous rappelle que ce blog n’a pas de prétentions académiques, donc je ne vais pas m’embarrasser de définitions méticuleusement exactes, qui débouchent le plus souvent sur des discussions quadripilotectomiques (1) de spécialistes qui n’ont rien d’autre à faire que de gloser sur la moindre virgule. Lire la suite

Application Legacy – Dette technique et ROI d’un refactoring

Application Legacy - Techncal Debt et le ROI d'un RefactoringEn matière de ROI, je ne me complique pas la vie : je pose l’hypothèse que nous allons réduire les coûts de maintenance dans une proportion égale à la réduction de la dette technique.

C’est une hypothèse que l’on peut trouver simpliste et donc discutable, mais notre ambition ne réside pas dans une précision absolue et exacte des chiffres que nous avançons – ce serait prétentieux et irréaliste – sinon à fournir au management des éléments qui facilitent sa prise de décision.
Et je pense que le management préfère une hypothèse de travail simple et claire, même si moins précise, plutôt qu’une formule complexe qui ne sera pas forcément plus réaliste. Lire la suite

Application Legacy – Refactoring avec le plugin SQALE (II)

LegacyTechDebtRefactoring3Comme je l’ai expliqué dans le post précédent, nous n’avons pas personnalisé le profile SonarQube et le modèle SQALE en fonction de notre application Legacy et de son contexte. En fait, nous utilisons les résultats ‘out of the box’ afin d’illustrer une démarche possible d’estimation du coût de refactoring de celle-ci, et de présenter quelques pistes d’action à approfondir avec l’équipe de projet et le management – ou éventuellement à voir ceux-ci les rejeter.

En d’autres termes, c’est la démarche qui nous intéresse plus que les résultats sur notre application, tout au moins dans le cadre de ces articles.

Je vais présenter ces actions, des plus simples au plus avancées. Lire la suite

Application Legacy – Refactoring avec le plugin SQALE (I)

Application Legacy - Refactoring Technical Debt with the plugin SQALE SonarQubeAfin de procéder à une estimation du coût de refactoring de notre application Legacy, je vais utiliser le plugin SQALE de SonarQube, employé habituellement pour mesurer la Dette Technique.

Nous avons déjà présenté ce plugin avec une application Legacy PL/SQL. Rappelons donc simplement que le plugin SQALE est basé sur le modèle SQALE de la qualité, et j’ajouterai également, sur une méthode permettant d’adapter le modèle en l’alignant avec les différents objectifs métiers, la technologie utilisée pour l’application, ou le contexte applicatif. Lire la suite

Application Legacy – Refactoring ou reengineering? (VII)

Qualilogy Legacy Application Refactoring ReengineeringNous avons montré dans le post précédent comment utiliser le dashboard SonarQube afin d’estimer l’effort de tests de caractérisation, tests préconisés par Michael Feathers dans son livre ‘Working Effectively with Legacy Code’.

Nous avons catégorisé les différents composants de notre application Legacy (Microsoft Word 1.1a) en différents groupes, des fonctions les plus simples avec une Complexité Cyclomatique (CC) inférieure à 20 points, aux fonctions complexes à très complexes, jusqu’à 200 points de CC, et finalement 6 composants ‘monstres’.

Nous avons construit une formule basée sur la Complexité Cyclomatique et un facteur de lisibilité afin d’évaluer l’effort de test sur chacun de ces groupes. Lire la suite

Application Legacy – Refactoring ou reengineering? (VI)

Qualilogy -Application Legacy - Effort de testNous avons présenté dans les deux posts précédents la notion de tests (unitaires) de caractérisation, proposée par Michael Feathers dans son livre ‘Working Effectively with Legacy Code’.

Nous avons montré brièvement comment nous pouvons utiliser de tels tests afin d’acquérir la connaissance du comportement de l’application. Je dis bien brièvement car, idéalement, il nous aurait fallu développer et présenter quelques tests à titre d’exemple, mais cela nécessiterait plusieurs posts, et cette série est déjà bien longue. Je vous renvoie au livre de Michael Feathers si vous souhaitez approfondir cette question.

Retenons simplement que l’écriture de ces tests facilitera le transfert de connaissances de notre application Legacy (Word 1.1a de Microsoft), et que toute opération ultérieure de refactoring ou de ré-engineering en sera plus rapide et plus sûre. Lire la suite