Lorsqu'elles maintiennent et améliorent les systèmes d'ingénierie, les organisations doivent souvent prendre une décision critique : doivent-elles refactorer les composantes existantes ou les réécrire entièrement? Comprendre les différences, les avantages et les inconvénients de chaque approche est essentiel pour faire des choix éclairés qui s'harmonisent avec les objectifs du projet et les contraintes en matière de ressources.

Comprendre la refactoration

Refactoring consiste à apporter des améliorations progressives aux systèmes existants sans modifier leur fonctionnalité de base. Il vise à améliorer la qualité du code, sa lisibilité et sa maintenance tout en préservant le comportement du système. Cette approche est souvent utilisée pour réduire la dette technique et préparer les systèmes pour le développement futur.

Améliorations supplémentaires et odeurs de code

La refacturation cible généralement les « odeurs de code » – indicateurs de surface qui correspondent généralement à des problèmes plus profonds dans le système. Les exemples incluent le code dupliqué, les méthodes longues, les grandes classes et les couplages excessifs. En éliminant systématiquement ces odeurs, les équipes peuvent rendre la base de code plus modulaire et testable.

Quand faut-il refactorer

Il est également approprié lorsque la logique d'affaires est complexe et bien comprise, car la réécriture risque de perdre des connaissances du domaine durement acquises. Les équipes qui pratiquent la refacturation continue dans le cadre de leur cycle de développement (p. ex., la «règle du scout de garçons») trouvent que la base de code demeure saine et que le besoin de réécritures importantes diminue. La refacturation est moins risquée parce que vous pouvez valider la correction par des tests et de petits déploiements.

Comprendre la réécriture

La réécriture, par contre, consiste à développer un nouveau système à partir de zéro ou à remanier substantiellement celui existant. Cette méthode est généralement choisie lorsque le système actuel est dépassé, trop complexe ou ne répond plus aux besoins des entreprises. La réécriture peut fournir un nouveau départ, permettant la mise en œuvre d'architectures et de technologies modernes.

Greenfield vs Brownfield Réécritures

Une réécriture de champ vert commence par une ardoise blanche, la construction du système dans un environnement complètement nouveau. Cela arrive souvent lorsque la plate-forme originale est obsolète (p. ex., migrer de Cobol à Java) ou que le système doit être entièrement ré-alterné pour être évolutif. Une réécriture de champ brun remplace progressivement des parties du système existant tout en maintenant les autres en marche – parfois appelé le « patron de figuier ».

Quand réécrire

La réécriture est justifiée lorsque le système actuel a atteint un point où la refacturation coûterait plus que la reconstruction. Les indicateurs comprennent : la base de code est intestable, l'architecture empêche les changements nécessaires (par exemple, ne peut pas être mise à l'échelle horizontale), ou la pile de technologie n'est plus supportée. Un autre scénario est lorsque le modèle d'affaires a changé si radicalement que le système hérité ne peut s'adapter sans une reconstruction complète.

Comparaison des risques et des coûts

Les deux approches comportent des profils de risque et des structures de coûts distincts, ce qui aide les équipes à aligner leur choix sur la tolérance au risque organisationnel et les cycles budgétaires.

Facteurs de risque

