Vous devez ajouter des fonctionnalités dans un vieux langage? Pourquoi ne pas sortir des sentiers battus?!
Bien sûr, il est toujours agréable de démarrer un nouveau projet. On choisit l’architecture et les technologies tout en tenant compte des besoins actuels et futurs du client. Cependant, ce ne sont pas tous les projets pour lesquels on part de zéro ou qui voient le jour dans le contexte d’une refonte. Il peut arriver qu’un client ait une application qui contient un certain bagage et qu’il désire simplement y ajouter une fonctionnalité. Cela implique aussi que la techno peut être vieillissante. C’est ainsi que la pérennité logiciel est très importante.
Vous devez ajouter des fonctionnalités dans un vieux langage? Pourquoi ne pas sortir des sentiers battus?!
Ainsi, la vision qui était valable au départ du projet peut ne pas avoir suivi l’évolution de la compagnie, et la structure du projet peut faire en sorte de rendre difficile l’utilisation des meilleures techniques de programmation telles que le TDD (développement orienté par les tests).
Chez DONE, nous avons vécu une situation similaire. Dans ce cas précis, le projet était codé dans le langage ASP classique. On ne parle pas ici d’ASP.Net, mais bien de son ancêtre, qui a vu le jour en 1996. Même si le langage en soi était vieillissant, le projet avait toujours une bonne valeur pour le client, ce qui explique pourquoi il était encore en utilisation à ce moment – et qu’il l’est encore aujourd’hui d’ailleurs.
Notre mission
Nous avons reçu comme mandat de développer une interface pour envoyer des demandes vers des systèmes partenaires en XML et en JSON.
Nos défis
Le premier problème que nous avons anticipé a été que JSON n’existait pas lors du lancement d’ASP, donc nos chances de trouver une librairie pour faire le travail étaient plutôt faibles. La structure des données à envoyer étant très complexe, il était aussi hors de question de construire cette chaîne à partir de bouts de textes concaténés. De plus, même si nous aurions pu nous adapter au langage, le fait que peu de développeurs sont familiers avec celui-ci aujourd’hui aurait augmenté considérablement le temps de développement.
Notre solution
Plutôt que d’aller dans cette direction, la solution que nous avons retenue a été de développer la fonctionnalité dans un langage récent, que nous connaissons bien et qui est à la fine pointe, c’est à dire .Net Core (C#).
Le vrai défi était donc de passer la « barrière » virtuelle entre le programme développé en ASP et celui en C#. Avec les bons outils de développement, la réalisation du reste du projet serait très facile.
Première étape : isoler notre code
La première étape consistait à isoler notre code dans un fichier ASP qui serait appelé au bon endroit. Ce fichier servirait d’interface à notre projet C# qui, lui, effectuerait le réel appel JSON vers les systèmes partenaires. Ce que nous souhaitions, c’était que l’appel soit le plus simple possible du point de vue du ASP classique et qu’il puisse cacher toute la complexité du côté .Net.
La façon de procéder que nous avons retenue est celle où la communication entre les deux systèmes se fait via de simples requêtes Web.
Voici à quoi ressemblait l’appel fait :
Nous avons choisi d’instancier un objet « MSXML2.ServerXMLHTTP » afin de générer un appel Web qui contiendrait le numéro de la demande à transférer sur le serveur du partenaire. Nous avons alors passé cette variable dans une chaîne JSON. Mais, puisque ce JSON était très minimaliste, il était facile à créer, même en ASP, en concaténant simplement des chaînes de texte. Cela aurait aussi pu être transféré sous forme de « query string ». L’important, c’était d’arriver à passer le plus rapidement et simplement possible vers notre langage plus moderne.
Toutes les informations requises pour la construction du « payload » se trouvaient dans la base de données qui, elle, devait être directement lue par la nouvelle application. L’URL à appeler devait simplement être conservée sous le nom « REQUEST_SENDER_URL » dans un fichier de configuration, dans lequel les configurations importantes seraient conservées.
Et voilà! La portion écrite dans l’ancien langage était déjà terminée.
Seconde étape : générer la structure de données complexe
De l’autre côté de cet appel, on reconnaîtrait donc un contrôleur C# bien standard qui recevrait les informations requises (l’ID de la donnée à envoyer) afin de pouvoir générer la structure de données complexe (soit du JSON ou du XML en fonction du partenaire sélectionné) et qui retournerait une réponse (affirmative ou négative) du partenaire en question pour cette demande.
Puisque nous étions maintenant en terrain connu, nous avons pu sauver énormément de temps et obtenir un logiciel beaucoup plus fiable. Pour la construction du JSON, il était facile de procéder en bâtissant une simple classe et en utilisant l’objet JsonSerializer (System.Text.Json.JsonSerializer.Serialize()) pour procéder à la conversion.
Dans le cas du XML à créer, encore une fois, il a été facile de créer une classe qui représenterait cet objet et de transformer celui-ci à l’aide d’une méthode qui utiliserait le « XmlSerializer » fourni par le langage.
Les avantages
Cela nous a épargné un travail colossal par rapport à s’il avait dû être réalisé en ASP classique, car au bout du compte, la demande générée faisait plus d’une centaine de lignes!
Un autre avantage d’utiliser un langage plus récent pour cette portion de l’application a été que nous avons pu tester le nouveau code de fond en comble à l’aide de tests unitaires et de tests d’intégration. Puisque l’utilisation de tests automatisés n’était pas encore pratique courante lors de la durée de vie utile du ASP classique, les outils permettant de les exécuter n’étaient donc pas existants.
Conclusion : une approche hybride sauve du temps !
Pour finir, avec une solution hybride, il ne faut pas négliger non plus l’avantage d’avoir une partie de code récente et prête à être utilisée dans un autre contexte. Ainsi, si le code ASP devait subir une refonte dans le futur, c’est toute cette partie de logique qui serait déjà faite et qui ne serait donc pas à reconvertir, ce qui diminuerait le coût requis pour procéder.
Et si d’autres fonctionnalités devaient être développées au fil du temps, cela pourrait aussi être fait section par section jusqu’à ce que l’entièreté de l’application soit transférée dans un nouveau langage. Bien entendu, cela aurait été plus complexe s’il avait fallu refaire une partie visuelle de l’application, mais il aurait quand même été pertinent de trouver une façon de procéder afin de bénéficier de tous ces avantages.
Selon nous, cela vaut souvent la peine de sortir des sentiers battus et de segmenter les fonctionnalités dans un langage plus récent, plutôt que de les réaliser dans un vieux langage. Cela permet de proposer une solution qui sera plus maintenable, plus stable et aussi plus économique pour le client, aujourd’hui comme dans l’avenir.
N’hésitez pas à nous consulter pour en savoir d’avantage: connectez avec nous.
Ainsi que nos autres divisions d’affaires : Pyxis
