Une équipe hérite d'un module de facturation que personne ne maîtrise vraiment. Il ne comporte aucun test garantissant le bon fonctionnement du système. Un sprint est proposé pour le « nettoyer », et le plan consiste à réécrire le noyau selon une nouvelle structure. Personne ne peut garantir que la nouvelle version facturera correctement les clients.
Il s'agit d'un scénario illustratif, et non d'un incident documenté. Il décrit la lacune qu'un projet de formation au refactoring doit combler : former des ingénieurs capables de constater qu'un code est désordonné, mais incapables de planifier une amélioration ciblée et de démontrer que le comportement attendu a été préservé.
Ce guide s'adresse aux responsables et aux gestionnaires de la formation en ingénierie. Il explique comment décrire le problème de performance, diagnostiquer les écarts, concevoir la préparation et la pratique, analyser une étude de cas et évaluer la transférabilité des compétences au travail réel. Il traite de la conception de la formation. Le code, les tests et les règles de votre programme doivent être validés par des ingénieurs seniors sur votre propre environnement technique.
Qu'est-ce qu'un projet de formation au refactoring ?
Un projet de formation au refactoring est un travail structuré sur du code existant, dont l'objectif est de développer des compétences tout en améliorant le code. Les participants planifient une modification mineure et circonscrite, protègent le comportement existant par des tests, améliorent la conception par petites étapes et démontrent qu'aucune modification n'a été apportée. Le code s'améliore et, plus important encore, les ingénieurs s'exercent au jugement nécessaire pour gérer la dette technique réelle.
Faits rapides
| Questionne toi | Réponse courte |
|---|---|
| Quelle est la tâche ? | Planifier et valider une amélioration du code existant dans des limites définies. |
| Quel est votre score ? | Analyse des risques et preuves que les comportements existants ont été préservés. |
| Une refonte complète est-elle un bon projet de formation ? | Généralement non. Cela masque la compétence mise en pratique et rend difficile la démonstration d'un comportement préservé. |
| Un quiz sur les modèles de refactoring est-il suffisant ? | Non. Cela confirme les prérequis, mais pas si un ingénieur est capable de planifier et de valider une modification. |
| Qui valide le contenu ? | Un responsable d'ingénierie et un ingénieur senior connaissant le code source. |
| Qu'est-ce que la formation ne peut pas résoudre ? | Outillage de test manquant, pression de libération inexistante, responsabilité floue et manque de temps pour la maintenance. |
| Comment savez-vous que cela a fonctionné ? | Un nouveau cas de code hérité, inédit, évalué selon des critères convenus, avec un suivi sur un travail réel. |
1. Décrivez le problème de performance
Commencez par la tâche : planifier et valider une amélioration circonscrite du code existant. Le mot clé est « côté ». L’apprenant choisit une modification suffisamment petite pour la mener à bien et peut définir ce qui est inclus et exclu du périmètre.
Il est utile d'être précis quant aux termes employés. Martin Fowler décrit le refactoring comme une technique contrôlée pour améliorer la conception d'une base de code existantecomposée de petites transformations préservant le comportement. L'expression « préservant le comportement » distingue la refactorisation d'une réécriture, et c'est ce que la formation doit mettre en évidence. La métaphore de la dette technique elle-même a été inventé par Ward CunninghamEt la discussion de Fowler nous rappelle utilement que l'endettement peut être contracté de manière délibérée et prudente, de sorte que chaque module imparfait n'est pas forcément une erreur à corriger.
Le livre de Michael Feathers sur le code hérité adopte la même approche pratique. La description de l'éditeur indique qu'il enseigne aux développeurs comment écrire des tests qui garantissent Ils ne modifient pas l'application par inadvertance.et de maîtriser les logiciels existants sans avoir à les réécrire entièrement.
Rédigez l'énoncé de performance en une phrase et faites-le vérifier par un responsable d'ingénierie : « Étant donné un module existant et un objectif défini, l'ingénieur propose une modification circonscrite, ajoute des tests qui cernent le comportement actuel, effectue la modification par petites étapes et démontre que le comportement est préservé. »
2. Diagnostiquer les lacunes en matière d'apprentissage et de contexte
Avant de vous lancer dans la construction de quoi que ce soit, comparez la tâche requise avec ce que vous pratiquez et évaluez dans vos activités actuelles. Trois questions permettent généralement de distinguer un manque de formation d'autre chose :
- La pratique actuelle utilise-t-elle la tâche réelle ? Si la formation se contente de présenter des modèles de refactoring dans des diapositives, mais que personne ne modifie jamais le code non testé, personne ne s'exerce à protéger les comportements. Si l'évaluation consiste en un questionnaire à choix multiples sur les anomalies de code, elle mesure la mémorisation.
- Quelle est la demande cognitive ? Dans la taxonomie révisée de Bloom, l'évaluation de la sécurité d'un changement se situe aux niveaux d'analyse et d'évaluation, tandis que la conception du plan et des tests relève du niveau de création. L'association des activités à ces niveaux est abordée dans notre guide. Faire correspondre les activités d'apprentissage à la taxonomie de Bloom.
- Y a-t-il autre chose que le talent qui vous bloque ? Vérifiez les effectifs, les outils et les procédures. Si la compilation prend une heure, personne ne lancera de tests régulièrement. Si la maintenance n'est jamais planifiée, les ingénieurs ne feront de refactoring qu'en secret. Signalez les problèmes non liés à la formation aux personnes compétentes.
3. Concevoir une préparation et une pratique ciblées
Une fois que vous savez quelles lacunes la formation peut combler, attribuez à chaque étape une fonction distincte.
Préparation. Vérifiez les prérequis grâce à un diagnostic rapide : fonctionnement de votre cadre de test, définition d’un test de caractérisation et procédures de revue et de fusion au sein de votre équipe. À ce stade, l’autoformation est recommandée. Un contrôle de connaissances permet uniquement de confirmer les prérequis.
Pratique. Utilisez des projets de refactorisation systématiques et bien structurés. Commencez par un petit échantillon sûr, puis passez à une partie réelle mais délimitée de votre propre code. Le kata Gilded Rose est un point de départ bien connu pour la première étape. Son fichier README, maintenu par Emily Bache, recommande d'écrire des tests avant de modifier le code L'exercice est présenté comme une pratique consistant à procéder par petites étapes, à exécuter fréquemment les tests et à améliorer progressivement la conception. Une séquence logique pour chaque projet est la suivante : définir l'objectif et les limites, écrire des tests qui décrivent le comportement actuel du code, modifier un élément à la fois, exécuter les tests après chaque modification et consigner les enseignements tirés.
Feedback. Liez les commentaires aux décisions prises, et non à une note globale. « Vous avez extrait la logique de réduction, mais vos tests ne couvraient que le cas nominal ; vous n’avez donc pas pu remarquer le changement d’arrondi » est plus utile que « 3 sur 5 ».
Intervention en direct de l'instructeur ou révision asynchrone ? L'intervention en direct est particulièrement précieuse lorsqu'un choix est ambigu, par exemple s'il faut s'arrêter pour ajouter un test manquant ou continuer. La révision asynchrone suffit lorsque les apprenants comparent leur plan et leurs tests avec une version annotée par un expert. De nombreuses équipes utilisent les deux méthodes : une préparation autonome d'abord, puis une séance animée par un facilitateur sur les cas complexes.
4. Travaillez sur un exemple réaliste
À titre d'exemple, un responsable technique doit valider le cas et les critères de réponse avant toute utilisation.
L'affaire. Une fonction existante calcule le total d'une commande, incluant une remise, la taxe et les frais de livraison. Elle n'est pas testée. Une équipe propose de restructurer l'ensemble du module de facturation afin de le rendre plus clair.
La tâche. L'apprenant explique ce qu'il ferait, cite les preuves qu'il recueillerait et indique les informations ou le soutien supplémentaires dont il a besoin.
Une première tentative. « Je scinderais le module en trois services et transférerais la logique, puis je vérifierais les résultats en environnement de test. » L'apprenant a opté pour une modification importante et une vérification manuelle tardive. Il est impossible de savoir si les anciennes et nouvelles versions concordent sur les cas limites.
Commentaires et nouvelle tentative. L'évaluateur demande ce que fait la fonction actuellement lorsqu'un panier est vide, lorsqu'une réduction rend le total négatif et lorsqu'un arrondi est effectué. Lors de la nouvelle tentative, l'apprenant est invité à se concentrer sur un seul comportement et à expliquer comment il prouverait qu'il n'a pas changé.
Une tentative plus convaincante. « Je laisserais la structure du module telle quelle pour le moment. Je capturerais le comportement actuel de la fonction de calcul du total de la commande pour un ensemble d'entrées, y compris les cas limites, à titre de tests. Ensuite, j'extrairais le calcul de la remise dans une fonction distincte, j'exécuterais les tests après cette unique étape, et je m'arrêterais là. Je noterais que la règle de livraison présente un comportement que je ne comprends pas et je consulterais un collègue avant d'y toucher. » Notez que cette réponse encadre la modification, protège d'abord le comportement initial et nomme ce qui est inconnu.
Pourquoi chaque réponse est défendable ou incomplète. Évaluez chaque proposition selon des critères approuvés, et non selon les préférences d'un examinateur. La première tentative peut constituer une orientation judicieuse à long terme, mais elle reste incomplète en tant que plan, car elle ne repose sur aucune preuve de la pérennité des comportements observés. La tentative la plus solide est plus modeste, vérifiable et assume pleinement son incertitude.
5. Évaluer les capacités et planifier le transfert
La démonstration de compétence repose sur la performance face à un cas d'utilisation d'un code existant que l'apprenant n'a jamais vu auparavant. Évaluez l'analyse des risques et la preuve du maintien du comportement attendu. Une grille d'évaluation simple utilise une échelle de 0 à 2 par critère :
| Critère | Preuves observables |
|---|---|
| Exécution des tâches | Planifie et valide une amélioration du code existant dans des limites définies, et consigne l'action et les preuves qui la sous-tendent. |
| Raisonnement | Explique les contraintes, les alternatives et l'incertitude, et vérifie les risques et les preuves que le comportement a été préservé. |
| Frontières | Utilise les procédures approuvées et demande de l'aide lorsque les informations ou l'autorité sont insuffisantes. |
Ancrages : 0 signifie absent ou non étayé, 1 signifie partiel avec des omissions pertinentes, et 2 signifie complet et justifié par rapport aux critères convenus. Définissez les erreurs critiques séparément, comme un changement de comportement non détecté par un test, afin qu’une note globale ne puisse pas les masquer. Cette grille d’évaluation est une proposition, et non une norme de préparation validée : adaptez-la avec un responsable technique et testez-la. Consultez notre guide pour Concevoir une pratique interactive avec des retours utiles montre comment rédiger des commentaires qui permettent d'éclairer les décisions.
Planifiez le transfert de manière réfléchie. Après l'exercice, confiez à chaque ingénieur une petite tâche concrète à résoudre avec un réviseur, ou organisez une brève rétrospective sur une modification récente ayant entraîné un dysfonctionnement. Vérifiez le transfert après une immersion adéquate dans un environnement de travail réel, et non immédiatement après l'atelier.
Là où la livraison interactive est utile
Les formats interactifs permettent à chacun de s'engager avant la réunion de groupe. Lors d'une session en direct, un animateur peut présenter un court extrait de code existant, demander à chaque ingénieur de proposer la première modification qu'il apporterait et d'expliquer comment il en garantirait la sécurité, puis dévoiler le résultat avant la discussion. Cette même consigne peut être utilisée individuellement pour la préparation. AhaSlides favorise l'apprentissage interactif et permet d'alterner facilement entre présentation en direct et préparation individuelle. Il s'agit d'un outil de présentation et d'apprentissage, et non d'un environnement d'exécution ou d'analyse de code ; par conséquent, effectuez la refactorisation dans votre propre environnement. Vérifiez la compatibilité de toute fonction de création, de retour d'information ou de reporting que vous prévoyez d'utiliser avec votre flux de travail. Pour obtenir des conseils sur le choix des formats, consultez notre article sur Quand utiliser l'apprentissage adaptatif, interactif et en direct.
Mesurez ce qui a changé
Déterminez à l'avance les critères permettant de démontrer la compétence des ingénieurs. Comparez la qualité de l'analyse des risques et la persistance des comportements attendus sur un cas inédit, par rapport à une situation de référence. Précisez les critères d'inclusion, le dénominateur et le calendrier. Si les résultats s'améliorent, vérifiez les autres changements survenus durant la même période (nouveaux outils de test, accélération du processus de fabrication, changement de propriétaire, etc.) avant de valider la formation.
Des contraintes qui pourraient subsister
- Il est temps de procéder à des travaux d'entretien. Si les travaux de recouvrement de créances ne sont jamais programmés, les ingénieurs qualifiés n'ont toujours aucun moyen d'utiliser leurs compétences.
- Outils de test. Sans banc d'essai utilisable ni méthode de développement rapide, il est difficile de maintenir des progrès par petites étapes et des vérifications fréquentes.
- Couverture du dossier. Un cas historique illustre plusieurs types de risques. Une note ne reflète pas de manière générale le jugement d'un ingénieur.
- Savoir quand ne pas refactoriser. Certains codes sont mieux laissés en l'état, remplacés ou mis hors service, et cette décision implique bien plus que de simples compétences.
- Transfert. Les performances dans un kata ne sont pas les mêmes que les performances dans un module de production sous la pression de la livraison.
Signalez ces problèmes aux sponsors dès le début et prévoyez des correctifs distincts. La formation améliore les capacités de planification et de validation des ingénieurs. Elle ne crée ni le temps ni les outils nécessaires.
Foire aux questions
Qu'est-ce qu'un projet de formation au refactoring ?
Il s'agit d'une pratique structurée sur du code existant où les ingénieurs planifient une petite modification, protègent le comportement existant avec des tests, modifient la conception par petites étapes et montrent que rien n'a été cassé.
Une réécriture complète est-elle un bon moyen d'en apprendre davantage sur la dette technique ?
Généralement non. Une réécriture est volumineuse, difficile à valider et masque la compétence que vous souhaitez développer. Une modification circonscrite, accompagnée de tests qui capturent le comportement actuel, rend le raisonnement visible.
Comment évaluer si les ingénieurs peuvent refactoriser en toute sécurité ?
Fournissez un nouveau cas de code existant et évaluez l'analyse des risques ainsi que les preuves de la préservation du comportement par rapport aux critères convenus. Un questionnaire sur les modèles de refactoring ne vérifie que les prérequis.
Avez-vous besoin d'un exemple de code source pour la formation ?
Il vous faut un espace sécurisé pour vous entraîner. De nombreuses équipes commencent par un kata public, puis passent à une partie délimitée de leur propre code. Votre responsable technique devrait confirmer que le code est adapté.
Par où commencer
Choisissez une modification mineure et récurrente de votre code. Rédigez l'analyse de performance, faites-la valider par un responsable technique ainsi que les tests démontrant le maintien du comportement attendu, et élaborez une grille d'évaluation à trois critères (de 0 à 2) incluant une liste d'erreurs critiques. Testez-la auprès d'une petite équipe avant de la déployer.
Pour découvrir comment un exercice de décision de refactorisation pourrait être mené en direct avec votre propre équipe et réutilisé à votre propre rythme par la suite, explorez AhaSlides.
