Nous 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 →

Nous 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 →

Un 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 →

En 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 →

Comme 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 →

Afin 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 →

Nous 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 →

Nous 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 →

Dans notre post précédent, nous avons repris la définition de Michael Feathers (depuis son livre « Working Effectively with Legacy Code ») selon lequel l’absence de tests unitaires est le facteur déterminant d’une application Legacy. Il propose le concept de test de caractérisation afin de comprendre le comportement de l’application, c’est-à-dire ce qu’elle fait réellement, et non pas de chercher à découvrir à travers le code ce qu’elle est censée faire.

Mais qu’en est-il lorsque notre application Legacy ne dispose pas déjà de tests unitaires ? La réponse à l’un de nos 3 scénarios – plan de transfert de l’application à une autre équipe – peut-elle passer par l’écriture de tests ? Est-il possible de faciliter ce transfert de connaissances avec des tests de ce type ? Lire la suite →