Lors de la refactorisation, pensez « évolution, pas révolution »

Au début de ma carrière de développeur de logiciels, j'ai eu la chance d'assister à ce qui semblait initialement être une réunion assez standard décrivant la mise en œuvre d'une nouvelle fonctionnalité. Dans le cadre de cette discussion, deux ingénieurs seniors ont échangé sur la meilleure façon d'ajouter la nouvelle fonctionnalité à l'application que nous développions à l'époque. Cette nouvelle fonctionnalité nous obligerait à nous appuyer sur une partie substantielle de notre code qui était… pour le moins négligée.

Dans le cadre de la discussion, un développeur senior a insisté sur le fait qu'il était maintenant temps de vider cette zone de code une fois pour toutes. Le code était hideux, il était vieux et il sentait mauvais. Nous pourrions recommencer, nous pourrions réécrire ce code à partir de zéro et le rendre génial. Nous devions de toute façon ajouter cette nouvelle fonctionnalité, pourquoi ne pas réécrire également toute la zone de code associée ? Cela nous éviterait sûrement des maux de tête à long terme ?

L'autre développeur n'était pas d'accord. Oui, le code était un gâchis. Oui, il a été écrit il y a longtemps. Oui, les auteurs originaux avaient depuis longtemps fui l'entreprise, laissant la destruction dans leur sillage. Cependant, à toutes fins utiles, cela a fonctionné. Il a fait ce que nos clients attendaient de lui, même si le code était hideux sous le capot. De plus, nous étions déjà sous pression pour sortir cette nouvelle fonctionnalité, et la réécriture d'un énorme morceau de code hérité ne ferait qu'entraîner des retards supplémentaires, des délais manqués et des matchs criants.

Au lieu de cela, il a proposé un compromis et, ce faisant, il a utilisé une phrase qui m'est restée dans tous mes autres rôles de développeur depuis. Il a dit que nous devrions nous concentrer sur "l'évolution, pas la révolution".

Les problèmes de la « révolution »

Réécrire cet énorme morceau de code hérité n'était tout simplement pas une option pour le moment. Une « révolution » dans ce cas ne serait tout simplement pas possible étant donné les contraintes de temps auxquelles nous étions actuellement soumis. De plus, pourrions-nous vraiment nous permettre de prendre le risque de publier des changements aussi importants parallèlement à une toute nouvelle fonctionnalité à la fois ? Parallèlement aux efforts de développement, le nombre de tests unitaires, de tests d'intégration, de tests système et de tests manuels nécessaires augmenterait également de manière significative.

Il fallait être réaliste. Dans un monde idéal, bien sûr, nous aimerions réécrire ce code dans son intégralité et fournir la nouvelle fonctionnalité à un niveau tout aussi élevé. Mais, malheureusement, nous ne vivons pas dans ce monde idéal.

Alors que faisons-nous?

Le temps de "l'évolution"

Les étapes proposées étaient les suivantes :

• Nous développons la nouvelle fonctionnalité à un niveau de qualité élevé.
• Pendant que nous travaillons sur cette fonctionnalité, si nous touchons une zone de l'ancien code dans le processus, nous l'améliorons. Lentement mais sûrement.
• Nous testons minutieusement ces améliorations. Nous nous assurons d'avoir un niveau élevé de couverture de code dans notre suite de tests et nous effectuons des tests manuels approfondis.
• Au cours de notre travail, si nous voyons des domaines d'amélioration clairs qui pourraient être apportés mais qui prendraient beaucoup de temps, nous les rassemblons. Ensuite, ils peuvent être analysés et regroupés. Nous pourrions créer des tickets pour mettre en œuvre ces changements, en communiquant aux parties prenantes les avantages qui en résulteraient. Encore une fois, nous pourrions mettre en œuvre ces améliorations étape par étape.

Cette approche met l'accent sur l'importance de maintenir les fonctionnalités existantes tout en les itérant et en les améliorant progressivement. Nous avons décomposé une seule grande tâche de refactoring en tâches plus petites et plus gérables. Ces petites tâches pourraient être mises en œuvre progressivement sans perturber le système de fonctionnement actuel.

Ainsi, nous avons pu éviter d'introduire de nouveaux bogues et de casser des fonctionnalités existantes, tout en apportant des améliorations progressives à notre base de code. Cette approche nous a également aidés à suivre plus efficacement les changements et à garantir que les changements que nous avons apportés l'ont été de manière contrôlée et itérative.

En fin de compte, nous avons pu livrer la nouvelle fonctionnalité (pour la plupart) à temps. Tout en améliorant progressivement le code existant sur une période plus longue. Comme le dit le vieil adage/blague : « Comment mangez-vous un éléphant ? Une bouchée à la fois.

Note : Aucun éléphant n'a été blessé lors de la rédaction de cet article.

Merci beaucoup d'avoir pris le temps de lire ceci.

Si vous avez apprécié cet article ou l'avez trouvé informatif, pensez à lire certains de mes autres articles et suivez-moi sur Medium. Acclamations!