Expériences et réflexions sur le modèle d'application Strangler

Question

Tout récemment, j'ai découvert une idée appelée Modèle d'étrangleur d'applications . D'après ce que j'ai compris, il s'agit d'une solution au problème des grands systèmes hérités. L'idée est de créer une nouvelle application autour de l'ancienne application. Le coût et le risque de cette démarche seront bien moindres que ceux d'une réécriture complète du système. Lentement, au fil du temps, la nouvelle application fera de plus en plus de travail et finira par étouffer l'ancienne application. Pendant ce temps, les développeurs travaillent dans un nouveau système propre, plus efficace et, espérons-le, produisant un bien meilleur code.

Là où je travaille actuellement, nous sommes arrivés à un point où les nouvelles fonctionnalités, même les choses apparemment insignifiantes, prennent beaucoup de temps à développer, avec un risque élevé de casser quelque chose. Nous avons environ un million de lignes de code, avec une couverture des tests unitaires de 1 à 2 %. Le système est un système SOA utilisant des services web (aucun n'est vraiment nécessaire) et est plus procédural dans son style qu'orienté objet. Le système est à la fois web et win, tout est écrit dans les langages de programmation .net.

Enfin la question : En envisageant cette nouvelle idée/ce nouveau modèle, j'aimerais savoir si quelqu'un a eu une expérience de l'utilisation de ce modèle qu'il aimerait partager. Par exemple, quelle serait une bonne façon de le mettre en œuvre (en se connectant aux événements de l'ancienne application, par exemple) ? De même, si quelqu'un a des idées sur le sujet, pourquoi ce serait une bonne ou une mauvaise idée, ce serait également apprécié.

Références :

• Article de blog de Martin Fowler
• Hanselminutes avec Michael Feathers

Answer 1

Le plus gros problème à surmonter est le manque de volonté de terminer réellement l'étranglement (généralement la volonté politique des parties prenantes non techniques, qui se manifeste par un manque de budget). Si vous n'éliminez pas complètement l'ancien système, vous vous retrouverez dans une situation encore pire, car votre système a maintenant deux façons de faire les choses, avec une interface maladroite entre les deux. Plus tard, une autre vague de développeurs décidera probablement d'étrangler ce qui existe déjà, en écrivant encore une autre application étrangleuse, et à nouveau un manque de volonté pourrait laisser le système dans un état encore pire, avec trois façons de faire les choses.

Si le projet est de grande envergure et qu'il est exécuté dans plusieurs régions, vous devez OBLIGATOIREMENT obtenir un consensus global sur l'état final et sur la manière dont chacun va coopérer pour y parvenir. Pendant que l'ancienne application est étranglée, il est vital pour les équipes distantes de communiquer tous les jours, de coopérer sur le travail si possible en faisant de la programmation par paire à distance, et de résoudre tout malentendu ou désaccord dès qu'il survient. Sinon, il y a un risque que chaque équipe régionale décide d'écrire sa propre application d'étranglement et qu'elles se rencontrent quelque part au milieu et s'affrontent, laissant le système encore pire.

Quoi que vous fassiez, n'effectuez pas le remaniement/la restructuration dans une branche différente du courant principal de développement. Les difficultés de fusion deviendront insurmontables.

J'ai vu des systèmes critiques qui ont subi ces deux sorts, et se sont retrouvés avec quatre ou cinq "orientations architecturales stratégiques" et "architectures d'état futur". Un grand projet multisite s'est retrouvé avec huit nouveaux mécanismes de persistance différents dans sa nouvelle architecture. Un autre s'est retrouvé avec deux schémas de base de données différents, l'un pour l'ancienne façon de faire les choses et l'autre pour la nouvelle. Aucun des deux schémas n'a jamais été supprimé du système et il existait également de multiples hiérarchies de classes qui correspondaient à l'un de ces schémas, voire aux deux.

Enfin, si vous introduisez des technologies qui sont nouvelles pour l'équipe ou pour le personnel de support/maintenance (par exemple, l'ajout d'une messagerie asynchrone fiable à ce qui est actuellement une architecture client/serveur synchrone à trois niveaux), vous devez vous assurer qu'il y a des responsables techniques expérimentés sur le projet qui savent comment construire des systèmes avec cette technologie et assurer le support de ces systèmes. Et ces responsables techniques doivent rester dans le projet pendant un certain temps après que l'ancienne application ait été complètement étranglée. Sinon, l'architecture se dégradera au fur et à mesure que des développeurs inexpérimentés la modifieront de la manière qu'ils connaissent, mais pas de la manière qui correspond à la nouvelle architecture.

Answer 2

Le grand risque de ce modèle est que vous finissiez par bloquer à la fois l'ancien et le nouveau code pour obtenir le comportement dont vous avez besoin, surtout si l'ancien code n'a jamais été conçu pour être étranglé (c'est-à-dire qu'il ne présente pas d'interfaces propres et cohérentes).

D'après mon expérience, le débogage devient plus difficile au fil du temps, car on ne sait pas si la fonctionnalité problématique est apparue dans le nouveau ou l'ancien code (ou un problème partagé entre les deux).

Je sais que Martin Fowler parle d'écrire du code conçu pour être étranglé, mais à mon avis, c'est simplement une autre façon de dire que la conception modulaire est une bonne chose, mmm ok ; c'est non controversé et assez évident.

Answer 3

Le principe de base de l'étrangleur est vraiment génial : au lieu d'essayer de remplacer un système existant en une seule fois dans un style "big bang", vous construisez une application étrangleuse en effectuant des coupes verticales dans les couches, en remplaçant chaque fonctionnalité existante une par une jusqu'à ce que le système d'origine puisse être mis hors service. Cette méthode fonctionne bien, en théorie et en pratique - l'un des meilleurs aspects de cette méthode est probablement qu'elle réduit considérablement le risque technologique et permet à une équipe de se concentrer sur le remplacement des fonctionnalités les plus importantes. Si le nouveau système ne fonctionne pas, les gens peuvent simplement utiliser l'ancien système.

Qu'est-ce qui pourrait mal tourner ?

• Les organisations peuvent trouver qu'il peut devenir difficile de conserver des informations à long terme. projets de rafraîchissement de l'infrastructure à long terme dans le sillage de nouveaux projets qui promettent de nouvelles fonctionnalités, un avantage concurrentiel, un potentiel de revenus, ou une augmentation de la part de marché - en particulier pour les organisations qui sont concentrées sur un produit ou un service. C'est l'un de ces problèmes immédiatement problèmes immédiatement visibles et, bien qu'il s'agisse d'un bouc émissaire facile, ce n'est généralement pas la seule menace. la seule menace.
• Lorsque le système remplacé est trop lié au système qui le remplace, cela peut causer des peut entraîner une augmentation considérable des difficultés techniques. peut être acceptable de leur faire partager un point d'intégration spécifique, mais mais plus que cela, c'est un problème. Lorsque l'équipe est distraite par le défis technologiques qu'elle s'est elle-même créés, elle ne travaille plus plus efficace et les délais du projet deviennent incontrôlables. contrôle.
• Les équipes technologiques qui sont organisées horizontalement peuvent avoir une particulièrement difficiles avec le modèle d'application étrangleur, car les tranches verticales nécessaires pour terminer le travail exigent une intégration avec plusieurs départements ou équipes, et chaque groupe a ses propres cycles de publication, ses propres cycles de publication, ses objectifs et ses pressions organisationnelles.
• S'il existe un remplacement de personnel technique ou de gestion clé au cours du projet, il arrive que les nouvelles personnes qui héritent du projet se rendent compte qu'elles qu'ils n'aiment pas le nouveau système plus que celui qu'il remplace. ce qui les amène à se lancer potentiellement dans un troisième système.
• Parfois, vous pourriez réussir partiellement, et créer une nouvelle version d'un système - mais quand il temps de revenir en arrière et de réécrire les systèmes de moindre importance pour commencer à à utiliser le nouveau système, les gens sont trop occupés à faire de nouvelles choses cool avec le nouveau système. Vous avez maintenant deux systèmes. Ou, si vous avez déjà fait une fois, vous en aurez trois.

Tous ces points faibles sont gérables, bien sûr. Il peut être utile de réorganiser les équipes, de conserver des séparation nette entre les systèmes, d'accorder une attention particulière à la direction projet et de fixer des objectifs réalistes pour le remplacement du système existant. existant.

Answer 4

Le nom de la vieille école pour cela est "wrapper". Cela a l'air génial ; qui veut s'embêter avec l'ancienne application quand on peut écrire quelque chose de nouveau et de propre pour l'isoler ? Le problème est que cela crée une couche de gluant, et il ne faut pas longtemps avant que quelqu'un décide que le wrapper lui-même est désordonné. Quelle est la solution à ce problème ? Un autre emballage ? De mon point de vue, de tels wrappers et "étrangleurs" finissent par blinder l'application originale et finissent par vous rendre la vie plus difficile. Mais les gens choisissent souvent des solutions à court terme qui sont sous-optimales à long terme. Après tout, personne ne le remarquera avant que vous ne soyez parti depuis longtemps.

Answer 5

D'après mon expérience, le moteur de cette démarche est d'ajouter des fonctionnalités supplémentaires plutôt que de rendre obsolète la base de code originale. Une fois que la nouvelle fonctionnalité a été ajoutée, l'analyse de rentabilité immédiate pour réaliser le changement est affaiblie et l'élan est perdu. Bien entendu, cela ne doit pas se produire et vous devez dès le départ prévoir d'éviter cela.

Salutations