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 sources de données que j’utilise ont trop d’impacts, directs ou indirects, sur le projet

Situation 1

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’équipe qui développe l’API communique peu avec celle qui réalise l’application et utilise l’API.

Problématique : Ce défaut de communication entraîne des frustrations du côté des développeurs front car ils ne sont pas prévenus des breaking changes réalisés sur l’API entre deux livraisons. Ces changements rendent inutilisable l’application et la base de code doit être modifiée à tous les endroits où ces changements ont un effet.

Situation 2

Un ancien collègue est développeur fullStack sur un backoffice permettant de gérer des réunions via un calendrier interactif (gestion de l’ordre du jour, des participants, etc.). Il n’a pas la main sur la base de données qui possède des champs peu explicites et des préfix sur leur nom.

Problématique : La présence de préfix sur les champs ajoutée à des noms peu clairs, engendre de la pollution visuelle ainsi que des incompréhensions possibles s’ils sont directement utilisés dans le code.

Situation 3

Je suis chef de projet dans le secteur médical et, avec l’aide d’un prestataire, nous réalisons un progiciel pour des pharmacies d’hôpital. Ce progiciel est architecturé autour d’une base de données Oracle.

Problématique : Le prestataire demande un environnement de test avec une base de données Oracle afin de débuter ses développements. Je dois payer une coûteuse licence Oracle dès le début alors que le projet vient à peine de commencer et n’est pas encore en production.

Problématique commune

Ces trois situations montrent que les sources de données peuvent avoir des effets directs sur le quotidien du projet (situation 1 et 2). Dans la première situation, les développeurs doivent adapter rapidement leur code pour continuer leurs tâches. Il y a deux problématiques : le manque de communication et

les breaking changes. Le premier n’étant pas technique, uniquement le second sera abordé.

Dans la deuxième, le développeur devrait utiliser les noms définis dans la base de données dans son code.

Mais aussi des impacts indirects du point de vue des développeurs de la situation 3. En effet, payer une licence dès le début du développement peut avoir un impact non négligeable sur le budget du projet, surtout si cette phase dure plusieurs mois.

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

Un peu de théorie

Ne pas calquer le code sur le modèle de données de la source mais au contraire venir le contraindre aux structures de données définies dans l’application.

Ainsi, notre code se rend indépendant de la source car il connaît uniquement ses propres structures de données.

Côté pratique

Créer des entités métiers connues uniquement de notre code puis faire correspondre le modèle de données de la source à nos entités.

Situation 1 : L’application étant réalisée autour des entités qui sont définies pour mon code, le mapping entre les deux mondes se fait à un seul endroit. Lors de breaking changes, par exemple un renommage de champs, uniquement le fichier réalisant la correspondance est touché et non toute la base de code.

Situation 2 : Au même titre que la situation précédente, il y aura un mapping entre les deux mondes. Le développeur peut ainsi utiliser les noms qu’il souhaite dans son code, sans être dépendant de ceux présents dans la base.

Situation 3 : En isolant l’application d’Oracle, il est possible de construire une version autonome (cf. l’article : Gestion des dépendances extérieures) puis venir connecter Oracle en temps voulu, voire décider de changer de base de données.

Avantages

• Permet de reporter des décisions d’architecture (comme un choix de base de données)
• Le code devient plus facilement testable
• Maîtrise des données présentes dans l’application
• Peut faire faire des économies sur les coûts de licence
• Étaler les difficultés au cours du développement

Inconvénients

• Au début, réussir à ne plus travailler directement avec les données fournies par la source
• Découvrir des difficultés liées à la source de données plus tard dans le projet. La mise en place de tracer bullets qui est une approche visant à écrire un minimum de code sur une partie complexe et/ou inconnue d’une application, cela permet de déminer le terrain. À la différence d’un prototype, le code est destiné à rester et à évoluer.

Le prochain article de la série s’articule autour des arborescences de répertoires et fichiers hétérogènes entre les projets.