5 Leçons Intemporelles pour devenir Développeur Professionnel (tirées du livre “Clean Code”)

Рет қаралды 14,805

Simon Dieny - Code Senior

Күн бұрын

Пікірлер: 79

@erwanangot9663 2 ай бұрын

Super Simon bientôt 50k abonnés. Je t’ai regarder sur tes tuto angular au début 😊 bonne continuation

@codeursenior Ай бұрын

Salut Erwan, merci beaucoup pour le soutien. Des que j’ai fini mon workshop Angular Junior, je reprendrai la chaîne KZbin avec un rythme plus soutenu. 👍

@DavidRENAUD1986 2 ай бұрын

Super intéressant. J'ai acheté ce livre suite aux conseils d'un collègue il y a quelques jours, mais je n'ai pas encore pris le temps de le lire. Ca m'a motivé à le débuter. J'aime beaucoup tes vidéos très généralistes sur la qualité du code et la gestion de projet, car c'est valable pour tous les langages, et on se retrouve très facilement avec des cas de figures similaires.

@codeursenior Ай бұрын

Salut David, c’est top si tu as le temps de lire Clean Code. Je suis à peu près sûre que tu ne le regretteras pas. Merci pour ton retour sur les vidéos et bon code !

@MichelRaskin-j6s 5 күн бұрын

Bonjour et merci. Je ne suis pas développeur, mais je code de temps en temps, des petites choses au niveau professionnel ou pour mes bidouilles personnelles. J'ai bien apprécié les deux vidéos que je viens de regarder, vous avez une façon claire de dire les choses, et, cerise sur le gâteau, elles sont tout à fait censées 🙂. Cela me donne envie d'en regarder d'autres, j'espère juste qu'il y en a avec du concret car les deux visualisées étaient plutôt faites de généralités, sans trop entrer dans le vif du sujet. Ce n'est pas un reproche, puisque que j'ai dit en préambule que je les ai appréciées. D'ailleurs j'aurais bien envoyé celle là à mes collègues si elle avait été en anglais. (je fais partie d'une entreprise qui vend des logiciels de conception électronique, et je pense qu'on gère quelques centaines de milliers de lignes de code, voir beaucoup plus !)

@arsenicsenga 2 ай бұрын

Vous avez des thèmes très importants et j'apprécie grandement votre façon de concevoir le métier d'ingénieur logiciel, merci de votre professionnalisme

@ApprendreSansNecessite 2 ай бұрын

Il y a à boire et à manger dans ce livre, je pense qu'il faut le prendre avec pas mal de recul. En tout cas les conseils concrets et les exemples donnés ne sont pas toujours convainquants. Mais j'ai gardé quelques astuces, comme ne pas mélanger des niveaux d'abstraction par exemple, ou mettre les commentaires en rouge vif dans mon IDE (et le JSDoc en gris, faut trouver le moyen de séparer les deux si non tu pleures) Ce qu'il y a des bien avec l'oncle Bob c'est qu'il est très facile de caricaturer ce qu'il dit, il est très marquant, très sûr de lui, donc pédagogiquement ça rentre très facilement. Il a une très bonne série de vidéos sur les tests, les principes SOLID et les design patterns qui malheureusement coûte un bras, mais attention de ne pas le prendre comme gourou. Personnellement, j'ai été designer la plupart de ma carrière et quand j'ai voulu passer au développement j'ai cherché des ressources comme ça pour être professionnel. Elles ne sont pas mauvaises, mais représentent une autre façon de travailler qui se perd, et leur lecture m'a clairement déservi pour chercher du taff. J'ai dû réapprendre à coupler mon code, à dépendre de frameworks, à tout tester en end-to-end pour avoir simplement le droit de travailler. Alors j'ai envie de dire "attention", tout ça est très bien, mais ça n'existe pas le "clean code", d'ailleurs tu le dis très bien, chacun sa définition, mais surtout on n'est pas un "clean coder". S'identifier à une manière de faire ou à un paradigme c'est la façon la plus certaine d'être fermé d'esprit et de s'interdire d'en changer (parce que ça reviendrait à se renier)

