Faut-il réécrire le code hérité en C# ? Un regard plus approfondi sur le point de vue de Derek Comartin

L'illusion de la simplicité

À 1:07, Derek évoque ses débuts en tant que développeur junior. Comme beaucoup d'autres, il a souvent voulu réécrire de grandes parties d'un système simplement parce qu'il pensait que le code était mauvais. Mais il s'est rendu compte par la suite que cette conviction découlait souvent d'une incompréhension du code, et non pas du fait que le code lui-même était intrinsèquement mauvais.

Il nous fait part d'une vérité qui peut être vécue :

"Partir de zéro est plus facile que d'avoir à se plonger dans la base de code, dans toute sa complexité, dans les cas limites - c'est vraiment difficile"

En fait, ce qui ressemble à un "feu de pneu" n'est peut-être qu'une logique mal comprise enveloppée dans des années d'évolution et de correctifs. Les développeurs confondent souvent méconnaissance et mauvaise conception.

Quand les réécritures peuvent être justifiées

Derek ne dit pas pour autant que les réécritures sont toujours mauvaises. Vers 1:44, il commence à introduire des nuances. Pour les équipes qui travaillent dans la même base de code depuis des années, qui comprennent toute la complexité du domaine et les limites du système, la réécriture peut être une option valable.

"Si vous êtes dans un système depuis très longtemps... c'est là qu'intervient la nuance. Vous pouvez dire oui, cette chose est un feu de pneu et nous empêche d'avancer. Il est peut-être opportun de procéder à une réécriture. "

"Le pire est le meilleur" et la règle des 80/20

Derek introduit le concept du "pire est meilleur" à 2:01, en le reliant au principe de Pareto (règle des 80/20). Il affirme que souvent, 80 % de la valeur d'un système provient de seulement 20 % de la base de code. Lors de la réécriture, l'objectif ne doit donc pas être de tout reproduire, mais de se concentrer sur l'essentiel qui apporte réellement de la valeur.

"Il y a un moment où moins de fonctionnalités - pire - est l'option préférable"

Il explique que la simplicité et l'aspect pratique l'emportent souvent sur l'exhaustivité. Un système limité mais utilisable et maintenable peut s'avérer plus utile qu'une plateforme patrimoniale tentaculaire mais difficile à maintenir.

Évaluer les coûts par rapport aux avantages

À 2:47, Derek suggère que la décision finale se résume souvent à une analyse coûts-avantages. Réécrire pour réécrire n'est jamais justifié. Mais si le coût de la maintenance de l'ancien code ou des limites imposées par l'ancienne technologie est supérieur à celui de la réécriture, l'équation peut pencher en faveur d'une réécriture.

Il fait référence à des situations où votre avantage concurrentiel est entravé parce que vous êtes bloqué sur des plates-formes ou des outils obsolètes. Dans de tels cas, le fossé technologique lui-même devient une raison valable de reconstruire.

Une leçon de Greg Young

Derek évoque un billet brillant de Greg Young à 3:12, dans lequel un prototype qui est accidentellement passé en production a été réécrit. La réécriture a duré 9 mois. Le résultat ?

"Après neuf mois de travail sur l'architecture et le code, nous gagnions environ 10 000 dollars de plus par mois"

Greg a conclu qu'ils auraient mieux fait de construire 30 nouveaux prototypes pour tester de nouvelles stratégies plutôt que d'investir massivement dans la reconstruction de celui-là. Derek aime cette conclusion parce qu'elle remet en question l'idée que la perfection technique est toujours l'objectif à atteindre.

Parfois, c'est le logiciel "suffisamment bon" qui l'emporte, surtout lorsqu'il apporte déjà une valeur ajoutée à l'entreprise.

Le parti pris "ancien contre nouveau"

À 4:20, Derek aborde la question de l'idée reçue selon laquelle l'ancien est mauvais et le nouveau est bon. Il donne un exemple personnel : il intègre deux services tiers qui ont la même finalité. L'un d'entre eux utilise JSON moderne et est probablement construit en Python. L'autre, étonnamment, renvoie du XML et a probablement été construit en ColdFusion dans les années 1990.

"Ils sont tous deux équivalents. Ils sont stables. Ils offrent la même valeur à mes clients et à moi-même "

Cela montre que le plus récent n'est pas toujours le meilleur. La stabilité, la fiabilité et l'utilité sont souvent bien plus importantes que la pile technologique.

Expérience personnelle de réécriture de Derek

Derek partage enfin sa propre histoire à 5:31. Il a participé à une réécriture à grande échelle après avoir passé plus de six ans dans le domaine du système d'origine. La réécriture a duré environ 14 mois, principalement en raison d'une lacune technologique qui limitait la capacité du système à s'intégrer aux outils de commerce électronique et aux services en ligne modernes.

"Nous avons vraiment dû reconstruire quelque chose de nouveau à cette fin"

Il ne s'agissait pas seulement d'un cas de "mauvais code" - le système était fondamentalement incapable d'évoluer, de sorte que la reconstruction était la seule voie viable.

Conclusion

À la fin de la vidéo, vers 6:11, Derek rappelle que la réponse n'est pas simplement "oui" ou "non"

"Je ne pense pas que la réponse soit clairement négative. Je pense qu'il faut être prudent avant de prendre cette décision, car le contexte est important et il y a beaucoup de nuances