Classification des composants¶
Vue d'ensemble¶
La migration de la Platform repose sur une règle simple :
aucun composant n'est intégré dans la nouvelle Platform sans avoir été préalablement classifié.
Cette classification permet de distinguer les composants qui doivent être conservés, adaptés, réécrits ou supprimés.
Elle constitue l'une des étapes obligatoires de la méthodologie de migration.
Pourquoi classifier¶
Le plugin historique contient plusieurs années de développement.
Tous les composants n'ont pas la même valeur.
Certains représentent le cœur du métier.
D'autres correspondent à des optimisations ponctuelles, des patchs historiques ou des contraintes aujourd'hui disparues.
La classification permet de prendre des décisions cohérentes et documentées.
KEEP¶
Définition¶
Le composant est déjà compatible avec la nouvelle Platform.
Il peut être conservé avec peu ou pas d'adaptation.
Critères¶
Le composant :
- possède une responsabilité claire ;
- ne dépend pas fortement de l'ancienne architecture ;
- est correctement structuré ;
- reste pertinent dans la nouvelle Platform.
Exemple¶
Un helper générique indépendant de WordPress.
MIGRATE¶
Définition¶
Le composant est utile mais son intégration doit être adaptée.
La logique métier est conservée.
Son emplacement ou son organisation évoluent.
Critères¶
Le composant :
- apporte une valeur métier importante ;
- dépend encore de l'ancienne structure ;
- nécessite une adaptation avant intégration.
Exemple¶
Un service métier appelé depuis l'ancien Runtime mais qui sera déplacé dans un Module Platform.
REWRITE¶
Définition¶
La logique métier est conservée.
Le code est entièrement réécrit.
Cette approche est souvent préférable lorsque plusieurs années de patchs ont rendu le composant difficile à maintenir.
Critères¶
Le composant :
- est fortement couplé ;
- contient de nombreux patchs successifs ;
- mélange plusieurs responsabilités ;
- n'est plus compatible avec l'architecture cible.
Exemple¶
Une grosse classe historique mélangeant normalisation, scoring, persistance et logs.
LEGACY¶
Définition¶
Le composant reste utilisé uniquement pendant la période de transition.
Il n'est pas destiné à faire partie de la Platform finale.
Critères¶
Le composant :
- est encore appelé par le Runtime historique ;
- ne peut pas être supprimé immédiatement ;
- sera remplacé progressivement.
Important¶
Un composant LEGACY n'est jamais considéré comme terminé.
Son objectif est de disparaître.
DELETE¶
Définition¶
Le composant n'apporte plus de valeur.
Il sera supprimé lorsque toutes les conditions de sécurité seront réunies.
Critères¶
Le composant :
- n'est plus appelé ;
- est remplacé ;
- est devenu obsolète ;
- constitue un doublon ;
- correspond à un ancien test ou à un ancien patch devenu inutile.
Cas particulier des patchs¶
L'ancien plugin contient de nombreux patchs.
Chaque patch doit être analysé indépendamment du fichier qui le contient.
Un même fichier peut ainsi contenir :
- une logique métier à conserver ;
- un patch à supprimer ;
- un second patch à réécrire.
La classification s'applique donc aussi aux patchs individuels.
Cas particulier des dépendances¶
Un composant peut sembler propre tout en dépendant fortement de l'ancienne architecture.
Dans ce cas, il ne pourra généralement pas être classé KEEP.
La dépendance devra être supprimée ou remplacée avant son intégration.
Critères de décision¶
Avant toute classification, plusieurs questions doivent être posées.
Valeur métier¶
Le composant apporte-t-il une valeur réelle ?
Utilisation¶
Est-il encore appelé par le Runtime ?
Simplicité¶
Peut-il être simplifié ?
Modularité¶
Respecte-t-il les principes de la nouvelle Platform ?
Dette technique¶
Le composant est-il principalement constitué de patchs historiques ?
Compatibilité¶
Peut-il être intégré naturellement dans l'architecture cible ?
Objectif¶
L'objectif de cette classification n'est pas de conserver le maximum de code.
L'objectif est de conserver uniquement ce qui mérite de faire partie de la Platform.
Chaque composant doit gagner sa place dans la nouvelle architecture.