@ilronin804 2 ай бұрын

Je suis un peu sceptique. J'ai lu ce livre et je le trouve personnellement, très utile. Certaines observations des auteurs, beaucoup de développeurs comme moi les ont aussi faites durant leur vie professionnelle. Je ne comprends pas en quoi la lecture de ce livre peut vous desservir dans votre recherche d'un travail. Vous dites "j'ai dû apprendre à tout tester end to end", je ne comprends. Les auteurs encouragent-ils à ne pas tester son code ? C'est même exactement le contraire ! J'ai l'impression que vous n'avez peut-être pas bien lu ce livre.

@ApprendreSansNecessite 2 ай бұрын

@@ilronin804 Le end-to-end ce n'est pas la seule façon de tester. Tu as aussi les tests unitaires et les tests d'intégration. Et un test acceptance n'est pas forcément end-to-end non-plus (une règle métier qui peut avoir plusieurs clients ferait bien d'être testée en isolation). Les Oncle Bob, Kent Beck, Dave Farley, Martin Fowler, etc. sont prompts à recommander des stratégies de test qui ne sont majoritairement pas end-to-end (la fameuse pyramide des tests: beaucoup de tests unitaires, moins d'intégration, moins de end-to-end) parce que tu n'isoles pas bien la cause de l'erreur en end-to-end, tu aurais souvent besoin de plusieurs "points de mesure" à différentes interfaces ; parce que le e2e c'est lent et que c'est compliqué d'appliquer TDD, qui a besoin de cycles rapides, de cette façon ; parce que ça peut fausser les mesures de code coverage, etc. Kent Beck il est connu pour TDD et TCR, sa méthode de test fetish c'est le test unitaire (alors il a une notion de "unitaire" un peu abstraite pour l'époque, mais moi aussi du coup, donc quand je dis "unitaire" je ne dis pas tester chaque méthode de chaque classe mais bien tester une unité logique qui ne collabore pas avec une autre partie signifiante du système) Robert C. Martin a créé FitNesse, qui est un genre de Cucumber en Java et qui permet de tester avec une grande granularité, en créant des fixtures qui permettent d'invoquer les bonnes entités avec les bons use cases. Je n'ai pas encore une grande expérience en dev pur mais ça c'est la méthode à papa, j'ai jamais vu personne faire ça, jamais vu un framework le proposer, au contraire c'est "couple tout, de toute façon je te donne un outil pour tester". Ils proposent des patterns comme Humble Object, ils insistent sur la création de ViewModels, ils mettent en garde contre les outils de mocks puissants qui te motivent à coupler ton code parce que tu n'es pas pénalisé quand tu le fais, ce qui a tendance à diminuer la qualité du code et à coupler les tests à sa structure, les rendant fragiles, etc. Je fais référence à des codebases qui ne peuvent se tester *que* en end-to-end parce que ce serait trop compliqué de les tester autrement vu le niveau de couplage. Mais ce qui est drôle, en effet, c'est que quand je parle de ne pas tout tester en end-to-end, systématiquement, vraiment, 95% du temps, on me répond comme toi que c'est important de *tester* tout court. Comme si "tester" c'était forcément tester en end-to-end.

@ApprendreSansNecessite 2 ай бұрын

@@ilronin804 J'ai écrit une longue réponse qui a été censurée, je pense que certains acronymes et noms propres doivent mal passer parce que c'est pas la première fois que ça m'arrive sur cette chaîne. Mais du coup, excuse le caractère expéditif de cette deuxième réponse : Ne pas tout tester en end to end, ça ne signifie pas ne pas tester (je pourrais m'arrêter là en fait) Les grands auteurs qui ont transformé notre industrie avec les tests automatisés, le Behaviour-driven design et l'agilité ne recommandent pas de tout tester en end to end (on pense à la pyramide des tests par exemple). En fait ce que j'ai appris en partant de Robert C. Martin et en faisant le tour des auteurs de sa génération est tout l'inverse de ce que je vois au jour le jour. Mais pour résumer vraiment grossièrement leur ressenti : la qualité de ton code est en général inversement proportionnelle à la puissance de tes outils que tu es forcé d'utiliser pour le tester.

