STOP ! Stop à la Clean Archi, stop au TDD, stop à l'architecture hexagonale quand tu rejoins une nouvelle équipe !
craftacademy.substack.com
Pour faire gagner en productivité ton équipe, fais ça à la place 👇 :
Un petit peu de contexte :
Tu arrives dans une nouvelle équipe et tu constate directement que toutes les bonnes pratiques que tu connais ne sont pas respectées.
❌ Pas de tests automatisés
❌ Pas de TDD
❌ Pas d'inversion de dépendances
❌ Pas d'abstraction sous forme de ports
❌ Pas d'architecture hexagonale ou de Clean Architecture
❌ Pas d'Anti-Corruption Layer
❌ Un domain model anémique
❌ etc.
Du coup tu t'empresses de dire tout ça à ton tech lead ou à ton lead dev ! Et sa réponse est sans appel :
🧑💻 "Ouais ouais mais c'est overkill tout ça ! Ça ferait du code en plus et l'équipe serait perdue"
Ce qu'il pense vraiment c'est : "T'es mignon petit junior qui a lu plein de théories mais moi j'ai de la bouteille donc retourne à ton clavier tranquillou".
Tu vois l'erreur ici ?
Les points mentionnés ci-dessus sont tous des points techniques ! Très éloignés donc de quelque chose de tangible, palpable.
La meilleure chose à faire quand tu arrives dans une équipe est d'abord de t'intégrer pleinement dans la vie quotidienne de celle-ci.
Être très à l'écoute des douleurs quotidiennes rencontrées. Nous les devs on adore râler, donc si tu tends l'oreille tu entendras très rapidement que les mêmes problèmes reviennent souvent.
Les vrais leviers sur lesquels tu peux agir sont là où l'équipe est en souffrance.
❌ Elle passe trop de temps à tester manuellement ?
👉 Probablement que l'on peut commencer à réfléchir à automatiser des tests
❌ Elle n'arrive pas à créer des tests automatisés rapides et fiables ?
👉 Probablement que substituer certaines dépendances au moment des tests serait pertinent, grâce à l'inversion de dépendances.
❌ Elles se plaint de ne jamais savoir où trouver telle ou telle logique métier dans le code et se rend compte qu'elle la duplique souvent ?
👉 Probablement que centraliser cette logique dans des objets dont c'est le rôle est plus pertinent.
Bref, partir des problématiques et non des solutions. Je dis donc STOP en début de post car c'est une erreur de mentionner directement ces termes qui seront vus comme des buzz words.
Et au final ton tech lead fera de l'architecture hexagonale sans même s'en rendre compte ;)
Ton équipe te remerciera et tu pourras dormir la nuit sereinement :)
Happy Coding !
------------------
Pour fêter la rentrée 2023, 𝘁𝘂 𝗽𝗲𝘂𝘅 𝗯é𝗻é𝗳𝗶𝗰𝗶𝗲𝗿 𝗱𝗲 𝟮𝟯% 𝗱𝗲 𝗿é𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝘀𝘂𝗿 𝘁𝗼𝘂𝘀 𝗹𝗲𝘀 𝗰𝘂𝗿𝘀𝘂𝘀 𝗖𝗿𝗮𝗳𝘁 𝗔𝗰𝗮𝗱𝗲𝗺𝘆 pour apprendre à developper de meilleurs logiciels plus rapidement grâce aux principes Craft ici : https://bit.ly/3sEjIIJ
STOP ! Stop à la Clean Archi, stop au TDD, stop à l'architecture hexagonale quand tu rejoins une nouvelle équipe !
STOP ! Stop à la Clean Archi, stop au TDD, stop à l'architecture hexagonale quand tu rejoins une nouvelle équipe !
STOP ! Stop à la Clean Archi, stop au TDD, stop à l'architecture hexagonale quand tu rejoins une nouvelle équipe !
Pour faire gagner en productivité ton équipe, fais ça à la place 👇 :
Un petit peu de contexte :
Tu arrives dans une nouvelle équipe et tu constate directement que toutes les bonnes pratiques que tu connais ne sont pas respectées.
❌ Pas de tests automatisés
❌ Pas de TDD
❌ Pas d'inversion de dépendances
❌ Pas d'abstraction sous forme de ports
❌ Pas d'architecture hexagonale ou de Clean Architecture
❌ Pas d'Anti-Corruption Layer
❌ Un domain model anémique
❌ etc.
Du coup tu t'empresses de dire tout ça à ton tech lead ou à ton lead dev ! Et sa réponse est sans appel :
🧑💻 "Ouais ouais mais c'est overkill tout ça ! Ça ferait du code en plus et l'équipe serait perdue"
Ce qu'il pense vraiment c'est : "T'es mignon petit junior qui a lu plein de théories mais moi j'ai de la bouteille donc retourne à ton clavier tranquillou".
Tu vois l'erreur ici ?
Les points mentionnés ci-dessus sont tous des points techniques ! Très éloignés donc de quelque chose de tangible, palpable.
La meilleure chose à faire quand tu arrives dans une équipe est d'abord de t'intégrer pleinement dans la vie quotidienne de celle-ci.
Être très à l'écoute des douleurs quotidiennes rencontrées. Nous les devs on adore râler, donc si tu tends l'oreille tu entendras très rapidement que les mêmes problèmes reviennent souvent.
Les vrais leviers sur lesquels tu peux agir sont là où l'équipe est en souffrance.
❌ Elle passe trop de temps à tester manuellement ?
👉 Probablement que l'on peut commencer à réfléchir à automatiser des tests
❌ Elle n'arrive pas à créer des tests automatisés rapides et fiables ?
👉 Probablement que substituer certaines dépendances au moment des tests serait pertinent, grâce à l'inversion de dépendances.
❌ Elles se plaint de ne jamais savoir où trouver telle ou telle logique métier dans le code et se rend compte qu'elle la duplique souvent ?
👉 Probablement que centraliser cette logique dans des objets dont c'est le rôle est plus pertinent.
Bref, partir des problématiques et non des solutions. Je dis donc STOP en début de post car c'est une erreur de mentionner directement ces termes qui seront vus comme des buzz words.
Et au final ton tech lead fera de l'architecture hexagonale sans même s'en rendre compte ;)
Ton équipe te remerciera et tu pourras dormir la nuit sereinement :)
Happy Coding !
------------------
Pour fêter la rentrée 2023, 𝘁𝘂 𝗽𝗲𝘂𝘅 𝗯é𝗻é𝗳𝗶𝗰𝗶𝗲𝗿 𝗱𝗲 𝟮𝟯% 𝗱𝗲 𝗿é𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝘀𝘂𝗿 𝘁𝗼𝘂𝘀 𝗹𝗲𝘀 𝗰𝘂𝗿𝘀𝘂𝘀 𝗖𝗿𝗮𝗳𝘁 𝗔𝗰𝗮𝗱𝗲𝗺𝘆 pour apprendre à developper de meilleurs logiciels plus rapidement grâce aux principes Craft ici : https://bit.ly/3sEjIIJ