Le premier entraĂ®nement…

La sĂ©ance d’entraĂ®nement

Ça y est, c’est fait! Nous avons complĂ©tĂ© notre première sĂ©ance d’entraĂ®nement. (Voir blogue prĂ©cĂ©dent)

Nous avons rĂ©ussi Ă  convaincre la direction. Celle-ci nous a accordĂ© 3 heures par sprint de 3 semaines pour parfaire nos techniques. Donc, Ă  partir de maintenant, Ă  chaque trois semaines, le vendredi de 9 heures Ă  midi, c’est notre sĂ©ance d’entraĂ®nement.

Étant dans un projet en cours, nous avions identifiĂ© un besoin de nous entraĂ®ner sur les techniques de remaniement (refactoring) du code existant. Nous voulions surtout nous entraĂ®ner sur une technique prĂ©cise que je pourrais nommer la « transplantation ». Si vous lisez tous les livres sur le remaniement de code, comme “Refactoring: Improving design of existing code” par Martin Fowler, Kent Beck et d’autres, vous trouverez plusieurs techniques pour faire du remaniement. Ces techniques prennent souvent en compte le fait que vous ayez une bonne couverture de tests au dĂ©part. Ce qui n’est pas le cas pour notre projet actuel. Cette lacune m’a amenĂ© Ă  dĂ©velopper la technique de la « transplantation ».

La transplantation

Ceci consiste à remplacer du code malade par du code sain, sans faire souffrir le système. La technique comporte trois étapes simples :

  1. Extraire les fonctionnalités du code à corriger;
  2. Améliorer le code en passant le TDD et le refactoring;
  3. RĂ©introduire le code dans son environnement initial.

Ça peut paraĂ®tre simple et Ă©vident au premier coup d’Ĺ“il, mais dans les faits ça ne l’est pas tant que ça.

L’extraction

Je parle ici d’extraction de la fonctionnalitĂ© et non du code. Quand un chirurgien veut remplacer un cĹ“ur naturel par un cĹ“ur artificiel, il n’a pas besoins de simuler parfaitement le battement du cĹ“ur. Il a seulement besoin d’une pompe pour faire circuler le sang.

Dans le code, c’est pareil. Si votre code malade accède directement Ă  une base de donnĂ©es SQL Server pour rĂ©cupĂ©rer l’information, vous n’avez pas Ă  faire la mĂŞme chose. L’important c’est de remplacer la fonctionnalitĂ©, par exemple, par un repository.

Le remaniement

C’est lĂ  qu’entre en jeu toutes ces belles techniques de remaniement mentionnĂ©es dans les livres suivants : Extract Method, Extract Class, Introduce parameter Object, Replace Conditional With Polymorphism,… Pour Ă©viter de partir de rien, vous allez sĂ»rement avoir tendance Ă  reprendre du code existant, et c’est normal, mais soyez prudents!

Avant de modifier quoi que ce soit, assurez-vous d’avoir une couverture complète de votre code par des tests unitaires. Du refactoing sans couverture de tests, c’est comme conduire sans ceinture de sĂ©curitĂ©; ça va tant qu’il n’y a pas de problèmes.

Le plus grand dĂ©fi auquel vous aurez Ă  faire face c’est l’abstraction des dĂ©pendances. Je vous parlerai de ce point dans un prochain billet.

La réintroduction

Si vous avez bien travaillĂ© Ă  l’Ă©tape prĂ©cĂ©dente, la rĂ©introduction devrait se faire facilement, sans trop de risques de rejet. Par contre, il peut arriver que le nouveau code ne soit pas parfaitement adaptĂ© Ă  son nouvel environnement. Après tout, il a Ă©tĂ© crĂ©Ă© en laboratoire.

Dans ce cas, vous avez deux choix : soit vous retournez Ă  l’Ă©tape prĂ©cĂ©dente pour faire des corrections, toujours avec la protection de tests, soit vous modifiez l’environnement du code pour qu’il fonctionne bien. Si vous choisissez cette deuxième option, il faut que vous ayez l’intention de remanier cet environnement plus tard et que le code d’adaptation ne soit que temporaire.

 A suivre…

email

Ă  propos de Ă©ric de carufel

Passionné, impliqué et minutieux sont des qualités qui décrivent bien Éric pour qui le développement logiciel est une quête constante d'amélioration pour atteindre l'équilibre entre la perfection et les besoins du client. Son approche architecturale est simple : élaborer une architecture où il est plus facile d'appliquer les bonnes pratiques que les mauvaises.
voir mon profil Â»