@LaCaverneDesCodeurs 2 ай бұрын

@@ApprendreSansNecessite Personnellement je suis un grand simplet. Je n'ai jamais voulu écouter les tenants de la POO, ou des design pattern, ou de SOLID, ou des méthodes "agiles". J'en sais un peu sur ces sujets parce que je ne veux pas être "largué" dans une discussion sur la programmation. Quant à ce qui fait un code robuste et à ce qui fait un code maintenable, on a tous des avis différents selon notre expérience. Corollaire : ceux qui ne savent pas ce que c'est que de maintenir une application sur une très longue durée (par exemple vingt ans) devraient ne pas s'exprimer sur ce genre de sujet, même s'ils connaissent tous les principes à la mode.

@ApprendreSansNecessite 2 ай бұрын

@@LaCaverneDesCodeurs Tu ne trouves pas étrange que dans une discipline qui aime s'appeler "ingénierie" et qui touche la science de l'information on soit tellement nombreux à avoir des préjugés et des avis fondés sur l'expérience personnelle ? Je n'ai jamais entendu personne mentionner des études lorsque l'on parle de programmation (il y a bien Dave Farley, mais je parle de personnes que je connais ou qui ne sont pas des auteurs sur le sujet). Ça me semble complètement aberrant.

@sebastienestienne4669 2 ай бұрын

Merci de mettre en lumière tous ces aspects intéressants

@JKABESANCON-iq9ds 2 ай бұрын

J'ai 49 ans ... je veux apprendre ... merci Simon d'aider les novices comme moi.

@moaly4738 2 ай бұрын

bravo je vous encourage vivement, j'ai quelques années de moins que vous et je me forme aussi.

@ggousier 2 ай бұрын

Il n'y a pas d'âge pour apprendre contrairement à ce que l'on essaie de nous faire croire. Mais si tu débutes, ne t'embêtes pas trop avec le clean code, c'est déjà assez compliqué de bien comprendre les fondamentaux. Ne te rajoutes pas une couche de complexité. Par contre quand tu commenceras à être à l'aise, là oui tu pourras t'y intéresser.

@LaCaverneDesCodeurs 2 ай бұрын

@JKABESANCON-iq9ds : ma chaîne encore vide va, dans environ une semaine, essayer d'être utile à ceux qui veulent apprendre à programmer. On va parler d'abord de choses purement techniques, parce que ceux qui apprennent trop tôt les "bonnes pratiques" ne les comprennent en réalité pas.

@conscientart 2 ай бұрын

Enfin une personne qui tente de se rapprocher de la vérité réel. Si tu n'étais pas youtuber, tu aurais plus raison.

@codeursenior 2 ай бұрын

Meilleur commentaire de la semaine, merci !

@RIthon779 Ай бұрын

Coucou Simon et merci pour la vidéo, petite idée de vidéo ==> comment customiser les couleurs de son application grâce aux theming :D

@nashaeshire6534 2 ай бұрын

Personnelement je code dans cet ordre: 1 Analyse du cahier des charges et recherche du VRAI besoin, 2 Doc, 3 Test, 4 code. Après, je suis dans l'industrie, je suppose que j'ai plus de temps que d'autres devs. Et aussi, j'ai fait 20 ans en maintenance (aéro puis médical) avant de devenir dev, ca doit jouer :)

@ameltriki2497 2 ай бұрын

Merci beaucoup! C'est très intéressant!

@arnoldkienou42 2 ай бұрын

j'ai beaucoup hésité à le lire ce livre, merci. j'y vais de ce pas.

@mugiwaranocoder 2 ай бұрын

Super intéressant 🚀

