Refactoring des logiciels existants?: des défis aux opportunités

Cet article explique comment nous gérons l'internationalisation d'un système de gestion logistique (OMS) et les défis de l'intégration avec les nouvelles plateformes de commerce électronique. Le système a été développé en 2018 pour optimiser le processus de préparation des commandes d'une entreprise de commerce électronique en plein essor et s'intégrer efficacement avec différents opérateurs logistiques. Construit à l'aide de PHP (Symfony), MySQL, Socket.io et jQuery, il couvre l'ensemble du processus, de l'emballage à l'expédition, y compris des fonctionnalités telles que le suivi des commandes, les connexions de messagerie, la génération d'étiquettes et les mesures de performances de préparation des commandes.

L'accumulation de dette technique

Ce système a bien fonctionné pendant de nombreuses années, mais à mesure que l'entreprise se développait, ses limites sont devenues de plus en plus apparentes. La dette technique est particulièrement inquiétante, car elle affecte plusieurs niveaux d’un projet. En termes d'infrastructure technique, l'application fonctionne sur des frameworks et des versions linguistiques de base obsolètes?:

• La version Symfony (4.0) n'est pas une version de support à long terme (LTS) et ne recevra plus de mises à jour de sécurité à partir de janvier 2019.
• PHP 7.1 a également terminé son cycle de vie et le système manque de mises à jour de sécurité critiques.

En plus des versions obsolètes, le projet présente également de sérieuses failles dans les fondamentaux du développement logiciel?:

