Description

Quand notre seul outil est un marteau, tous nos problèmes finissent par ressembler à des clous. Donc si vous voulez arrêter de tout casser dès que vous touchez quelque chose,e ssayer de diversifier votrer boite à outils! DDD est jsutement là pour ça!

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

• Speaker #0

  Bonjour à tous, et bienvenue dans ce nouvel épisode du podcast Punkin'Dev. Quand notre seul outil est un marteau, tous nos problèmes finissent par ressembler à des clous. Voilà une maxime relativement célèbre que j'ai souvent entendue dans le monde du dev ou de l'agilité. Elle cherche à dire quoi, cette punchline ? Et pourquoi on aime bien l'utiliser en fait ? Assez simplement, elle veut juste dire qu'avec une seule typologie d'outils, il ne faut pas s'attendre à être capable de résoudre une grande typologie de problèmes. Avec un outil unique, on saura adresser un type de problème. Pour le marteau, on va savoir enfoncer des clous, ou casser des trucs. Avec un peu d'expérience, on peut même devenir expert en plantage de clous, et en cassage de trucs. Et c'est très bien de disposer d'une expertise forte sur des points particuliers. Ça peut rendre de grands services, et ça peut même se monnayer assez cher si on trouve le bon marché. Par contre, si on a besoin de poncer des planches, de faire des circuits électriques, il va peut-être falloir laisser la place aux menuisiers ou aux électriciens. Ou se décider à ranger le marteau pour essayer de mettre d'autres outils dans notre boîte à outils. Le monde du dev a une propension incroyable à se créer des outils pour se simplifier certaines tâches. A tel point qu'aujourd'hui, il y a un peu un outil pour tout. Ce qui pourrait être une excellente chose si cette profusion n'avait pas parfois tendance à virer à un excès tel qu'on finisse par s'y perdre un peu, voire beaucoup des fois. Une conséquence de tout ça, c'est qu'à certains moments, on va forcément vouloir se simplifier la tâche d'apprentissage, et essayer de trouver cette espèce de chimère que sera l'outil ultime, cette espèce de couteau suisse qui sera totalement adaptable, générique, et qu'on pourra utiliser absolument de partout. Et c'est normal que quelque part on ait envie de trouver cette panacée. Imaginez pouvoir remplacer la totalité des frameworks JavaScript par un seul framework unique pour les gouverner tous. Ouais, on sait dans quel ténèbre ça finit cette histoire de trucs uniques là. Mais même si tout cet outil a été justement pensé comme un couteau suisse pour pouvoir remplir plein de fonctions différentes, ça restera un couteau suisse qui dépannera pour plein de choses, mais qui au final ne sera vraiment bon dans absolument aucun cas. Et pour cause, c'est pas son rôle, il a pas été conçu pour ça. Un couteau suisse, il est là pour vous dépanner quand vous avez rien d'autre à portée de main. Pour un pique-nique champêtre, y'a pas mieux. Mais pour fabriquer un meuble ou une bagnole, ça va être compliqué. Alors désolé de faire le rabat-joie, mais le super framework trop bien qu'on peut utiliser partout, tout le temps, les yeux fermés, j'y crois plus. Ça marche aussi pour les moteurs de base de données et tout un tas de choses. Le monde est vaste et complexe, et je ne pense pas qu'on puisse sincèrement trouver un outil qui réponde à tous nos besoins. Autant chercher la pierre philosophale. C'est pour cette raison que, en tant que dev, j'ai fait le choix de remplir ma boîte à outils d'un maximum de choses, et si possible, de plus de variétés. J'en garde forcément quelques-uns sur lesquels je vais avoir un peu plus d'expertise, ne serait-ce que pour pouvoir les vendre un peu plus cher. Mais au global, je vais m'efforcer d'avoir plein d'outils annexes, quitte à les utiliser très rarement. Mais si je sais dans quel but ils ont été créés, je devrais être capable de les ressortir quand c'est vraiment pertinent. Et c'est cette connaissance-là, plus que celle de l'outil en lui-même, qui me semble importante. Connaître un design pattern, c'est bien. Mais savoir précisément quel type de problématique il adresse, et donc à quel moment l'utiliser, ça, ça me paraît beaucoup plus précieux, et beaucoup plus important. On peut facilement retrouver l'implème du pattern si on l'a oublié, c'est pas très grave. Si par contre on a mal compris le problème adressé, connaître l'implème par cœur, ça va pas nous éviter une grosse erreur de conception. Au jeu de la boîte à outils bien fournie, je milite grandement pour que chacun s'approprie des DD. Comme je tentais de l'expliquer dans le tout premier épisode du podcast, des DD, ce n'est ni un pattern, ni un framework, c'est juste... Une boîte à outils. Et je dirais même que c'est une énorme boîte à outils. Que ce soit pour sa dimension stratégique, qui va nous permettre d'améliorer l'exploration, la compréhension du métier, ou sa partie tactique, qui propose des patterns et des pratiques d'implémentation, DDD a bien souvent une réponse, ou au moins une piste, pour vous aider dans votre problématique. A ce stade, les plus attentifs me diront que ce que je suis en train de vous dire ici pour DDD, c'est en totale opposition avec ce que je vous racontais il y a deux minutes sur l'universalité et l'outil unique. Et bah si. vous vous dites ça vous aurez raison alors je vais le redire ddd n'est pas un outil c'est une boîte à outils libre à vous de piocher dedans pour en extraire ce qui vous intéresse alors bien sûr que cette boîte à outils n'a pas toutes les réponses si vous tombez sur un problème super spécifique comme je sais pas moi de la haute performance ou des très fortes volumétrie à gérer à ddd va pas vous donner le moteur bdd utiliser Par contre, utiliser suffisamment tôt les patterns stratégiques d'exploration métier, que ce soit le BDD, l'event storming, les ong mapping ou d'autres, tout ça, ça pourra vous alerter assez tôt sur l'émergence de cette problématique de volume, de fréquence. tout ce que vous voulez. Et à ce moment-là, libre à vous d'adresser cette problématique-là de la bonne manière. En mettant, je sais pas moi, du CQRS, une base non SQL, ou juste en démultipliant vos instances serveurs. Débrouillez-vous. Mais bien utilisé, DDD devrait vous permettre d'être proactif sur ces questions et de délivrer le maximum de valeur métier à vos utilisateurs, en leur épargnant au mieux les problématiques purement techniques. En résumé, DDD c'est la vie. J'espère que vous ne trouverez pas que cet épisode sur les marteaux ne valait pas un clou. Si vous êtes curieux de DDD, n'hésitez pas à vous inscrire à tous les meet-ups flagués DDD qui peut y avoir en France. Je pense à DDDFR qui est basé plutôt sur Paris, au Crafter... Lyon, qui font des soirées DDD tous les mois. Je vous invite à aller voir toutes les personnes qui parlent régulièrement de DDD sur leur blog, sur leur Twitter. Je pense toujours à Thomas Pirin, je pense à Julien Topsu, il y a plein de gens comme ça. Je vous mettrai une liste dans la description. Il me reste à vous souhaiter une excellente fin de semaine. A la prochaine pour un nouvel épisode. Et d'ici là, geekez bien, codez bien.