ConnaisLe pilote de ligne, le cuisinier et le médecin utilise ça et toi ? tu le point commun entre :
- un cuisinier.
- un docteur.
- un pilote de ligne.
- un ingénieur bâtiment.
En fait j’aurais pu rajouter plein d’autres métiers …
Prenons le cas du cuisinier.
Je suis nul en cuisine et je n’y connais rien mais …
Penses tu qu’un cuisinier qui veut créer un plat.
Admettons une nouvelle recette d’Avocado Toast.
J’ai pris cet exemple car j’en mange souvent à Bali et j’adore ça.
Penses tu qu’il réfléchit des heures à la manière de faire toaster son pain ?
Penses tu qu’il essaye d’inventer une manière de faire un œuf poché ?
Penses tu qu’il invente une nouvelle théorie sur la manière de mixer les avocats ?
Non, il fait de l’assemblage !
Même un cuisinier qui invente une nouvelle recette, invente très peu finalement.
Il reprend des techniques existantes et les combinent pour créer sa propre recette.
Prenons le cas d’un docteur.
Un docteur généraliste voit passer plusieurs dizaines de patients chaque jour.
Il ne peut pas se permettre de perdre trop de temps.
Penses tu vraiment qu’il réfléchit des heures sur la manière de faire un diagnostique ?
Non, il applique des méthodes toutes prêtes pour diagnostiquer.
Il possède des méthodes pour détecter les cas les plus courants.
Et dès que ça sort du cadre il t’envoie vers un spécialise.
Prenons le cas d’un pilote de ligne.
Penses tu qu’un pilote se pose la question de comment gérer la grêle la première fois qu’il en voit ?
Penses tu qu’il décide d’expérimenter un nouvelle manière d’atterrir ?
Penses tu qu’il se demande comment traverser un orage violent lorsqu’il en voit un ?
Non, un pilote de ligne suit des procédures apprises par cœur et répétées des milliers de fois.
Et heureusement pour nous.
Prenons le cas d’un ingénieur en bâtiment.
Penses tu qu’il invente une technique particulière lorsqu’il construit un immeuble sur un sol sableux et mou ?
Penses tu qu’il réfléchit des heures sur la manière de construire un immeuble dans une zone sismique ?
Penses tu qu’il cherche à inventer une technique pour percer une roche trop dure ?
Non, il applique des techniques existantes, approuvées et testées depuis des années.
Sinon voila ce qui arrive lorsqu’on essaye des techniques non éprouvées : www.youtube.com/watch?v=Rmfl2kFeNPM
Penses tu que dans la programmation ce soit différent ?
Je sais tu vas me dire la programmation c’est différent.
On tombe sur des problèmes spécifiques à notre programme à chaque fois.
Et bien c’est une erreur !
Je vois trop de débutants (même des plus expérimentés) essayer de réinventer la roue …
Ou se lancer dans un développement complexe sans même se poser et réfléchir un peu avant.
Si tu tombes sur une problématique particulière, il y a fort à parier que tu ne sois pas le premier.
Alors je sais ton ego va faire que tu vas vouloir résoudre le problème par toi même et trouver ta propre solution.
Mais penses tu qu’un pilote atterrira mieux avec sa propre technique ?
Penses tu qu’un docteur te soignera mieux avec sa propre technique de diagnostique ?
Penses que ton immeuble sera mieux construit si c’est fait par un mec qui vient juste de trouver une technique non approuvée ?
Je ne pense pas !
Dans le développement c’est pareil on utilise des techniques, des concepts, des méthodes éprouvés et validés.
Des techniques qui couvrent un large spectre de problématiques assez courantes.
On les appelle des Design patterns (Patron de conception).
A chaque fois que tu as un problème vérifie qu’il n’existe pas un design pattern qui peut t’aider.
Prenons un exemple classique de connexion en bases de données.
Dans un site web, un logiciel ou autre, on a souvent besoin d’accéder aux bases de données (BDD).
A chaque action (visite de pages, connexion, création, mise à jour etc).
Il faut se connecter à la base de données et exécuter une requête.
Cela peut parfois faire plusieurs centaines de connexions par seconde.
Une seule connexion à une BDD c’est très coûteux.
Coûteux en terme de délais (plusieurs longues millisecondes à établir).
Coûteux en terme de mémoire (Maintenir une connexion permanente ça prend de la mémoire).
Alors imagine plusieurs centaines, voir des milliers de connexions par seconde ?
Il y a de quoi faire tomber un serveur !
Alors comment faire ?
Il est possible de bidouiller un truc non standard dans son coin.
Ou vérifier s’il existe pas un design pattern qui couvre ce cas.
Le design pattern Singleton couvre ce cas.
Je ne vais pas rentrer dans les détails dans ce mail mais tu peux aller voir ici : en.wikipedia.org/wiki/Singleton_pattern
Mais pour faire simple.
Ce pattern te permet d’avoir une seule instance d’un objet.
Dans notre cas de base de données
Au lieu de faire crasher le serveur si il y a des milliers de connexions BDD.
Grâce au Singleton on aura toujours une seul instance de l’objet qui sert à maintenir la connexion à la BDD.
Et du coup on limite l’utilisation de la mémoire.
(derrière ça peut poser d’autres problèmes mais on ne va pas en parler de cet email).
Ceci n’est qu’un exemple parmi tant d’autres.
Penses à toujours regarder dans les design patterns avant de partir dans ta solution.
C’est également souvent demandé dans les entretiens d’embauches.
On peut te demander d’en citer ou d’en expliquer.
Il est important de connaitre les plus courants.
Si tu veux aller plus loin sur le sujet, sache qu’ils sont reparties en 3 grandes familles :
- Les patterns de création.
- Les patterns de structures.
- Les patterns de comportement.
Demain je te parlerai d’un autre pattern important.
