"…il suffit de mettre le code à chaque fois là où tu en as besoin et c'est tout ! Sans indirection !"
Avoir un code découplé avec quelques indirections, ce n'est pas juste pour faire joli, ou la dernière lubie des pro-tdd, pro-clean architecture, ou toutes les personnes reloues qui semblent juste vouloir complexifier le code pour paraître plus intelligentes :)
Un exemple très concret que je vois dans beaucoup de projets : la gestion des évènements d'analytics.
"Quand l'utilisateur met un produit dans un son panier => envoie un évènement productAddedToCart à Google Analytics"
"Quand l'utilisateur commence son checkout => envoie un évènement checkoutStarted".
Facile ! Il suffit d'aller dans le code à l'endroit où l'on appelle la fonction addProductToCart(), et simplement ajouter juste en dessous "sendAnalyticsEvent("productAddedToCart").
Pareil pour le checkout ! On va voir dans le code où le checkout commence, et hop on ajoute juste un petit bout de code la ligne du dessous pour envoyer l'évènement.
No problemo ?
Si, problemo !
D'un point de vue purement branl*tte intellectuelle, on peut rétorquer : 🤓 "Ton code viole le principe S de SOLID, cette fonction a 2 responsabilités différentes, c'est pas bon !"
Ou encore : 🤓 "Ton code manque de cohésion de cette façon !"
Sauf que c'est loin d'être de la branl*tte intellectuelle, on peut se rendre compte rapidement du problème.
Imaginons que le PM (ou n'importe qui d'autres) ait besoin de savoir quels sont tous les évènements envoyés.
Avec la façon de faire ci-dessus, on doit partir à la recherche dans notre propre code, à coup de CMD+F pour trouver les différents évènements envoyés. Pire, parfois ça devient tellement pénible que c'est le PM lui-même qui doit regarder dans son dashboard les derniers évènements reçus.
Pourquoi ? Parce qu'on a mis le bazar dans notre propre code.
Ce que l'on voudrait, c'est simplement avoir besoin de regarder dans notre structure de fichiers, voir un dossier analytics/ et avoir par exemple à l'intérieur un seul fichier sendEvent où seront envoyés tous les évènements, ou alors un fichier par évènement d'analytic envoyé par exemple.
De cette façon, on respecte le S de SOLID, et notre code a plus de cohésion, car on sait exactement où chercher quoi (entre autres).
Comment parvenir à ce résultat ? Eh bien en découplant notre code grâce aux évènements !
Et avec redux, c'est très facile, puisque l'event-oriented programming est inclus :)
Il suffira dans un module analytics d'écouter les différentes actions redux responsables de l'ajout d'un produit dans le panier, ou du démarrage du checkout, et en retour envoyer l'évènement d'analytics qui va bien :)
Finalement ce n'est donc pas de la branl*tte intellectuelle ;)
Avoir un code découplé ça ne sert à rien !
Avoir un code découplé ça ne sert à rien !
Avoir un code découplé ça ne sert à rien !
"…il suffit de mettre le code à chaque fois là où tu en as besoin et c'est tout ! Sans indirection !"
Avoir un code découplé avec quelques indirections, ce n'est pas juste pour faire joli, ou la dernière lubie des pro-tdd, pro-clean architecture, ou toutes les personnes reloues qui semblent juste vouloir complexifier le code pour paraître plus intelligentes :)
Un exemple très concret que je vois dans beaucoup de projets : la gestion des évènements d'analytics.
"Quand l'utilisateur met un produit dans un son panier => envoie un évènement productAddedToCart à Google Analytics"
"Quand l'utilisateur commence son checkout => envoie un évènement checkoutStarted".
Facile ! Il suffit d'aller dans le code à l'endroit où l'on appelle la fonction addProductToCart(), et simplement ajouter juste en dessous "sendAnalyticsEvent("productAddedToCart").
Pareil pour le checkout ! On va voir dans le code où le checkout commence, et hop on ajoute juste un petit bout de code la ligne du dessous pour envoyer l'évènement.
No problemo ?
Si, problemo !
D'un point de vue purement branl*tte intellectuelle, on peut rétorquer : 🤓 "Ton code viole le principe S de SOLID, cette fonction a 2 responsabilités différentes, c'est pas bon !"
Ou encore : 🤓 "Ton code manque de cohésion de cette façon !"
Sauf que c'est loin d'être de la branl*tte intellectuelle, on peut se rendre compte rapidement du problème.
Imaginons que le PM (ou n'importe qui d'autres) ait besoin de savoir quels sont tous les évènements envoyés.
Avec la façon de faire ci-dessus, on doit partir à la recherche dans notre propre code, à coup de CMD+F pour trouver les différents évènements envoyés. Pire, parfois ça devient tellement pénible que c'est le PM lui-même qui doit regarder dans son dashboard les derniers évènements reçus.
Pourquoi ? Parce qu'on a mis le bazar dans notre propre code.
Ce que l'on voudrait, c'est simplement avoir besoin de regarder dans notre structure de fichiers, voir un dossier analytics/ et avoir par exemple à l'intérieur un seul fichier sendEvent où seront envoyés tous les évènements, ou alors un fichier par évènement d'analytic envoyé par exemple.
De cette façon, on respecte le S de SOLID, et notre code a plus de cohésion, car on sait exactement où chercher quoi (entre autres).
Comment parvenir à ce résultat ? Eh bien en découplant notre code grâce aux évènements !
Et avec redux, c'est très facile, puisque l'event-oriented programming est inclus :)
Il suffira dans un module analytics d'écouter les différentes actions redux responsables de l'ajout d'un produit dans le panier, ou du démarrage du checkout, et en retour envoyer l'évènement d'analytics qui va bien :)
Finalement ce n'est donc pas de la branl*tte intellectuelle ;)
Happy Coding !
PS : C'est les soldes d'été sur Craft Academy, jusqu'à -60% :) si tu veux profiter de l’un des cursus :)