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.

Je suis contraint par des dépendances extérieures quand je développe

Situation 1

Je réalise l’interface d’un back office pour la création de tickets d’entrée à des événements. L’API, sur laquelle je dois me connecter, n’est pas encore commencée.

Problématique : Les développements de l’application doivent commencer avant que l’API ne soit disponible.

Situation 2

Je suis Product Owner et mon équipe réalise une application mobile 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. L’API, sur laquelle ils doivent se connecter, est accessible mais instable (changement dans les données disponibles, problèmes de performance, indisponibilité, …)

Problématique : Les instabilités entraînent d’une part une fragilité sur les données utilisées et d’autre part un rythme saccadé, dû aux performances de l’API, dans le développement de l’application.

Situation 3

Je réalise une API qui expose des numéros de commande aux clients, afin de générer des QR Codes. Les développeurs de ces clients doivent gérer certains cas marginaux de leur côté.

Problématique : Il est difficile de trouver des jeux de données sur des cas complexes et/ou marginaux, permettant de vérifier le bon affichage sur un téléphone mobile.

Situation 4

Je réalise un back office permettant de gérer les roulements et renforcements du personnel soignant d’établissements de santé. Le jour de la démonstration au client, l’API est inaccessible.

Problématique : Assurer la présentation du travail réalisé durant l’itération au client, même avec des données dégradées.

Problématique commune

Ces situations montrent qu’à plusieurs niveaux, chacun peut être lié à des dépendances extérieures et cela engendre des frustrations : - Chez les développeurs car ils/elles ne peuvent pas travailler dans de bonnes conditions (changer constamment leur code, attendre 30 secondes la réponse de l’API, difficulté à trouver des données spécifiques, …) - Chez les coordinateurs (managers, chef de projet, etc.) qui entendent : « Je ne peux pas commencer la fonctionnalité car X n’est pas prêt », « on ne peut pas assurer la démonstration car une dépendance extérieure est en panne ».

“Mon code doit être indépendant des acteurs dont il n’assure pas le contrôle.”

Un peu de théorie

Nous allons définir des contrats d’interactions (exemple : des interfaces dans les langages orientés objet) entre notre code et ses dépendances extérieures. Cela va permettre d’être découplé des implémentations du contrat durant le développement.

Par ce biais, les dépendances sont inversées : au lieu d’être lié à ces dépendances extérieures, c’est leur implémentation qui s’adapte à notre code.

On peut voir le contrat comme une prise femelle et les implémentations comme les prises mâles qui viennent s’y connecter.

1 contrat peut avoir ???? implémentations interchangeables.

C'est ici que des techniques comme l'injection de dépendance peuvent être utilisées, pour changer les implémentations sans changer le code qui les appelle.

Côté pratique

Créer manuellement une implémentation du contrat. Ce bouchon fait office de simulation de la dépendance extérieure.

En effet, en utilisant cette technique, cela me permet de répondre aux problématiques vues précédemment :

Situation 1 : En créant ma propre source de données, je peux pallier le décalage de planning et développer la fonctionnalité. Et je connecterai ultérieurement la dépendance extérieure finale quand celle-ci sera prête et sans impacter mon code.

Situation 2 : Par extension à la situation précédente, l’équipe peut développer les fonctionnalités demandées sans être impactée par l’instabilité de l’API. Et l’équipe viendra interchanger les implémentations sans toucher à son code car elles respectent le même contrat.

De plus, cela permet un développement itératif, ce qui évite un mini effet tunnel pour le client. Tout d’abord la version bouchonnée où il pourra visualiser un premier comportement (éventuellement faire des premiers retours), puis la version finale où il accédera à la totalité de la fonctionnalité.

Situation 3 : Travaillant sur des jeux de données que je maîtrise, je peux simuler aisément des cas marginaux et/ou complexes.

Situation 4 : En co-construisant l’application avec ma source de données simulée, je m’assure d’avoir un projet fonctionnel en tout temps.

Avantages

• Respect d’une bonne pratique de développement (inversion des dépendances - D de S.O.L.I.D)

• Rapidité et simplicité de la mise en place des bouchons

• Evolutivité et maintenabilité des bouchons

• Le code devient plus facilement testable

• Permet de travailler dans toutes les conditions Exemple : dans l’avion sans Internet

• Permet d’avoir une version du projet toujours fonctionnelle Exemple : l’API est inaccessible le jour de la démo

• Permet de développer sans être connecté tout le temps à l’API

• Facilite la simulation de cas complexes et/ou marginaux

Inconvénients

• Assurer une cohérence des données entre les bouchons
• Créer du code sans utilité fonctionnelle directe
• Les testeurs ont potentiellement deux recettes à faire de la fonctionnalité

Le prochain article de la série s’articule autour de la limitation des impacts qui sont engendrés par des mises à jour structurelles dans le framework utilisé.

Projet IT : S’adapter à un monde qui change - Gestion des mises à jour des frameworks