• Manque ou insuffisance de tests?: Un manque de tests automatisés (tests unitaires, d'intégration et de bout en bout) entrave non seulement la détection précoce des bugs, mais rend également toute modification susceptible de compromettre la stabilité du système.
• Manque de normes de codage?: La base de code ne suit aucun modèle ou norme documenté, et même s'il existe, ils ne sont pas conformes aux meilleures pratiques de l'industrie. Cela rend difficile à la fois la maintenance et l’intégration de nouveaux développeurs dans le projet.
• Documentation inadéquate?: La documentation existante est rare et souvent incomplète. Cela affecte non seulement le développement technique mais également la compréhension des processus métier implémentés dans le code.
• Contr?le de version incomplet?: L'historique de Git manque d'explications, la granularité des commits est approximative, les messages ne suivent aucune convention et manquent d'informations générales sur les modifications apportées. Cela rend difficile la compréhension de l’évolution du code et des décisions prises au fil du temps.

L'accumulation de dette technique constitue non seulement une menace pour la stabilité et la sécurité du système, mais aussi :

• Réduction de la vitesse de développement des nouvelles fonctionnalités
• Risque accru d'introduction de bugs
• Augmentation de la difficulté pour les nouveaux membres de rejoindre l'équipe
• Augmentation des co?ts de maintenance
• Complique le diagnostic et la résolution des problèmes

Limites structurelles

L'architecture d'origine présentait des problèmes de couplage qui affectaient sérieusement sa flexibilité et son évolutivité?:

• Entièrement dépendante de la plateforme e-commerce principale?: L'application ne peut pas fonctionner de manière indépendante, et toutes les opérations logistiques dépendent directement des données et des processus de la plateforme e-commerce. Cela signifie que toute modification apportée à la plate-forme principale peut interrompre la fonctionnalité du système.
• Base de données partagée entra?nant des problèmes de performances?: Les applications logistiques et les plateformes de commerce électronique utilisent la même base de données, ce qui entra?ne des problèmes de performances, en particulier pendant les périodes de charge de pointe pour l'une ou l'autre application. De plus, cette configuration complique la gestion des autorisations car tout accès à la base de données peut compromettre des données importantes provenant d'autres systèmes.
• Ne peut pas fonctionner de manière autonome?: Cette application est con?ue pour fonctionner uniquement avec les plateformes de commerce électronique. Non seulement cela limite sa portabilité, mais cela empêche également les tests dans un environnement isolé ou la migration vers d'autres plates-formes. Ses dépendances ne sont pas correctement encapsulées, toute tentative d'isolation nécessiterait des modifications importantes et co?teuses dans l'ensemble du système, et le principe de responsabilité unique (SRP) n'est pas respecté dans la classe principale.
• Difficulté à mettre en ?uvre de nouvelles fonctionnalités : Le manque de respect du principe d'ouverture/fermeture (OCP) et du principe de substitution de Liskov (LSP) freine grandement l'évolution du système. Les nouvelles fonctionnalités nécessitent des modifications du code existant, augmentant ainsi le risque d'introduire des régressions. De plus, les dépendances directes entre les modules rendent presque impossible le respect du principe d'inversion de dépendance (DIP).

Ces limitations structurelles réduisent non seulement la maintenabilité et l'évolutivité du système, mais augmentent également les risques associés à toute modification ou évolution, laissant l'application dans un état techniquement fragile et stratégiquement vulnérable.

Gestion du développement et alignement stratégique

L'un des défis les plus importants n'est pas seulement technique, mais aussi stratégique. Bien que le développement externe soit fonctionnellement correct, il existe des limites organisationnelles importantes?:

• Déconnecté de la stratégie globale?: Le développement se fait en silos sans une compréhension complète des objectifs et des processus internes de l’entreprise. Il en résulte des fonctionnalités qui, bien que techniquement correctes, ne répondent pas toujours aux besoins réels de l'entreprise.
• Manque de priorisation stratégique?: La mise en ?uvre de nouvelles fonctionnalités manque d'un processus clair d'évaluation et de priorisation. Il n’y a aucun doute quant à savoir si une fonctionnalité est vraiment nécessaire, si c’est la meilleure fa?on de la mettre en ?uvre ou s’il existe une alternative plus efficace.
• Développement réactif vs développement proactif?: Le développement suit principalement un modèle réactif, répondant aux besoins immédiats sans tenir compte des impacts à long terme ou des synergies potentielles avec d'autres processus de l'entreprise.
• Manque de processus de validation?: L'absence d'un processus structuré d'examen et de validation entra?ne des fonctionnalités qui, bien que fonctionnant, ne fournissent pas toujours la meilleure solution pour l'utilisateur final ou pour les objectifs généraux de l'entreprise.

Cette situation est intenable à long terme car elle :

• Ce qui donne lieu à des produits de plus en plus éloignés des besoins réels
• Entrave l'intégration avec d'autres systèmes et processus de l'entreprise
• Complique les décisions stratégiques concernant les produits
• Limite la capacité de l’équipe à innover et à s’améliorer continuellement

Impact des co?ts de base

Un aspect souvent négligé mais particulièrement important dans ce projet est le co?t de base, qui, à mon avis, est un concept clé dans le développement de logiciels et fait référence au co?t de maintien d'un système en fonctionnement même sans ajouter de nouvelles fonctionnalités ou apporter des améliorations minimales requises.

Dans notre cas, les co?ts de base incluent tous les co?ts associés à la maintenance d'un framework et de versions linguistiques obsolètes, à la résolution des urgences dues à l'accumulation de dette technique, à la gestion des dépendances avec d'autres systèmes, à l'adaptation à des architectures couplées et aux co?ts de connaissance du domaine encourus en raison d'une compréhension insuffisante. . Tout cela consomme une quantité importante de ressources disponibles et a un impact direct sur la capacité à investir dans l’innovation et l’amélioration continue.

Bien que ce facteur n'ait pas été décisif dans notre décision d'internaliser le développement, il a été assez influent dans le diagnostic initial du projet. Les co?ts de base sont souvent ignorés lors de l’évaluation de la durabilité d’un système, mais dans ce cas, cela démontre clairement que les stratégies actuelles ne sont pas viables à long terme. De plus, comme nous le verrons dans les articles suivants, toute tentative de maintenir la structure existante augmentera de fa?on exponentielle le co?t de base au fil du temps.

Pour une explication plus détaillée des concepts de base des co?ts et de leur importance, il est recommandé de se référer à l'article original d'Eduardo Ferro.

Tournant?: nouveaux défis et décisions stratégiques

Dans tout projet de refactoring, plusieurs stratégies peuvent être employées, et le dilemme est souvent rencontré : fig étrangleur ou réécriture big bang.

La décision technique initiale était de travailler au sein du même projet existant en utilisant le Strangler Pattern, une approche qui implique le développement d'un nouveau module ou système qui remplace progressivement des parties de l'ancien système. Cette stratégie nous permet d'apporter des changements parallèles, de réduire les risques et de maintenir les fonctionnalités actuelles tout en construisant une base plus solide pour prendre en charge les fonctionnalités futures.

Cependant, d'un point de vue commercial, cette option présente un risque excessif pour le système existant (qui est déjà opérationnel et remplit ses fonctions). Nous avons décidé d'éviter de toucher au projet existant et de développer plut?t une application autonome pour répondre aux nouveaux besoins.

Ce changement nous a amené à bifurquer de la base de code existante, une décision qui était techniquement réalisable mais présentait certains inconvénients?:

• Duplication des bases de codes : Deux bases de codes distinctes doivent désormais être maintenues.
• Séparation des bases de données?: les structures de données doivent être copiées et adaptées pour chaque système.
• Réplication de l'infrastructure?: nécessite le déploiement de serveurs indépendants et la garantie d'une observabilité appropriée pour chaque système.
• Charge cognitive accrue sur l’équipe : Toute cette duplication nécessite des efforts supplémentaires pour maintenir la cohérence entre les deux systèmes, augmentant ainsi la complexité de l’équipe et le risque d’erreurs.

Cette approche nous permet d'évoluer vers des solutions indépendantes, assurant la stabilité des systèmes existants tout en développant un projet aligné sur de nouveaux objectifs stratégiques. Cependant, une analyse détaillée des avantages et des inconvénients est nécessaire pour planifier et relever ce défi en toute confiance. De plus, nous sommes parvenus à un consensus avec le niveau commercial pour ne pas étendre les fonctionnalités et contr?ler étroitement le retard du projet jusqu'à ce que la migration vers la nouvelle plateforme de commerce électronique soit terminée.

Conclusion et prochaines étapes

La décision d'internaliser et de réécrire un logiciel existant n'est jamais facile, surtout lorsque le logiciel est capable de faire son travail. Le dicton ? Si ?a marche, n’y touchez pas ? sera toujours là. Cependant, il faut parfois un pas en arrière pour faire deux pas en avant.

Dans les articles suivants de cette série, nous explorerons comment nous avons répondu à ces défis, les décisions techniques et stratégiques que nous avons prises et comment nous avons transformé ces défis en opportunités d'amélioration et de développement d'équipe.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!