Voilà plusieurs années que je travaille dans le monde des projets informatiques, tout d’abord dans le rôle du client (MOA et Product Owner) et maintenant en tant que membre de l’équipe de développement. J’ai pu constater que plusieurs points de souffrance apparaissent très (trop) régulièrement mais depuis quelques temps déjà, j’arrive à les devancer.

Nous allons voir comment.

Disclaimer

L’article fait partie de la série Projet IT : S’adapter à un monde qui change. Dans chacun de ces articles, je vous propose des retours d’expériences sur des situations ayant une problématique proche et où je présente un moyen de l’éviter. Au risque de décevoir certaines personnes, il n’y aura pas de code dans cette série.

Les mises-à-jour du framework sont douloureuses ou parfois impossibles

Situation 1

Je suis Product Owner d’une application permettant aux utilisateurs de visualiser les événements liés à leur contrat, les détails de celui-ci et trouver des points de service (parking, station essence, garage, …) autour d’eux. Nous cherchions à faire peau neuve du visuel tout en gardant le même périmètre fonctionnel.

Problématique : Le code de l’application était fortement couplé à AngularJS et à son architecture. De plus, Google avait revu complètement son framework tant d’un point de vue structurel que technologique, en sortant Angular2.

Situation 2

Je suis Tech Lead sur un projet mobile en React Native qui permet de visualiser des événements autour de soi.

Problématique : L’application doit également être déclinée en back office puis en site Internet, avec le même périmètre fonctionnel.

Problématique commune

Ces situations montrent que les projets évoluent, que parfois il faut faire évoluer la technologie car elle devient vieillissante. En effet l’éditeur ayant sortie une nouvelle version, a arrêté de faire des évolutions, ne rajoute plus de fonctionnalités, etc. (situation 1), ou d’autres fois il faut ajouter un nouveau canal de communication (situation 2), sans changer le fonctionnel.

“Les points d’entrées de mon application ne possèdent aucune règle métier.”

Un peu de théorie

Les situations précédentes permettent de mettre en avant au moins deux parties biens distinctes dans les applications :

• Les règles métiers
• Les consommateurs de ces règles

Chaque partie a besoin de pouvoir évoluer à des rythmes différents, et pour des raisons qui leurs sont propres. Par conséquent, je souhaite les rendre indépendantes les unes des autres.

Côté pratique

Je rends les règles métiers agnostiques de tout choix technique (framework, librairie, API, etc). Elles ne dépendent alors que de leur matière première : le langage de programmation lui-même. Exemples :

• JavaScript pour Angular, React, Express, …
• Java pour Spring Boot, Play, …
• PHP pour Symfony, Zend, Doctrine, …
• etc.

Et elles doivent proposer une API simple (masquant la complexité) à ses consommateurs.

En revanche, je me sers des outils qui sont proposés par les frameworks, les librairies, etc. , pour construire les parties périphériques, comme la gestion des routes, l’affichage des données, etc.

En effet, utiliser ces techniques me permet d’enlever une grosse difficulté au moment des évolutions, car uniquement les consommateurs seront éventuellement à adapter.

Situation 1 : Le jour où le changement de la charte graphique fut actée, le constat a été simple, il fallait tout redévelopper.

En utilisant partout le framework et en mélangeant les deux parties, mon équipe s’était tirée une balle dans le pied. En effet, nous étions complètement dépendants des évolutions d’AngularJS et des décisions de Google.

Nous avons dû annoncer à notre sponsor qu’un changement de design qui pouvait prendre 2 à 3 mois, nécessitait une refonte complète de l’application de 7 mois.

Qui dit refaire de zéro dit également redéveloppement des règles métiers et son lot d’erreurs potentielles. Les 2 derniers mois furent très longs et douloureux.

Situation 2 : En isolant correctement les règles métiers de ses consommateurs, la création du site s’est mieux déroulée.

En effet, j’ai uniquement eu à adapter les consommateurs et à configurer correctement la librairie choisie, en l’occurrence React, sans toucher aux règles métiers.

Avantages

• Respect d’une bonne pratique de développement (responsabilité unique — S de S.O.L.I.D)
• Evolutivité indépendante des parties
• Les fichiers sont plus courts
• Les règles métiers sont plus facilement testables car non couplées à des frameworks

Inconvénients

• Au début, réussir à bien séparer les règles métiers de ses consommateurs
• Un peu plus de configuration pour les frameworks imposant une structure précise

Le prochain article de la série s’articule autour de la dissociation du coeur de l’application de ses sources de données.

Projet IT : S’adapter à un monde qui change — Gestion des sources de données