@wiemkharrat1497 2 ай бұрын

C'est très bien Simon ; c'est une courte présentation intéressante.

@codeursenior 2 ай бұрын

Salut, merci pour ton retour. 👍

@gabbyfoot8623 22 күн бұрын

BONJOUR SIMON ET MERCI POUR TOUT CE QUE TU FAIS. TOUT COMME TOI J'AIMERAIS DEVENIR DÉVELOPPEUR PROFESSIONNEL, JE SUIS RÉELLEMENT PASSIONNÉ PAR JAVA SCRIPT. S’IL-TE-PLAIT QUELLES SONT LES COMPÉTENCES DONT J'AURAIS BESOIN POUR Y PARVENIR ET DANS QUEL ORDRE?

@DominiqueSAUVIGNON 2 ай бұрын

Merci :-) j'ai ce livre et je l'ai commencé, et à priori, tu conseilles que je le finisses...

@djcaesar9114 2 ай бұрын

Le GOAT des miniatures a encore frappé, donc je mate.

@djcaesar9114 2 ай бұрын

Je viens enfin d'acheter le bouquin, depuis le temps que tu en parles. Hâte de voir ce que ça va changer dans mes pratiques!

@adriencbl 2 ай бұрын

La leçon 2 est très important. Martin écrit également dans Clean Agile "Agile est un engagement à tendre vers l’excellence, à être toujours plus professionnel et à favoriser les comportements professionnels dans l’industrie logiciel" Les mots important sont professionnel, excellence et industrie; il y a un réel souhait depuis plusieurs années (depuis le début même) à avoir une profession honorable On peut ainsi comparer l'artisan au bricoleur. Malheureusement en informatique on fait bcp plus de bricolage que d'artisanat.

@rs4267 2 ай бұрын

Le livre de Martin Fowler sur le refactoring aussi est une vraie mine d'or !

@codeursenior Ай бұрын

Tout à fait ! J’aurais du mal à ne pas faire une vidéo sur cette pépite prochainement !

@rs4267 Ай бұрын

@@codeursenior je l'attends avec impatience

@codeursenior Ай бұрын

@@rs4267 🔥

@boguiniava3419 Ай бұрын

@ Simon Dieny, merci pour ta vidéo. Je suis développeur débutant. Je pense que je souffre su syndrome de l'imposteur. Lorsque je souhaite résoudre un problème, je me rends souvent sur Google. Comment faire pour éviter le copier coller du code des autres ? Car j'ai l'impression de ne pas comprendre réellement ce que je fais. Merci d'avance.

@Yami_nK 2 ай бұрын

Par principe, je suis d'accord avec la "boyscout" rule. Sur le terrain, ce n'est pas systématiquement applicable. Et elle entre en contradiction avec le dicton : "If it's not broken, don't try to fix it". J'ai eu entre les mains y'a plusieurs mois une petite mission de TMA. La code base était un cas d'école de ce qui pourrait être considéré comme étant à l'exact opposé de ce qu'on trouve dans un guide des bonnes pratiques. Je ne vais pas trop rentrer dans les détails, mais le client avait des impératifs : Réparer "le" bug de leur logiciel, ajouter 3~4 features, le faire le plus rapidement possible faute de budget. Le code avait besoin d'une refonte complète tellement c'était une usine à gaz. Dans ce genre de circonstances, appliquer cette règle me semble dangereux. Si y'a un truc qui foire sur une section du code "nettoyée", il va falloir justifier auprès du client "pourquoi t'as touché à du code qu'on t'a pas demandé de toucher, et qu'on t'a pas payé pour modifier ?" À défaut d'être un boyscout, il me semble préférable de ne pas ajouter d'avantage de désordre, plutôt que de se risquer à ranger / nettoyer une structure qui menace de s'écrouler... Ou à défaut, on ne s'y risque pas seul... Très bonne vidéo, comme d'habitude.

@ApprendreSansNecessite 2 ай бұрын

