Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Arnaud Lemaire, Arnaud bonjour.
Hello.
J'adore ton esprit de synthèse, est-ce que tu peux quand même te présenter en plus de quatre mots pour les auditeurs s'il te plaît ?
Alors c'était un mot, ouais alors moi c'est Arnaud Lemaire, Attille de base, je suis développeur, basiquement, sur un peu plein de choses.
Et on peut me retrouver sur Twitter ou sur l'idobas.com.
Cool, merci.
Alors tu m'as proposé un sujet, je sais pas de quoi on va parler, mais le sujet m'a vachement plu donc allons-y, pour moi les doodoo ça me parle, tu me disais, la base de données, enfin redis-moi le sujet que tu m'as proposé.
Ouais en fait c'est une discussion qui revient régulièrement, c'est une image que j'utilisais souvent et c'est revenu encore hier dans une discussion, c'est la base de données en fait, c'est un vrai doodoo pour développeur.
Vas-y, exprime, parce que moi je vois bien ce que c'est un doodoo.
Et là je crois que j'ai enfin trouvé le doodoo de ma fille à deux ans, donc je commence à retrouver des nuits, je vais dire presque normal, c'est quoi le doodoo des développeurs ?
C'est le rassure émotionnellement, c'est quoi le truc ?
C'est ça en fait, c'est un objet de réassurance incroyable en fait, et on s'en rend compte quand justement on intervient dans des équipes et qu'on commence à leur parler de cohérence à terme, de dénormalisation des données,
on sent qu'il y a une crispation qui arrive chez les gens et il y a une espèce de gêne comme ça qui monte, qui monte, jusqu'à... alors des fois ils n'arrivent pas à l'exprimer, des fois ça explose, et ils se demandent oui mais comment est-ce que je fais pour mes transactions, comment est-ce que je fais pour ma base de données, comment est-ce que...
Et tu laissens paniquer, parce qu'en fait t'as touché à un des rares trucs auxquels ils sont habitués qu'ils marchent un petit peu du premier coup, c'est leur schéma de base de données.
C'est-à-dire qu'ils savent qu'au niveau applicatif souvent ça peut être un DAWA monumental, mais les développeurs ont cette espèce de réassurance que... ouais mais au moins c'est dans la base de données, j'ai fait ma transaction, il peut se passer n'importe quoi autour, si ma base de données va bien, le reste va bien.
Et donc quand tu commences à toucher à cet objet et quand tu commences effectivement à aborder ce genre de choses, tu sens un petit peu cette tension apparaître dans les équipes, et c'est quelque chose qui est souvent assez difficile à faire perdre dans un premier temps.
Alors moi j'ai une anecdote personnelle qui date d'il y a quelques jours donc elle est encore très fraîche. Je discute avec une copine d'entrepreneuse, elle me présente son développeur, on discute un petit peu, on essaie de voir si je peux les aider à prendre du recul, enfin je sais pas à faire un truc, voir comment je peux les conseiller un petit peu.
Et justement au moment où on parlait de la base de données, on parle à un moment donné, la nana me dit ah oui puis on a là cette base, c'est du no SQL, est-ce que tu sais ce que c'est ce truc ?
Oui c'est de la donnée des normalisés et là effectivement je vois le développeur pas lire et à la perspective de devoir travailler avec cet objet complètement paniqué.
C'est-à-dire qu'il y a plus cet abe, il y a plus ces machins et tu te rends compte, je ne retrouve plus mes colonnes, mais justement tu crées le schéma que tu veux, c'est encore plus libre. Il était en perdition totale. Est-ce que ça rejoint un petit peu le sujet que tu évoques là ?
En fait ça rejoint ça et en fait ça rejoint surtout un truc qui est, je pense, vient même de la façon dont les développeurs sont formés et de la façon dont on travaille et de la façon dont on a tendance à penser l'architecture logicielle.
C'est qu'on a une certaine tendance naturelle à faire ce qu'on appelle la MDA, c'est-à-dire la Model Driven Architecture, c'est en fait de dire ok, dans mon système j'ai ces entités qui sont en gros des tables dans lesquelles j'ai ces attributs et ces relations.
En gros j'ai des for inky, j'ai des attributs qui ont un type et j'ai des tables et tout ça en fait ça se connecte bien dans un joli schéma et tout ça.
Et finalement l'applicatif ne consiste qu'à mettre par-dessus ce truc une espèce d'interface utilisateur pour interagir avec.
Et donc très souvent ce qu'on voit c'est que l'architecture ressemble à ça.
Donc mécaniquement dès que tu viens toucher à ce sous-jacent qui finalement drive tout le reste de l'architecture, mécaniquement les mecs ça les met en stress.
Le problème c'est que quand on fait ça, on définit dès le début du projet le truc qui est le plus difficile à refactorer.
Je pense que toute personne qui a tenté une action de refactoring s'est rendu compte que quand on commençait à toucher à la partie de persistance, c'est là où les emmerds démarrent.
Et c'est pour ça que commencer son projet et baser l'architecture de son projet sur le truc qui est le plus chiant à refactorer, mécaniquement ça n'augure rien de bon pour la suite.
Parce que ça veut dire qu'on a à peine commencé que déjà on sait que là où on s'est trompé et on s'est trompé.
C'est à dire que je connais personne qui est capable de deviner à l'avance les réels cas d'usage que va avoir son logiciel.
Mais ça veut dire que dès le début, on va galérer à adapter ce que l'on avait imaginé au début, à ce qu'est la réalité.
Et donc on est déjà en train de mettre le logiciel sur une mauvaise pente.
Et tu recommandes quoi du coup pour péter cette approche ? Parce que je t'avoue que moi cette approche de coller aux données,
moi j'ai pas mal utilisé rails et le framework est centré autour de ce paradigme là.
Donc pour moi si tu sortes du crud, en tout cas au niveau du modèle et de tout ce qui est au-dessus,
je perçois plus trop forcément l'intérêt d'un framework comme rails en fait qui est hyper dogmatique sur ces approches là.
Donc moi je suis pas mal bibroné à ça et ça me va.
Mais du coup comment je fais pour sortir ? C'est quoi la démarche ?
Que des approches comme l'archi exinconal, c'est ça qui va me permettre d'insérer un certain découplage entre le métier et ma persistance.
Qu'est-ce que tu recommandes à une équipe qui a ce stress à part ta plée ?
Comment est-ce qu'il peut franchir ce stress et aller vers de l'avant ?
En fait le problème c'est que même si tu essaies de faire de l'archi exa, parce que l'archi exa effectivement ce que ça te promet,
c'est d'avoir une sorte d'indépendance qui se construit entre ta persistance on va dire et la façon que tu l'utilises dans ton application.
Mais si tu as ce mindset en fait de faire de l'architecture qui est orientée, qui est dirigée par la structuration de tes données,
que tu fasses de l'exagonal ou pas ça va rien changer. Le sorru que tu apportes l'exagonal effectivement c'est que ça sera peut-être un peu moins chiant de faire évoluer le tout.
En fait le changement de mindset en fait il se trouve vraiment sur le fait que au lieu d'essayer de comprendre quelle est la donnée que tu as dans ton soft
et quelles sont les relations qui existent entre ces différentes données, c'est en fait de s'intéresser au comportement.
C'est-à-dire en fait qui sont les acteurs, je ne parle pas des acteurs au sens sacar mais des acteurs au sens, j'ai un système de paiement,
j'ai un utilisateur qui est un acheteur, j'ai un utilisateur qui est un livreur etc. Donc qui sont ces différents acteurs et comment est-ce qu'ils interagissent ?
Quelles sont les comportements qu'on est censé voir apparaître dans l'applicatif ?
Et donc là en fait on va passer d'une modélisation qui est basée sur les données à une modélisation qui est basée sur les comportements.
Et en faisant justement ce saut on va pouvoir justement mécaniquement commencer à concevoir le système non pas autour de comment est-ce que la donnée est censée être persistée
mais de quels sont les comportements attendus par l'applicatif. Et d'un point de vue business ça fait quand même beaucoup plus sens.
Normalement le métier d'un développeur c'est pas de produire une base access glorifiée.
Parce que finalement quand on fait du crowd c'est ce qu'on fait, on fait un access c'est joli mais la plus-value elle n'est pas folle.
C'est pour ça que beaucoup d'entreprises peuvent finalement remplacer beaucoup de leur logiciel métier par des excès et que beaucoup de logiciels métiers
peuvent vraiment remplacer ce content de remplacer des excès. Mais encore une fois c'est parce qu'on n'est pas allé sur le cran qui consiste à dire ok quels sont les comportements de métier que l'entreprise
est censée avoir quels sont les comportements que j'ai pour résoudre ce problème et c'est que de là en fait que peut démarrer une vraie démarche architecture.
Alors je trouve ça passionnant et si je me mets dans la peau d'un auditeur qui ne sait pas par où commencer et d'ailleurs moi personnellement si je devais chercher à rentrer dans ce que tu décris et aller plus vers ça
à part du DDD ou des trucs comme ça je sais pas trop je chercherai qu'est ce que tu recommanderais c'est quoi le mot clé à chercher sur Google juste après avoir écouté l'épisode.
En fait malheureusement il fin d'aider c'est déjà trop en fait et je pense que pour beaucoup de gens en fait justement c'est le fait que ce soit parce qu'il y a tellement de choses que l'on met sous le parapluie d'aider que les gens ont l'ence à se perdre
c'est pour ça que vraiment en fait se dire j'arrête de me concentrer sur mes données juste j'identifie mes acteurs j'identifie les différents comportements qui sont attendus entre ces acteurs c'est déjà un très très bon premier step
et ensuite on se rend compte en fait que ces acteurs ça peut devenir des objets et que les comportements entre ces objets en fait c'est des appels de méthode entre ces différents objets
et juste en faisant ça il n'y a pas besoin d'avoir lu un bouquin de fou c'est juste changer un peu la façon dont on réfléchit le logiciel ça change déjà beaucoup de choses
et ensuite la persistance c'est quoi la persistance c'est de dire entre deux crashs ou entre deux requêtes en fonction du langage que tu utilises
il faut bien être capable de garder un état il faut sauvegarder en fait si tu veux l'état de ces différents acteurs et dans ce cas là j'ai besoin effectivement de les persister
mais on voit bien en fait que là la problématique elle est complètement détachée c'est à dire en fait là je peux me dire si je veux dénormaliser ma data c'est pas problématique
je prends mon acteur je le sérialise et je le pose quelque part et quand j'en ai besoin en fait je récupère cette version sérialisée
je réhydrate mon acteur avec ça et je récupère le endroit où il s'était arrêté je peux continuer à interagir avec lui et donc on se détache beaucoup justement en fait de cet attachement à l'ADB
et on comprend que la cohérence à terme ça veut dire en fait qu'il y a certains acteurs et bien qu'ils vont être persistés avant que d'autres
potentiellement on est été persistés mais c'est pas grave à terme tout le monde aura été persisté et on aura bien la bonne donnée
c'est juste qu'on essaye plus maintenant de tout persister au même moment en même temps etc
et donc ça aide vraiment à se défaire il n'y a pas besoin de rentrer dans des bouquins dans des machins c'est vraiment juste un changement de philosophie
Ah bah écoute je te propose que ce soit le mode la fin merci beaucoup Arnaud pour tout ça si les auditeurs vont en savoir plus sur ce que tu fais
ils peuvent venir t'écouter ou te lire
Alors me lire sur effectivement mon blog principalement lillobase.y
Merci Arnaud
Merci pour l'invitation
Quant à toi chers auditeurs j'espère que tu as apprécié cet épisode je pense que cet épisode est tout indiqué pour une écoute commune
le principe c'est tu proposes à tes potes à tes collègues à qui tu veux d'écouter cet épisode à plusieurs et d'en discuter
surtout si tu te sens concerné par les symptômes qu'a pu évoquer Arnaud le stress pré-traumatique et d'un changement de base de données
je pense que cet épisode est tout indiqué partagez autour de ça et je suis extrêmement curieux de ton feedback
tu me l'envoies sur benoîtarobaseartisandeveloper.fr qu'est ce que ça a donné ?
est ce qu'il y a eu des survivants ?
je te souhaite une bonne journée