Les risques de refacturation:[ Le plus grand risque est que la refacturation ne se termine jamais – elle devient un cycle sans fin de petites améliorations pendant que les problèmes sous-jacents du système persistent.Un autre risque est la «refacturation de la fatigue», où l'équipe perd de la motivation parce que les progrès sont lents et invisibles pour les intervenants.

Retraits de réécriture: L'avertissement le plus célèbre vient de l'article de Joel Spolsky "Things You Nef Nef Do, Part I", où il soutient que la réécriture conduit souvent à expédier un buggy, les années de remplacement de fonctionnalités-pauvres. La réécriture introduit le risque de calendrier (le nouveau système peut prendre plus de temps que prévu), le risque de connaissances (les règles d'affaires se perdent dans la traduction) et le risque d'intégration (migration de données et interopérabilité avec d'autres systèmes).

Analyse des coûts

Une étude de l'Institut de génie logiciel a révélé que la correction d'un défaut après la libération coûte 10 à 100x de plus que la correction pendant la conception, mais la refacturation attrape de nombreux défauts tôt en améliorant la clarté du code. La réécriture nécessite un investissement initial important : vous devez réanalyser, remanier, recoder et tout tester. Le coût total de la propriété (TCO) pour une réécriture dépasse souvent celui de la réfacturation sur un horizon de 3 à 5 ans, à moins que le système hérité ne soit vraiment inmaintenable.

Cadre de décision pour les chefs d'ingénierie

Le choix entre la refactoration et la réécriture dépend de divers facteurs, tels que la complexité du système, les priorités opérationnelles, les ressources disponibles et les objectifs à long terme. Le cadre de décision suivant peut aider à évaluer votre situation particulière.

Évaluation du système de santé

Effectuez une analyse systématique de la base de code en utilisant des paramètres comme la complexité cyclomatique, la couverture de code, le couplage et la densité des défauts. Des outils comme SonarQube ou CodeClimate peuvent fournir des données objectives. Si le système note mal sur la maintenance mais que la logique d'entreprise est stable, la refacturation peut suffire. Si l'architecture est fondamentalement déficiente (par exemple, spaghetti monolithique qui ne peut pas être modulalisée), une réécriture peut être nécessaire.

Harmonisation des objectifs opérationnels

Si l'objectif est d'accélérer la mise en oeuvre des fonctionnalités au cours du prochain trimestre, la remise en état est généralement plus sûre. Si l'objectif est d'entrer sur un nouveau marché qui nécessite des caractéristiques de performance ou de mise à l'échelle radicalement différentes, une réécriture pourrait être justifiée.

Capacité de l'équipe et connaissances institutionnelles

Si les auteurs originaux sont encore dans l'équipe, la refactoration est plus efficace. Si la base de code est une boîte noire avec peu de documentation, une réécriture peut sembler tentante, mais elle risque de répéter des erreurs passées. Dans ce cas, envisager une «réécriture avec conservation» : construire le nouveau système en parallèle, mais extraire les règles d'affaires de l'ancien code par une lecture attentive et des tests automatisés avant de jeter l'ancien système.

Exemples du monde réel

L'examen de la façon dont d'autres organisations ont choisi ce choix peut fournir des indications pratiques.

Exemple : Refacturation de l'Aîné par Basecamp

Lors du développement du service de messagerie HEY, l'équipe de Basecamp a choisi de refactorer la base de codes Rails existante plutôt que de la réécrire à partir de zéro.Elle a systématiquement extrait la logique de domaine en objets de service, amélioré la couverture des tests et éliminé le code mort.Cela leur a permis d'expédier le produit à temps tout en maintenant la base de codes à jour. L'équipe a documenté leur approche, soulignant que l'amélioration progressive était la clé pour préserver leur compréhension approfondie de la manipulation des courriels.

Exemple : Réécriture de FreshBooks

FreshBooks, une société de logiciels comptables, a réécrit toute leur plateforme, d'une application PHP monolithique à un système moderne et évolutif. La décision est venue après des années de lutte contre les contraintes de performance et architecturales qui ne pouvaient pas corriger. La réécriture a pris plus de 2 ans et a coûté des dizaines de millions de dollars, mais elle leur a permis de servir des clients plus importants et de réduire les coûts de soutien. Le PDG a noté que la réécriture était «la chose la plus difficile que nous ayons jamais faite», mais il était nécessaire pour l'entreprise de survivre. Leur post-mortem] souligne l'importance de l'alignement entre la vision d'entreprise et l'architecture technique.

Exemple : Communauté de refactoring de Martin Fowler

Martin Fowler, auteur du livre séminal Refactoring: Improving the Design of Existing Code, a longtemps préconisé de refactoriser la surécriture. Il soutient que la plupart des systèmes peuvent être améliorés progressivement si les équipes investissent dans les tests automatisés et l'intégration continue.Son catalogue refactoring fournit des modèles éprouvés que toute équipe peut appliquer.

Conclusion : Faire le bon choix

Une évaluation minutieuse de la situation particulière guidera les organisations vers la stratégie la plus efficace, en équilibrage des risques, des coûts et de la préparation future. Le bon chemin implique souvent une combinaison : refactorer les pièces qui sont récupérables et réécrire uniquement les composants qui sont irréparables. Utilisez le cadre décrit ici pour évaluer la santé de votre base de codes, s'aligner sur les objectifs opérationnels et tirer parti des connaissances de l'équipe. En faisant un choix éclairé, vous pouvez conduire votre organisation vers des systèmes plus robustes, efficaces et adaptables qui soutiennent la croissance sans tomber dans le piège des réécritures prématurées ou des refactorations sans fin.