J'ai été dans ta situation et tout ce que je peux dire c'est qu'il faut effectivement se souvenir du scope de ton ticket et du budget, mais ça n'empêche pas de faire des petits refactos opportunistes. Souvent, au lieu de simplement lire et suivre le cheminement dans ma tête d'un code mal fichu, je vais faire une "lecture active" en déplaçant des bouts de code, en renommant ou créant des variables ou en supprimant des mutations. Je sais pas si c'est plus long, mais c'est plus facile et moins fatiguant que de se souvenir à quoi sont censés correspondre i, j et k dans des boucles imbriquées par exemple. Pour les refactos plus larges, le risque c'est de laisser la codebase dans un stade intermédiaire difficilement compréhensible si on remarque qu'on va dépasser le temps qu'on s'était donné. Donc effectivement, à éviter. Mais même sans tests unitaires (parce qu'on est d'accord que de la TMA sur du code spagetti c'est quasiment l'assurance de ne pas avoir de tests), si tu suis les astuces de Martin Fowler dans Refactoring, tu peux être pratiquement assuré de ne rien casser

@Nueve-w3d 2 ай бұрын

J'ai commencée ce livre en tant que junior il y'a plus 1 semaine et agréable surprise ce livre renferme des techniques très efficaces et permettra de plus vite faire du clean code sur la longue.

@ActualiteSciencesFrance Ай бұрын

Mais Simon D., que penses tu des personnes qui disent aux autres que leur code est trop perfectionné en sous-entendant qu'ils font les égoïstes alors que la personnes qui écrit le code ne fait qu'un pas vers l'avant ou est en apprentissage ? Cela doit démotiver qui, les lecteurs ou l'écrivain du code? La réalité c'est que n'importe qui peut avoir son propre avis juste parce que la compréhension de code n'est fondamentalement pas facile. Il faut arrêter de donner de fausses espoirs car on sait très bien qu'un code fonctionnels et opérationnel n'est pas forcément propre. Très philosophique. La propreté elle-même ne peut-elle pas etre subjective donc lié à une entité ?

@deskainy 2 ай бұрын

C'est marrant car j'ai eu un collègue qui a fais du code vraiment compliquée a comprendre, et ce derniers n'as jamais voulu que je fasse des correction sur sont code. Ca ressembler vachement a de l'ego mal placée car il étais plus vieux que moi ...

@LaCaverneDesCodeurs 2 ай бұрын

Quelle genre de correction auriez-vous voulu apporter à son code ?

@serge_amon 2 ай бұрын

Salut. Je cherche un paire pour le peer programming.

@afrique_cr9563 2 ай бұрын

Moi légalement

@Sahnas 2 ай бұрын

J'ai des Nike air classiques taille 44 quasi neuves très bon état 40€ a négocier

@serge_amon 2 ай бұрын

@@Sahnas le nom commun est au masculin.

@Sahnas 2 ай бұрын

Dans ce cas, ce n'est pas 'peer programming' mais pair programming et pair ne prend pas de 'e'

@krissclotilde8857 2 ай бұрын

excellent

@andersonbeauvais267 2 ай бұрын

Je me suis procurer se livre en Java mais je suis un développeur Javascript es important ?

@psycho__9945 2 ай бұрын

code propre : code que n'importe quel dev junior peut lire comme un roman et comprendre sans besoins d'explications externes oui j'ai lu le bouquin en entier.

@naturo_yatangaki 2 ай бұрын

code propre : perte d'argent qui obligera votre patron à prendre un indien pour faire avancer le projet selon ses dead lines

@psycho__9945 2 ай бұрын

@@naturo_yatangaki Il lui reste à choisir, perdre de l'argent maintenant ou plus tard.

@djcaesar9114 Ай бұрын

J'ai acheté le bouquin et je me suis dit qu'acheter la version française permettrait de financer des traducteurs. Quelle erreur: la traduction française est IMMONDE! J'ai dû l'acheter en anglais après. Le contenu du livre est très bon, en tout cas, merci du conseil lecture. Je te conseille en retour le tome 17 de Boule et Bill. Voilà, on est quittes.

