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

Application Legacy – Refactoring ou reengineering? (V)

Legacy ou Reengineering - Tests de caracterisationDans 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

Application Legacy – Refactoring ou reengineering? (IV)

Qualilogy-Legacy-Reengineering-RefactoringAu retour des vacances estivales, je reprends cette série de posts sur l’utilisation de SonarQube avec une application Legacy en C, en l’espèce la première version de Word publiée par Microsoft en 1990.

Nous avons posé l’hypothèse suivante : Microsoft vient de se faire racheter et son nouveau propriétaire vous demande, en tant que consultant Qualité, de recommander une stratégie concernant cette version de Word.

Ne croyez pas que cela n’arrive jamais : des boîtes de software se font racheter tous les jours, et la R&D et le code de ces logiciels sont au cœur de ces acquisitions.

Lire la suite

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