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

si vous souhaitez devenir développeur senior pour être bien payé travailler en full remote pour voyager ou encore vous lancer en freelance et bien il n'y a qu'un seul livre à lire avant ce soir c'est le fameux clean code de Robert Martin C dans cette vidéo je vais vous donner les cinq meilleurs conseils que j'ai lu dans le premier chapitre de ce livre et j'ai choisi de pas faire une vidéo où je parcours tout le livre parce que je pense que ça serait trop survolé la richesse que vous pouvez trouver dans ce bouquin aussi j'ai choisi de présenter ce livre en premier sur la chaîne puisque c'est le livre de code qui m'a fait découvrir tous les autres et à mon avis si vous souhaitez devenir vraiment bon en tant que développeur et bien il vous faut un peu de littérature sur le sujet puisque ça va vous permettre de capitaliser sur ce que les Anciens développeurs des générations précédentes ont déjà découvert plutôt que de passer 10 20 ou 30 ans de votre vie à les redécouvrir par vous-même et la leçon numéro 1 du premier chapitre de Clean code et bien c'est la what fuck d'or c'est-à-dire la porte du what the fuck donc c'est vraiment dans les premières pages du livre vous allez tomber sur cette fameuse porte du what the fuck quand je suis tombé sur cette illustration j'ai tout de suite su que j'allais adorer le livre puisque effectivement au quotidien dans mon travail et sur des projets persos quand je reliser mon vieux code la première chose qui me venait à l'esprit c'est what the fuck qu'est-ce que c'est que ce code qu'est-ce qu'il fait pourquoi il a été conçu comme ça alors par rapport à cette porte et bien la plupart des gens s'arrêtent sur cette illustration amusante et on pousse pas plus loin la chose c'est-à-dire que ça serait une sorte de même rigolo mais je pense que le livre veut faire passer un message qui va un petit peu plus loin puisque l'auteur affirme de manière claire et nette que la seule manière de mesurer du code de qualité et bien c'est le taux de what the fuck par minute quand vous lisez un fichier qui fait admettons 1000 lignes est-ce que vous avez un taux de what the fuck de 50 % c'est-à-dire une ligne sur deux ou un taux de what the fuck de 10 % c'est-à-dire que 9 liges sur 10 sont plutôt claires et vous comprenez ce que le code fait et il le fait bien donc selon moi c'est plus que une illustration amusante c'est vraiment un critère de mesure sur un projet quelles sont les portions du code sur lesqueles les développeurs se casse la tête et produisent plus de bugs que de résultats le seul problème qu'on pourrait reprocher à cette métrique qui est à la fois sérieuse et amusante c'est qu'elle peut être subjective c'est-à-dire que au moment où j'écris du code qui va devenir du what the fuck code j'ai toujours l'impression qu'il est clair c'est-à-dire que la première version d'un code que vous écrivez vous-même dans les heures les jours qui suivent vous avez encore le contexte du code en tte et donc il vous paraît plutôt acceptable donc la métrique du what the fuck code pour ne pas être seulement humoristique mais un peu sérieuse et bien je vous recommande de relire du code dans lequel vous n'avez plus le contexte en tête donc relisez le code des autres faites relire votre code par les autres ou alors relisez du code que vous avez écrit vous-même mais il y a 6 mois ou un an et vous allez voir que en réalité votre code est pas forcément très clair c'est à ce moment-l que vous devez faire passer le what the fuck test donc une des manières de faire baisser le what the fuck dans votre code et bien ça va être des choses assez classiques mais qui fonctionnent très bien par exemple la code review avant de livrer le code que vous venez d'écrire avec vous votre contexte en tête et bien faites-le relire par les autres peut-être que ça n'est pas si clair que ça et donc prenez le feedback des autres comme quelque chose qui a énormément de valeur même si c'est désagréable et que vous vous dites mais enfin c'est très clair ce que j'ai écrit les gens sont stupides ou quoi non prenez le fait qu'ils ont pas votre contexte en tête comme un feedback qui a vraiment une grande qualité pour faire baisser le what the fuck dans votre code une autre chose que vous pouvez mettre en place c'est le pire programming c'est-à-dire coder à deux vous allez vous rendre compte que vous travaillez avec des gens depuis peut-être 6 mois et que en fait vous fonctionnez pas du tout de la même manière et enfit une dernière chose qui m'aide beaucoup c'est d'être très sérieux sur le nommage vous devez construire un nommage qui est consistant qui est cohérent à travers toute la code base et ça n'est pas forcément évident il y a parfois des choses où on a l'impression de manipuler le même concept mais en fait en sous-jacant ça devrait être de nomages différents et enfin en bonus une des choses qui m'aide beaucoup à faire baisser le what the fuck dans le code que j'écris c'est que si j'écris du code en me disant oh là là je vais avoir l'air intelligent je vais impressionner les collègues en code review avec ce code généralement c'est très mauvais signe ça veut dire que vous avez écrit du code pour votre ego plutôt que de viser la simplicité pour délivrer de la valeur donc quand je ressens cette espèce de sensation de ego code où j'ai codé un truc où j'ai l'impression que je vais impressionner la galerie généralement il faut relire votre code et partir sur une approche beaucoup plus simple donc la porte du what the fuck est quelque chose de très sérieux ne la sous-estimez pas deuxième leçon que j'ai appris dans ce chapitre pareil sur les premières pages qui est super importante c'est que le code informatique le fait de coder c'est pas un petit marché c'est un marché qui pèse plus de 1000 milliards de dollars et qui est géré par des enfants de 25 ans d'après l'auteur en effet depuis 7 ans que je code professionnellement et bien les développeurs qui avaient plus de 40 ans et une expérience de au moins une décennies dans l'activité de production logicielle et bien je les compte sur les doigts d'une main et effectivement cette industrie est très étrange puisque le code logiciel est vital pour beaucoup d'entreprises donc c'est quelque chose de très sérieux le logiciel est partout dans notre société et pourtant on s'est développé un peu à la va vite à la légère dans beaucoup d'entreprises où on va mettre 1 2 3 juniors sur un projet crucial qui a des impacts sur des vrais gens imaginez que on fasse construire des bâtiments ou des voitures par 4 personne de 25 ans ça semblerait très étrange pareil si on cherchait à sortir un nouveau médicament et donc l'auteur se pose la question pourquoi il y a aussi peu de développeurs expérimenté dans notre industrie il parle de quelque chose de très important c'est-à-dire que pour la plupart des gens le métier de développeur c'est simplement de venir écrire le code qui marche c'est-à-dire on va faire un tour sur la documentation officielle sur Stack Overflow on copycle des bouts de trucs et puis quand le compilateur passe et que la fonctionnalité a l'air de marcher et bien on s'arrête là et on livre le code mais en réalité votre vraie mission ça va être de produire du code qui peut être maintenu pendant des années sur la plupart des produits sur lesquel vous allez intervenir votre code il doit pas marcher pour ce soir il doit être maintenable pour les 10 prochaines années par exemple et cette notion du code jetable et bien on la retrouve très fréquemment il y a un paquet d'entreprises qui ont des solutions qui existent depuis 20 30 ans mais dans laquelle la maintenabilité a pas été pris au sérieux depuis le départ et on se retrouve avec des entreprises qui doivent réécrire de zéro des logiciels qui ont 20 ans d'existence donc c'est très risqué pour ces entreprises ça coûte très cher et parfois il aurait pas fallu grand-chose pour sortir de la situation mais pour ça ça demande de l'expérience et donc il faut des développeurs expérimentés ce que j'essaie de faire à titre personnel via cette minuscule chaîne Youtube et bien c'est de donner envie aux gens de rester dans le code et de donner une vision plus large de notre métier que l'aspect un peu étroit de faire du code qui marche donc pour ça j'ai deux missions une espèce de mission publique à à travers la chaîne Youtube qui est de faire connaître le code professionnel au plus grand nombre de personnes et espérer qu'il ait plus de gens qui veuillent devenir développeur ça permettra entre guillemets d'attirer plus de talent potentiel dans notre industrie et puis pour les gens qui codent déjà leur donner envie de rester dans ce métier parce que si au bout de 5 ans de développement mais bien vous passez manager parce qu'on vous a dit que c'est la suite logique et que vous serez mieux payé et bien il y a jamais de gens expérimentés qui restent dans le métier du code et donc on se retrouve avec une industrie qui comme l'auteur le dit pèse 1000 milliards et géré par des enfants de 25 ans la leçon numéro 3 du livre et bien c'est qu'est-ce que le code propre puisqueen fait le livre a comme titre clean code et donc il y a quelque part l'arrogance de il y a du code propre c'est nous qui allons le définir dans le livre et puis il y a du code sale c'est les gens qui respectent pas ce qu' a écrit dans le livre et l'auteur commence par quelque chose de très intéressant c'est qu'il va interviewer plein de gens qui sont des pointures dans notre industrie par exemple l'inventeur du C l'auteur du livre working with Legacy code le co-inventeur de l'extrême programming et toutes ces personnes influentes donnent leur définition du code propre et ce qui est très intéressant c'est que aucun n'a la même définition c'est-à-dire que en tant qu'industrie c'est quand même assez compliqué de se dire que il y a du code propre et sale de manière arbitraire par contre tous leurs avis tendent à concorder vers ce que moi j'appelle la maintenabilité la flexibilité et la testabilité du code plus un code vient renforcer chacun de ces trois piliers plus c'est du code solide la maintenabilité c'est très simple c'est quel est le coût opérationnel de votre code base et ce qu'il vous faut 3 jours ou 3 mois pour former une nouvelle personne pour qu'elle puisse développer des fonctionnalités sur votre projet ou encore combien de bugs est-ce que vous créer à chaque fois que vous touchez telle ou telle page ça ça va être la maintenabilité la flexibilité ça va être tout le code que vous avez développé jusque- là est-ce qui vous permet d'aller plus vite ou est-ce qui vous ralentit pour vos nouveaux développements ce qui est très amusant c'est qu'on a des projets qui existent par exemple depuis 3 ans on doit venir rajouter une fonctionnalité très simple comme un bouton par exemple mais il y a tellement de couches d'architecture lecture qui nous contraignent que pour rajouter ce bouton et bien il va falloir se former pendant un mois et utiliser 14 classes et donc en fait tout le code qu'on écrit jusque- là nous ralentit et l'application devient un gros bousin qui est de plus en plus lent à développer pourtant on se dit on a déjà 2 ans de code derrière nous on aurait dû avoir des outils qui nous permettent d'aller plus vite que si on partait de zéro ça c'est la flexibilité et puis enfin la testabilité c'est même pas que votre code a des tests unitaires c'est est-ce que vous pourriez tester votre code facilement dans la plupart des cas le code a trop de coupling à trop de responsabilités et pour écrire des tests unitaires sur la page en question et bien ça demanderait un travail disproportionné par rapport au gains potentiel donc écrire du code en faisant comme si on allait le tester même si vous n'écrivez pas de test en bout de chaîne c'est un excellent exercice pour améliorer la qualité du code et tendre vers le fameux clean code la 4ème leçon extrêmement importante aussi et qui encore une fois vient dès les premières pages du livre ça va être d'optimiser le code non pas pour l'auteur c'est-à-dire vous quand vous écrivez votre code mais pour le lecteur quand quelqu'un vous explique qu'il va écrire plus vite du code en utilisant des tout petits acronymes ou des lettres à la place de variables qui ont un vrai sens c'est généralement très mauvais signe pour la simple et bonne raison que 90 % de votre temps vous allez lire du code plutôt qu'en écrire et ça c'est extrêmement important à comprendre chaque fois que vous allez écrire une ligne de code elle va peut-être être relu jusqu'à 9U fois par vous ou votre équipe imaginez le code que vous voyez à l'écran vous devez intervenir là-dedans est-ce que vous avez la moindre idée de ce que fait ce code même si je vous donnais une minute pour le relire probablement pas donc quand vous allez intervenir là-dedans ça va vous prendre beaucoup de temps et vous risquez d'introduire potentiellement des bugs l'auteur recommande donc de plutôt que de livrer le code que vous voyez à l'écran et bien de prendre le temps de le relire pour l'optimiser pour le lecteur c'est-à-dire vous plus tard ou vos collègues donc voici le même code que précédemment au sens où ça fait la même chose et pourtant regardez comme le code est beaucoup plus rapide à relire même si vous avez pris 10 minutes de plus pour refactoriser votre code pour obtenir ça et bien ça vaut le coup parce que c'est beaucoup plus agréable de tomber sur du code comme ça plutôt que la V1 qu'on a vu juste avant même si c'est plus rapide à écrire parce que vous avez fait un premier G comme ça intuitivement donc coder pour les autres soyez Friant du feedback des autres et ne restez pas cramponné sur votre V1 qui est sorti de votre tête comme ça et enfin la 5ème leçon la plus importante du chapitre 1 du livre clean code et bien ça va être la boys scoot rule la règle des boys scoot cette règle me parle particulièrement puisque j'ai été scoot moi-même quand j'étais plus jeune et une des leçons du scootisme et bien c'est de laisser le camp plus propre que ce qu'on l'a trouvé c'est-à-dire que quand vous venez planter le camp à un endroit pour manger le soir s'il y a des sachets plastiques partout et que c'est dégueulasse et bien on va pas les laisser en disant que c'était comme ça on va prendre le temps de nettoyer le camp et quand on repart le lendemain c'est plus propre que la situation de base et en fait c'est une excellente analogie avec le code c'est-à-dire laisser le code plus propre que ce que vous l'avez trouvé concrètement ça signifie que quand vous devez intervenir dans dans un fichier par exemple pour ajouter une fonctionnalité et bien vous avez le droit de regarder le design du code existant de regarder comment sont écrits les commentaires et de regarder s'il y a certains traitements qui sont pas beaucoup trop lourds par rapport à ce que ça fait et vous avez le droit de reprendre ce code si vous êtes amené à interagir avec lui pour implémenter votre fonctionnalité et bien donnez-vous le droit de refactoriser un petit bout de méthode venir corriger un petit commentaire si ça paraît pas trop risqué et c'est plus qu'un conseil c'est vraiment une règle que je vous recommande de suivre puisque sinon au fur à mesure de vos développements au fur et à mesure de la correction de bug et bien le design du code vient petit à petit se désagréger puisque'en permanence on est obligé de faire des tradof entre la qualité et l'urgence d'une livraison on est obligé d'intervenir dans une code base qui est potentiellement gigantesque donc on a pas forcément tout le design du code en tête donc peut-être qu'on va venir introduire une petite maladresse et cetera et cetera donc si vous n'appliquez pas la boy SCOT rle ou que vous êtes pas dans une équipe à qui ça tient à cœur et bien vous allez petit à petit travailler dans une code base qui ressemble au champ dont je parlais tout à l'heure avec avec des sacs plastiques qui traînent de partout vous voulez probablement pas travailler dans une code base comme ça où tout le monde en a rien à et où c'est de plus en plus sale donc comme je vous le disais c'est plus qu'un conseil ou un truc sympa c'est vraiment une éthique professionnelle et une culture que vous pouvez construire dans l'équipe dans laquelle vous allez intervenir et on retrouve d'ailleurs ce concept dans le refactoring de Martin fer où il recommande effectivement de refactoriser toutes les heures ce qui revient appliquer la boy SCOT rule en permanence comme une éthique de travail voilà c'était les cinq leçons du premier chapitre de cleanc code j'espère que vous êtes convaincu de la densité de cet ouvrage puisque simplement pour un premier chapitre il y a déjà un paquet de pépites à se mettre sous la dent donc bien sûr ce livre va pas faire de vous un développeur senior du jour au lendemain c'est pas parce qu'on lit un livre sur l'art qu'on devient artiste mais ça va vous donner des pistes de réflexion ou quand vous codez vous allez vous dire ah effectivement est-ce que c'est pas le moment d'appliquer tel ou tel conseil que il y a dans ce bouquin donc même si c'est pas une pilue magique la lecture de ce livre m'a beaucoup apporté pour progresser en code et je peux que vous recommander de le lire c'est un classique voilà merci d'avoir pris le temps de m'écouter j'espère que cette vidéo vous a apporté de la valeur et si vous cherchez à devenir développeur web professionnel et bien voici trois manières dont je peux vous aider gratuitement premièrement je publie une vidéo de temps en temps sur cette chaîne Youtube où je partage mon retour d'expérience de développeur avec 7 ans d'expérience pas besoin de vous abonner vous pouvez repasser quand vous en avez besoin deuxièmement si le sujet vous intéresse du code professionnel en entreprise et bien vous pouvez interagir AC avec la chaîne mettre un pouce bleu poser vos questions en commentaire l'objectif c'est pas de travailler pour l'algorithme mais c'est de faire connaître la chaîne pour que demain on ait plus de poids si je veux interviewer une pointure dans notre industrie par exemple le fait qu'on soit 40000 sur la chaîne je pense a pu nous aider à interviewer l'ex co de Malte qui a géré une équipe de plus de 100 développeurs avoir le retour d'expérience de ces personnes est extrêmement intéressant je pense pour nous en tant que développeurs et enfin si vous êtes intéressé pour aller plus loin et commencer à coder et bien j'ai j'ai un workshop sur le site angularsenior.fr où je vous montre en trois soirées de code ce que je pense qu'il faut absolument savoir pour votre premier jour en entreprise si vous avez une mission sur angulara ce workshop est pour l'instant accessible librement sur le site vous pouvez cliquer sur le lien en description sous la vidéo pour démarrer tout de suite en tout cas je vous dis à bientôt pour une prochaine vidéo bon code seigneor d'ici là et à la prochaine Ciao