Je dirige une équipe de dev sur des produits legacy et j'approuve à 100% tout ce que vous dites, et j'encourage tout le monde à suivre ces conseils. Robert "Uncle Bob" Martin est effectivement un référence et ses vidéo et livres sont vraiment utiles. Je mesure la qualité de code avec des "WTF" (what the fuck), et je découvre avec plaisir l'équivalent français "accroc mental" bien plus représentatif. Merci pour la vidéo, je vais la recommender (surtout le début) à certaines "parties prenantes" qui ont besoin de comprendre l'intérêt d'éviter la dette technique comme la peste et le choléra.
Ce livre est en effet la Bible du développeur. D'ailleurs j'ai mis dans mon prompt entre autre "Tu as lu clean code de Robert Martin et tu appliques tous les grands principe du livre dans tes réponses en particulier les bonnes pratiques de nommage et de factorisation du code"
Je te remercie pour ton excellente vidéo. Le vrai problème n’est pas d’avoir conscience de devoir refactorer et de vouloir faire l’effort mais de savoir comment le faire pour aboutir à un résultat qui change vraiment la donne. Les points que tu mets en avant sont tout à fait pertinents, mais que il s’agit de les appliquer c’est difficile pour beaucoup de développeurs, débutants et expérimentés, car cela reste souvent trop abstrait ou sujet à interprétation. La clé c’est effectivement de rendre les choses simples. Pour cela il faut faire la distinction entre l’expression de l’intention avec un language le plus naturel possible genre vehicule.roule() et le code exprimant comment cette intention est réalisée avec peut être un language plus technique. Attention au couplage, donc attention aussi à la factorisation. Vouloir factoriser a tout prix peut amener à un code très complexe , difficile à modifier ou du moins error prone. Quand c’est presque pareil c’est des fois juste différent. Les nouveau framework à la mode ne vous sauvera pas, seule la structure de votre code pourra le faire. Rendre simples les choses compliquées n’est pas facile. Ça demande d’essayer et essayer encore d’une autre. Et celui qu’il faudra vaincre c’est vous même, il faut dépasser la vision purement technique et syntaxique de la programmation et y trouver comme un moyen d’expression. On pourrait faire l’analogie avec l’écriture d’un livre avec des lettres et ponctuations. Ce ne sont définitivement pas les lettres et les ponctuations que vous utilisez qui en fera un chef d’œuvre…
Je plussoie votre commentaire, notamment : 1/ Attention au couplage, donc attention aussi à la factorisation => VRAI. 2/ La clé c’est effectivement de rendre les choses simples => VRAI. 3/ Les nouveau framework à la mode ne vous sauvera pas, seule la structure de votre code pourra le faire => VRAI
J'approuve à 100% ta présentation. souvent la dette technique s accumule, jusqu'a ce que ce ne soit plus maintenable (version du framework à l'abandon, vulnerabilité critiques) et qu il y ait une refonte complete du systeme sur une pile technologique plus récente.
Tout à fait d'accord avec toi. Il y a en plus un effet négatif quasiment jamais abordé, c'est l'aspect RH. En effet, ayant participé au processus de recrutement notamment les entretiens techniques et bien je peux dire que sur des projets avec des technologies obsolète il est difficile de trouver des candidats et je les comprends... Finalement, faute du nombre de candidats tu prend celui qui veut bien venir et c'est pas forcément le meilleur.
Hello Simon, une nouvelle fois merci pour cette vidéo instructive ! J'ai acheté Clean Code à Cultura le weekend dernier, ta vidéo me donne envie de l'attaquer dès maintenant ! 👀 Une question traîne dans mon esprit depuis un petit moment : je ne sais plus dans quelle vidéo, mais je me souviens t'avoir entendu dire que tu avais beaucoup accroché avec le frontend, et ce malgré un bagage en PHP assez important. Or, quand je regarde tes vidéos, j'ai l'impression que l'écosystème frontend dans lequel tu gravites est finalement assez proche du backend : consommation d'API, design pattern, tableaux/objets, architecture d'un framework front... J'ai aujourd'hui le sentiment d'être plus proche de l'aspect graphique du dev : design, interface, intégration... bien que j'adore le JavaScript, je me demande si prendre de la distance avec le CSS me stimulerait autant au quotidien. As-tu déjà eu ce sentiment ? Et d'une manière plus générale, as-tu le sentiment d'être "développeur frontend" ? Ce terme semble englober tellement de concepts... Au passage, j'adore le format type "podcast" de tes vidéos, elles permettent de se concentrer sur ce que tu dis 🙂
Effectivement, je viens d'un background backend sur Symfony (PHP). Mais on ne s'ennuie pas non plus côté frontend, il y a de quoi faire aussi finalement. Concernant ta question, effectivement, on pourrait redécouper le terme "développeur frontend". Disons que je me focus sur la logique qui permet de faire tourner une application web, sans être spécialement proche du CSS ou des APIs du navigateur. Une sorte d'intégrateur Angular, ou via un autre framework. Je ne sais pas si ça répond à ta question... Aussi, qu'est-ce que tu appelles le format "podcast" des vidéos ?
Hello, oui, je me suis noté de réaliser cette vidéo, mais je ne pourrai pas la produire avant plusieurs mois. J'ai envie de passer du temps sur cette vidéo, car les livres m'ont vraiment beaucoup aidé à progresser, donc je veux leur rendre hommage en quelque sorte. 😀
Merci pour la réponse, c'est un peu ce que j'allais dire. Ce n'est effectivement pas représentatif d'une ESN moyenne en France, mais ce n'est pas pour ça qu'il ne faut pas interviewer des experts. Que ce soit dans le code dans un autre secteur d'activité d'ailleurs. 👍
On peut également ajouter le nerf de tous les problèmes : après le Redécoupage, la GESTION DES DÉPENDANCES : de quel classe/module/package doit VRAIMENT dépendre la mienne/le mien, pour réaliser ce dont il est responsable, ni plus ni moins.
Ce que je vois encore trop souvent, ce sont des clients qui ne comprennent à la notion de dette technique et qui vont virer un tech lead compétent pour le remplacer par un pisseur de features jusqu'au point de non-retour.
6:18 oui, le code dot être optimisé pour le lecteur: donc si le vocabulaire métier est en français, alors le code doit être écrit en français, pas en anglais pour l'offshore à l'autre bout du monde ...
Je dirai que "oui" si le microservice est bien fait, et "non" si le microservice est mal fait. En fait, ma démarche est de croire plus dans les compétences que dans les technos, méthodologies ou autres frameworks.
🎉 Bonjour bonjour, je lancé un pavé dans la marre. Je fuit ma petite veille quotidienne, et je constate qu'une majorité de personne qui travaillent au sein de esn , ne font pas attention au tremblementaire AI. Tout ees gens continue à vaencquer à leur occupation sans préocuper de l'AI. Je étonné simon que toi tu n'en iarle ou que tu ne l'as pas intégrer dans tes vidéos. Je suis partie voir ce qui si passe chez les gros ESN et ça va etse un carnage lorsque certains esn leader dans lAI vont se déployer au pres de leur client.
Correction par AI : "Bonjour bonjour, je lance un pavé dans la mare. Je fuis ma petite veille quotidienne, et je constate qu’une majorité de personnes qui travaillent au sein des ESN ne font pas attention à l’intelligence artificielle (IA) sismique. Tous ces gens continuent vaillamment leur occupation sans se préoccuper de l’IA. Je m’étonne, Simon, que toi tu n’en parles pas ou que tu ne l’aies pas intégrée dans tes vidéos. Je suis allé voir ce qui se passe chez les gros ESN, et ça risque d’être un carnage lorsque certains leaders dans l’IA vont se déployer auprès de leurs clients." L’intelligence artificielle est en effet un domaine en pleine expansion, et son intégration dans les entreprises est un enjeu majeur. Espérons que davantage d’ESN prendront conscience de son potentiel et sauront l’utiliser de manière bénéfique pour leurs clients. ;-)
@@olive1782000 😁😁 bien joué, bonne initiative. Revenons à des choses sérieux, si je dis ça c'est qu'en 2007 à la sortie de l'iphone beaucoup de personnes pensaient que Nokia aller continué à dominer le monde de la téléphonie avec leur N95 N 100 etc. Et on connait la suite des événements. La, situation se reproduit avec l'AI. Et je vois le drame arrivé dans les Esn. On auras plus besoins de dev devops ops sre etc, on voudras des prompt engineering , des manager spécialisé IA etc..
Bonjour, le sujet de l'IA n'est pas mis sur le côté, au contraire j'invite tout le monde à se familiariser le plus tôt possible avec ces outils. J'ai réalisé une vidéo sur ce sujet si cela vous intéresse : th-cam.com/video/slvvttdgmXo/w-d-xo.html&ab_channel=SimonDieny-CodeSenior.
Ce n'est pas faux. D'où l'intérêt d'avoir une CI (Continous Integration) pour vous assurer que votre code se base sur des dépendances à jour, passe les tests unitaires, le linter et le formater. Cela vous aidera à avoir du code moins "obsolète" dans le temps. 👍
Ta réflexion est très juste IMO maintenant il faut expliquer cela à la secte agile et devops 😂 car tu dois ameilliore ton code le rendre évolutif corriger le bug apporter des nouvelles fonctionnalités vit et avec joie 🤣🤣🤣🤣
![ปฏิเสธไม่ไหว (Crush on you) - LIPTA feat. No One Else [TEASER MV]](http://i.ytimg.com/vi/VC689EgdSIw/mqdefault.jpg)
![เปิดบ้าน นาราเครปกระเทย 1 ไร่ ขายขาดทุนหลัก10ล้าน เอามาใช้หนี้!!! l [Nickynachat]](http://i.ytimg.com/vi/0jz84VFWVP4/mqdefault.jpg)
Je dirige une équipe de dev sur des produits legacy et j'approuve à 100% tout ce que vous dites, et j'encourage tout le monde à suivre ces conseils. Robert "Uncle Bob" Martin est effectivement un référence et ses vidéo et livres sont vraiment utiles. Je mesure la qualité de code avec des "WTF" (what the fuck), et je découvre avec plaisir l'équivalent français "accroc mental" bien plus représentatif. Merci pour la vidéo, je vais la recommender (surtout le début) à certaines "parties prenantes" qui ont besoin de comprendre l'intérêt d'éviter la dette technique comme la peste et le choléra.
À votre service pour continuer la propagande sur ce sujet. 👍
Ce livre est en effet la Bible du développeur. D'ailleurs j'ai mis dans mon prompt entre autre "Tu as lu clean code de Robert Martin et tu appliques tous les grands principe du livre dans tes réponses en particulier les bonnes pratiques de nommage et de factorisation du code"
@@Cracky541 Haha pareil, j'ai tendance à mettre tout ce qui me semble des bonnes pratiques dans un prompt/custom model ChatGPT. 👍
Je te remercie pour ton excellente vidéo.
Le vrai problème n’est pas d’avoir conscience de devoir refactorer et de vouloir faire l’effort mais de savoir comment le faire pour aboutir à un résultat qui change vraiment la donne.
Les points que tu mets en avant sont tout à fait pertinents, mais que il s’agit de les appliquer c’est difficile pour beaucoup de développeurs, débutants et expérimentés, car cela reste souvent trop abstrait ou sujet à interprétation.
La clé c’est effectivement de rendre les choses simples. Pour cela il faut faire la distinction entre l’expression de l’intention avec un language le plus naturel possible genre vehicule.roule() et le code exprimant comment cette intention est réalisée avec peut être un language plus technique.
Attention au couplage, donc attention aussi à la factorisation. Vouloir factoriser a tout prix peut amener à un code très complexe , difficile à modifier ou du moins error prone. Quand c’est presque pareil c’est des fois juste différent.
Les nouveau framework à la mode ne vous sauvera pas, seule la structure de votre code pourra le faire.
Rendre simples les choses compliquées n’est pas facile. Ça demande d’essayer et essayer encore d’une autre.
Et celui qu’il faudra vaincre c’est vous même, il faut dépasser la vision purement technique et syntaxique de la programmation et y trouver comme un moyen d’expression. On pourrait faire l’analogie avec l’écriture d’un livre avec des lettres et ponctuations. Ce ne sont définitivement pas les lettres et les ponctuations que vous utilisez qui en fera un chef d’œuvre…
Je plussoie votre commentaire, notamment :
1/ Attention au couplage, donc attention aussi à la factorisation => VRAI.
2/ La clé c’est effectivement de rendre les choses simples => VRAI.
3/ Les nouveau framework à la mode ne vous sauvera pas, seule la structure de votre code pourra le faire => VRAI
J'approuve à 100% ta présentation. souvent la dette technique s accumule, jusqu'a ce que ce ne soit plus maintenable (version du framework à l'abandon, vulnerabilité critiques) et qu il y ait une refonte complete du systeme sur une pile technologique plus récente.
Exactement... d'où la fameuse "techno miraculeuse"... et on relance la roue !
Tout à fait d'accord avec toi. Il y a en plus un effet négatif quasiment jamais abordé, c'est l'aspect RH. En effet, ayant participé au processus de recrutement notamment les entretiens techniques et bien je peux dire que sur des projets avec des technologies obsolète il est difficile de trouver des candidats et je les comprends... Finalement, faute du nombre de candidats tu prend celui qui veut bien venir et c'est pas forcément le meilleur.
Hello Simon, une nouvelle fois merci pour cette vidéo instructive ! J'ai acheté Clean Code à Cultura le weekend dernier, ta vidéo me donne envie de l'attaquer dès maintenant ! 👀
Une question traîne dans mon esprit depuis un petit moment : je ne sais plus dans quelle vidéo, mais je me souviens t'avoir entendu dire que tu avais beaucoup accroché avec le frontend, et ce malgré un bagage en PHP assez important. Or, quand je regarde tes vidéos, j'ai l'impression que l'écosystème frontend dans lequel tu gravites est finalement assez proche du backend : consommation d'API, design pattern, tableaux/objets, architecture d'un framework front...
J'ai aujourd'hui le sentiment d'être plus proche de l'aspect graphique du dev : design, interface, intégration... bien que j'adore le JavaScript, je me demande si prendre de la distance avec le CSS me stimulerait autant au quotidien. As-tu déjà eu ce sentiment ? Et d'une manière plus générale, as-tu le sentiment d'être "développeur frontend" ? Ce terme semble englober tellement de concepts...
Au passage, j'adore le format type "podcast" de tes vidéos, elles permettent de se concentrer sur ce que tu dis 🙂
Effectivement, je viens d'un background backend sur Symfony (PHP). Mais on ne s'ennuie pas non plus côté frontend, il y a de quoi faire aussi finalement.
Concernant ta question, effectivement, on pourrait redécouper le terme "développeur frontend". Disons que je me focus sur la logique qui permet de faire tourner une application web, sans être spécialement proche du CSS ou des APIs du navigateur. Une sorte d'intégrateur Angular, ou via un autre framework. Je ne sais pas si ça répond à ta question...
Aussi, qu'est-ce que tu appelles le format "podcast" des vidéos ?
Salut Simon ! J’aime beaucoup ce que tu propose. Peux-tu faire une vidéo sur quelques conseil de lecture allant du débutant à l’expert stp merci 👍
Hello, oui, je me suis noté de réaliser cette vidéo, mais je ne pourrai pas la produire avant plusieurs mois. J'ai envie de passer du temps sur cette vidéo, car les livres m'ont vraiment beaucoup aidé à progresser, donc je veux leur rendre hommage en quelque sorte. 😀
Très bons conseils. En revanche, interviewer des employés de Google ou Netflix ne va pas donner une représentation réaliste du métier en France.
Il faut écouter les meilleurs pour devenir meilleur. Il faut aussi pas ce focaliser que sur la France, le monde est grand il y a de la place partout.
Merci pour la réponse, c'est un peu ce que j'allais dire.
Ce n'est effectivement pas représentatif d'une ESN moyenne en France, mais ce n'est pas pour ça qu'il ne faut pas interviewer des experts. Que ce soit dans le code dans un autre secteur d'activité d'ailleurs. 👍
@@codeursenior en effet, bonne continuation à vous pour votre projet de devenir expert google (ce qui sera une formalité pour vous je pense)
@@b1899-k2v Oulà rien n'est sûr, je ferai le malin quand je serai de l'autre côté ! 😅
Bon code à vous,
Simon.
On peut également ajouter le nerf de tous les problèmes : après le Redécoupage, la GESTION DES DÉPENDANCES : de quel classe/module/package doit VRAIMENT dépendre la mienne/le mien, pour réaliser ce dont il est responsable, ni plus ni moins.
Oui vous avez tout à fait raison ! Limiter le coupling au strict minimum.. et organiser les dépenses par ordre de stabilité. Bon code !
Code that feats in your head, bonne référence, d'ailleurs l'auteur du livre Mark Seemann a un blog ou il écrit des articles.
Yep, j'adore son livre, au top.
Bon code,
Simon.
j'ai rien a dire je com pour la visibilité et recensement. tres quali pouce bleu
Merci pour votre contribution à l'effort de guerre !
Ce que je vois encore trop souvent, ce sont des clients qui ne comprennent à la notion de dette technique et qui vont virer un tech lead compétent pour le remplacer par un pisseur de features jusqu'au point de non-retour.
6:18 oui, le code dot être optimisé pour le lecteur: donc si le vocabulaire métier est en français, alors le code doit être écrit en français, pas en anglais pour l'offshore à l'autre bout du monde ...
Hello, point de vue intéressant. Codant uniquement en anglais, je ne me suis jamais posé cette question !
J'ai le sentiment qu'en microservjce on évite vachement plus ce genre de soucis non ?
Je dirai que "oui" si le microservice est bien fait, et "non" si le microservice est mal fait. En fait, ma démarche est de croire plus dans les compétences que dans les technos, méthodologies ou autres frameworks.
Parmis t’es livré tu en a un préférer ?
J'aurais du mal à choisir, je dirai "Code That Fits in Your Head" de Mark Seeman.
🎉 Bonjour bonjour, je lancé un pavé dans la marre. Je fuit ma petite veille quotidienne, et je constate qu'une majorité de personne qui travaillent au sein de esn , ne font pas attention au tremblementaire AI. Tout ees gens continue à vaencquer à leur occupation sans préocuper de l'AI. Je étonné simon que toi tu n'en iarle ou que tu ne l'as pas intégrer dans tes vidéos. Je suis partie voir ce qui si passe chez les gros ESN et ça va etse un carnage lorsque certains esn leader dans lAI vont se déployer au pres de leur client.
Correction par AI : "Bonjour bonjour, je lance un pavé dans la mare. Je fuis ma petite veille quotidienne, et je constate qu’une majorité de personnes qui travaillent au sein des ESN ne font pas attention à l’intelligence artificielle (IA) sismique. Tous ces gens continuent vaillamment leur occupation sans se préoccuper de l’IA. Je m’étonne, Simon, que toi tu n’en parles pas ou que tu ne l’aies pas intégrée dans tes vidéos. Je suis allé voir ce qui se passe chez les gros ESN, et ça risque d’être un carnage lorsque certains leaders dans l’IA vont se déployer auprès de leurs clients."
L’intelligence artificielle est en effet un domaine en pleine expansion, et son intégration dans les entreprises est un enjeu majeur. Espérons que davantage d’ESN prendront conscience de son potentiel et sauront l’utiliser de manière bénéfique pour leurs clients. ;-)
@@olive1782000 😁😁 bien joué, bonne initiative. Revenons à des choses sérieux, si je dis ça c'est qu'en 2007 à la sortie de l'iphone beaucoup de personnes pensaient que Nokia aller continué à dominer le monde de la téléphonie avec leur N95 N 100 etc. Et on connait la suite des événements. La, situation se reproduit avec l'AI. Et je vois le drame arrivé dans les Esn. On auras plus besoins de dev devops ops sre etc, on voudras des prompt engineering , des manager spécialisé IA etc..
Bonjour, le sujet de l'IA n'est pas mis sur le côté, au contraire j'invite tout le monde à se familiariser le plus tôt possible avec ces outils. J'ai réalisé une vidéo sur ce sujet si cela vous intéresse : th-cam.com/video/slvvttdgmXo/w-d-xo.html&ab_channel=SimonDieny-CodeSenior.
TOP
MERCI
possible d'avoir un projet web react de A à Z comment ça se passe en entreprise ?
Hello, pour React non. Pour Angular oui, ce sera l'objet de la formation que je rendrai publique quand j'aurais atteint 100.000 abonnées. Bon code !
@@codeursenior donc je partage au max la page 🎊🔥
@@henochangemichaellonzokoff6036 🚀
Je ne sais pas qui a dit un jour qu'un bout de code est obsolète dès qu'on l'a écrit.
Ce n'est pas faux. D'où l'intérêt d'avoir une CI (Continous Integration) pour vous assurer que votre code se base sur des dépendances à jour, passe les tests unitaires, le linter et le formater. Cela vous aidera à avoir du code moins "obsolète" dans le temps. 👍
Ta réflexion est très juste IMO maintenant il faut expliquer cela à la secte agile et devops 😂 car tu dois ameilliore ton code le rendre évolutif corriger le bug apporter des nouvelles fonctionnalités vit et avec joie 🤣🤣🤣🤣
Il y a sûrement d'excellents tech leads chez Google, il y en a sûrement aussi beaucoup qui sont moins bons que toi.
C’est très flatteur mais ils doivent être rares quand même. 😆