@codeursenior Ай бұрын

Merci pour cette recommandation de Boulet et Bill, volume 17. Aussi, j'ai oublié de préciser que j'ai lu le livre en anglais. Au vu de votre retour, j'aurais dû ! Bon code, Simon.

@infospeople5502 Ай бұрын

n'existe-t-il pas aussi une version française

@codeursenior Ай бұрын

Hello, oui ça s'appelle "Code Propre". Mais apparemment la traduction française est "immonde". Même si vous n'êtes pas une machine en anglais, ce qui est mon cas, le livre reste accessible. Bon code, Simon.

@FatoufallNdiaye-r5w Ай бұрын

Bonsoir , ou Esce qu’on pourrait vous contacter ?

@codeursenior Ай бұрын

Bonjour, il y a une section « Contact » sur mon site angularsenior.fr. Bon code !

@headshotmaster3401 2 ай бұрын

good

@codeursenior 2 ай бұрын

Thanks man.

@sarazar928ghost9 2 ай бұрын

Concernant le code a 11:00 , je préfère conserver les boucles fait mains qui sont plus rapide que de faire un filter puis flatMap puis encore filter, car a chaque fois il parcours tout et donc ça fait 3 fois plus de travail, donc le code est aussi 3 fois plus lent. J'ai fais cela par exemple qui je pense est propre ? Peut-être pas je sais pas, le mieux est d'utiliser TypeScript : /** * @param data * @return All infos above value 10 from datas active */ function checkResponseData(data){ const allActiveInfoAbove10 = []; for(let i = 0; i < data.length; ++i){ if(data[i].status !== "active") continue; const info = data[i].info; for(let j = 0; j < info.length; ++j){ if(info[j].value

@josedesousa5789 2 ай бұрын

Le pire programming ?! Ou le peer programming ?! 😉

@codeursenior 2 ай бұрын

Non non je parle bien du « pire programming ». 😅

@v-sig2389 2 ай бұрын

Ha, il y a des wtf dans ta description 🤓🥸

@pierreollivier1 Ай бұрын

Super video qui plus est tu n'as souligner que les bons conseils de ce livre, le reste etant beaucoups moins pertinent voir totalement a coter de la plaque.

@codeursenior Ай бұрын

Hello, il y a des critiques sévères sur certains point ms du livre, notamment le DRY. Cependant le livre est juste LA référence pour démarrer dans la littérature du code, et il y a beaucoup d’autres éléments intéressants du livre que je n’ai pas abordé ici.

@gungun974 2 ай бұрын

Personnellement je n’ai pas aimé ce livre la et je n’ai pas désirer regarder l’analyse d’un vieux framework de test unitaire Java. Après je ne dit pas que certaines idées sont importantes mais je trouve faire une livre complet pour parler de petite idée pour simplifier et rendre le code plus claire pourrait tenir dans une seule page d’un blog. Après je ne dit pas que Oncle Bob est mauvais, son livre « Clean Architecture » ma beaucoup plus et ma parmi de mieux comprendre une structure qu’aujourd’hui encore me plaît beaucoup où la logique métier est valorisé et bien structuré même si je dois le dire qu’avec le temps je préfère légèrement tendre cette structure en ignorant les interfaces et créer uniquement les interfaces de mes adapteur quand la logique devient compliqué qu’un bon test unitaire devient utile.

@jpouly 2 ай бұрын

Mouais, coder proprement c'est déjà de mettre des noms de variables qui ont du sens, de mettre des commentaires et surtout de penser à la maintenabilité. Ça sert à rien d'optimiser à mort si à la moindre évolution tu es obligé de tout jeter à la poubelle.

@codeursenior 2 ай бұрын

Hello, l’intérêt du clean code est justement de pouvoir itérer rapidement sur le code existant. Donc rendre le code existant facile à manœuvrer en cas d’évolution.