Construisez une base de code OpenEdge saine et réduisez la dette technique

Les applications commerciales stimulent les opérations principales de nombreuses organisations, et pour celles construites sur les progrès OpenEdge, des décennies de service continu et d’adaptation sont la norme. Mais avec les avantages de la maturité, venez des questions pressantes: comment gardez-vous votre base de code sous-jacente à mesure que les exigences évoluent? Quelle est la meilleure façon de répondre à la dette technique et de préparer vos systèmes pour un succès futur, d’autant que vous passez à de nouvelles plateformes comme OpenEdge 12?

Dans notre webinaire, Dans la conversation: construire une base de code OpenEdge saineRoland de Pijper de Progress et Tibor Lapikas de Groupe d’amélioration des logiciels (SIG) discuté de ces sujets, en fournissant des conseils, des exemples du monde réel et des recommandations pratiques. Le webinaire s’est concentré sur les approches de création et de maintien d’une base de code OpenEdge, en utilisant l’IA comme outil de codage et en résolvant les problèmes actuels de l’industrie.

Tibor Service de directeur des partenaires chez Software Improvement Group (SIG) où il soutient les clients et les partenaires dans l’intégration de normes élevées pour la qualité et la sécurité des logiciels. Avec une solide expérience en génie logiciel et en conseil, Tibor a passé plus de 10 ans à aider les entreprises à construire des systèmes sécurisés, fiables et maintenables, en se concentrant sur la transformation de la gestion pratique de la qualité des logiciels en résultats commerciaux.

Roland de Pijper est un consultant principal principal chez Progress Professional Services et fait partie des progrès depuis 1995. Basée à Rotterdam, Roland est un conseiller reconnu des clients du monde entier, les aidant à adopter les dernières technologies OpenEdge et à naviguer sur les voyages de modernisation sans sacrifier la continuité des affaires.

Au début de la conversation, Roland souligne que les applications OpenEdge ont souvent un long héritage. «Nos bases de données fonctionnent solides et nous sommes toujours compatibles en arrière. Donc, même votre code de version 4 s’exécutera toujours dans OpenEdge 12.» Cette compatibilité remarquable offre la liberté mais aussi le risque. Des années de changements urgents, d’améliorations progressives et de patchwork critique peuvent laisser des parties de la base de code emmêlées et difficiles à maintenir.

Lorsque la qualité du code baisse, votre capacité à innover également. Les problèmes persistent, la livraison ralentit et la dette technique se glisse, en prenant finalement du temps au nouveau développement et en menaçant votre capacité à répondre aux besoins de l’entreprise.

Tibor décrit la dette technique comme «toute maintenance que vous n’avez pas faite sur votre base de code». Il explique deux types communs:

• Complexité au niveau du code: Fonctions avec trop de points de décision, une logique profondément imbriquée ou une structure claire. «Cela se produit en ligne par ligne… un petit« solution rapide »à la fois», note Tibor, «mais si vous continuez à reporter le nettoyage, finalement votre cuisine est très désordonnée et cela va prendre beaucoup de temps à nettoyer.»
• Complexité architecturale: Au fil du temps, les équipes ajoutent des modules et des dépenses croisées sans séparation claire, ce qui rend risqué de changer une zone sans impact inattendu ailleurs.

Roland renforce que la pression réelle de l’entreprise intensifie le problème: «Quand le client en a-t-il besoin? En ce moment. Nous devons l’implémenter dès que possible et la qualité du code en souffrera.» Les meilleures pratiques peuvent être ignorées par souci de livraison et, au fil du temps, ces compromis se composent dans une dette technique importante qui devient plus difficile à détendre.

La mesure et l’analyse comparative de la qualité du code sont essentielles, surtout lorsque les organisations souhaitent guider les améliorations et suivre les progrès au fil du temps. Tibor présente la méthode de quantification de la maintenabilité de SIG avec un système de note d’étoile qui varie de un à cinq. «Trois étoiles sont en moyenne du marché», explique-t-il, donnant aux équipes un point de comparaison clair avec leurs pairs. La recommandation générale: visez quatre étoiles à trouver un bon équilibre entre l’agilité et la maintenabilité à long terme.

