De l'héritage logiciel à l'opportunité stratégique : le point de départ (I)

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!