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.
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 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.
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.
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.
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.
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.
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.
Le prochain article de la série s’articule autour des arborescences de répertoires et fichiers hétérogènes entre les projets.