Les utilisateurs d’OpenEdge peuvent découvrir cette approche de qualité du code objectif à travers le Service de gestion de la qualité et de la sécurité des applications (QSM). Le service QSM, propulsé par l’expertise analytique de la plate-forme Sigrid de SIG, offre des informations profondes et basées sur les données sur la structure, la maintenabilité et la sécurité d’une base de code OpenEdge. En analysant le code OpenEdge contre l’une des plus grandes bases de données de l’industrie au monde, QSM fournit des conseils transparents et exploitables pour les chefs d’entreprise et de développement. Au lieu de deviner où se concentrer ou s’appuyer sur le sentiment intestinal, les équipes reçoivent une feuille de route claire pour lutter contre la dette technique et hiérarchiser les modifications qui auront le plus d’impact, avec des conseils et un soutien des services professionnels progressistes et des normes mondiales d’assurance logicielle établies par SIG.

Surtout, Tibor met en garde contre la révision de tout dans une base de code une fois: « Si vous voulez passer de deux et demi à quatre étoiles à la fois, c’est un effort énorme. » Au lieu de cela, les équipes devraient se concentrer sur l’amélioration des domaines avec les plus grands rendements, en appliquant des normes de qualité supérieure au nouveau code et en ciblant les points chauds qui voient les changements ou les défis les plus fréquents.

Les deux orateurs conviennent que l’amélioration progressive et continue est la clé. Roland suggère d’utiliser des cycles de sprint: «Réservez un certain pourcentage de votre temps dans chaque sprint. Essayez de hiérarchiser ces problèmes et, chaque sprint, prenez du temps supplémentaire juste pour résoudre ce genre de problèmes. Si vous travaillez dans une partie de votre code et sachez que quelque chose doit s’améliorer, appliquez la règle de Boy Scout: laissez le code un peu mieux que vous l’avez trouvé.»

Leur conseil fait écho à un mantra de bon sens: n’essayez pas de faire bouillir l’océan. Fixez des objectifs réalistes, concentrez-vous sur les zones à fort impact et permettez aux développeurs de faire des améliorations progressives dans le cadre de leur travail quotidien.

La conversation se tourne ensuite vers la promesse et les limites des assistants de codage de l’IA, des outils qui tirent parti de l’intelligence artificielle pour aider les développeurs à écrire du code, à automatiser les tâches répétitives et même à suggérer des tests ou des améliorations. Alors que ces assistants deviennent de plus en plus qualifiés, non seulement générant des fonctions mais soutenant également des tâches architecturales plus larges, Roland et Tibor soulignent que l’IA n’est qu’une partie du paysage de développement.

L’expertise humaine, la revue et la collaboration continue restent au cœur de la création de logiciels de haute qualité, l’IA servant de complément précieux plutôt que d’une solution complète. «Les agents de l’IA ne sont pas une solution miracle», explique Roland. «Les développeurs doivent être en contrôle.» Tibor souligne que les outils d’IA sont les plus efficaces lorsque les développeurs expérimentés les utilisent judicieusement et lorsque les organisations investissent dans la formation et le déploiement progressif.

Les progrès fonctionnent dans cet espace, offrant des solutions comme QSM qui non seulement analysent le code pour la qualité et la sécurité, mais peuvent être connectées aux agents d’IA pour des commentaires automatisés directs. Pourtant, le code que vous générez avec l’IA doit être validé pour éviter de nouvelles dettes techniques ou de nouvelles problèmes de sécurité. L’approche la plus efficace est «humain dans la boucle» – en gardant les développeurs responsables de l’acceptation finale, de l’examen et de l’amélioration continue.

Chaque base de code OpenEdge est unique, mais le chemin de la santé soutenue est remarquablement similaire:

• Sensibiliser à la dette technique et à son impact
• Mesurer et la qualité du code de référence avec des objectifs clairs
• Améliorations de la mise au point sur les nouveaux code et les points chauds clés
• Prioriser les correctifs en cours et incrémentiels aux côtés de nouvelles fonctionnalités
• Utilisez l’IA et l’automatisation pour aider, et non les développeurs réfléchis,
• Tendez la main aux experts en solutions et tirez parti des outils d’évaluation lorsque des changements architecturaux plus profonds sont nécessaires

Comme le dit Tibor, «l’IA jouera un rôle plus important dans le travail réel de générer le code, mais ce qui se passe et ce qui doit être fait sera toujours principalement motivé par les développeurs eux-mêmes.» Le résultat? Des perspectives plus lumineuses pour les équipes OpenEdge sans avoir à sacrifier la stabilité, la continuité ou l’innovation.

C’est maintenant un excellent moment pour commencer. Même les petits changements, guidés par les bonnes mesures et les outils, peuvent faire une grande différence à long terme. N’hésitez pas et ne faites pas cavalier seul. Contactez l’équipe de services professionnels de Progress Pour en savoir plus sur la qualité des applications et la gestion de la sécurité pour soutenir la santé de votre base de code OpenEdge.