J'ai été formé (formation professionnelle de dév, pas d'école d'ingé) par un dév qui avait + de 25 ans de carrière. Un jour, il a débuté un cours avec une question : "Qu'est-ce que c'est qu'un mauvais développeur ?" Sa réponse (avec laquelle je suis entièrement d'accord et à laquelle je repense à chaque nouvelle expérience) est : "un mauvais développeur, c'est un développeur qui se rend indispensable". Cela dit, merci pour les vidéos. :)
Un bon développeur, c'est un gars qui prend son clavier et qui crache du code. Le mauvais développeur lui, il prend son clavier, il crache du code mais c'est un mauvais développeur. 🤣 Je ➡ .
C'est assez rare, mais la vidéo est apparue dans mes recommendations RU-vid, je l'ai regardé entièrement, puis j'ai liké, je me suis abonné, et j'ai activé toutes les notifications. En fait j'ai cliqué sur la vidéo en me disant, "qui sait, peut-être qu'en dépit de mes 4 années d'expérience, je commets encore ces erreurs de débutant" et effectivement, il y en a au moins 2 que je comments pas souvent mais pas très rarement non plus on va dire. Du coup j'ai bien aimé le contenu de la vidéo, tant sur le fond que sur la forme (son humour). Donc merci Simon.
Pour l'exemple du if digital/physique, on peut aussi profiter dans ce contexte du fait qu'il n'y a que 2 valeurs possibles au moment de la conception. Et donc au lieu d'un if 'digital', plutôt tester un if !=='physique'. Ce qui passera totalement inaperçu dans le développement, justement grâce au contexte, mais une bombe à retardement dans l'évolutivité.
Ouch ça c'est fourbe ! Comme ça avec un peu de chance le suivant qui voudra faire un refactoring par search and replace va remplacer seulement les 'digital' et pas les 'physical'
J'aurai tendance à recommander un mix : tantôt "if digital" et tantôt "if !physique" comme ça on rend le comportement bien imprévisible en cas d'ajout d'un 3ème état =)
Bien d'accord avec cette vidéo. Ca s'applique pas qu'au web. On pourrait ajouter aux commentaires décrivant le quoi et pas le pourquoi les textes de commits faisant la même chose. Par contre si tu réussis à choper un jour des devs google, essaie d'attraper ceux qui ont pondu go et ses conventions/conseils de nommage...
J'aime ce type d'humour,je t'avoue que jusqu'à ce que tu annonce que c'était a prendre avec humour je me disais que tu étais tombé sur la tête 😄 je m'abonne pour la peine 👍
Petite remarque : le nom des variables n'a pas besoin de répéter le contexte dans lequel elles sont utilisées (exemple : "password" serait suffisant dans une classe AdminProfile)
Hello @Galmiza, 100% d'accord. Le contexte peut venir du nom de la classe. A l'utilisation, vous obtiendrez : `admin.password`, ce qui est parfaitement clair.
Salut Simon, encore une excellente vidéo, tellement pertinent! Un Trésor pour tout DEV et quel que soit le langage! Merci infiniment, ça me donne presque envie de rassembler tous mes DEvs et les obliger à regarder cette Prez avec écarquilleurs d'yeux à la OrangeMécanique!😁 Bonne continuation à toi!
Développeur Python depuis 16 ans , j’ai trouvé ta vidéo excellente et très drôle. C’est exactement le message que j’essaye de transmettre aux devs moins expérimentés que je croise. Le nommage des éléments est tellement important. Un code bien nommé peut éviter 90% des commentaires. De plus, je le vois un peu comme un message dans le temps. Quand j’écris du code je m’imagine m’écrire à moi même dans le futur. Enfin ce genre de conseil est explicitement décrit dans le « zen of python » lui même inclus dans ce langage (faire « import this » dans un terminal python 🙂) Bref, en résumé très bonne vidéo avec beaucoup d’humour 🙂
Hello Alexis, merci pour ton message. Notamment cette phrase que je trouve intéressante : "De plus, je le vois un peu comme un message dans le temps.". Cest exactement ça ! Pour le zen python, un collègue m'en a parlé également. J'approuve à 100%. 👍 Bon développement, Simon.
salut Simon je suis un dev react fans de tout ce que tu fais et j'ai une préoccupation ! en réalité j'ai coder une application web reactjs et j aimerais améliorer son Référencement as tu une idée a me proposer car tout refaire en nextjs serais vraiment très fastidieux. merci pour ton retour
J'ai pas arrêté de rire devant ces précieux conseils :) Le pire c'est que je me reconnais un peu là dedans! Autres anti-patterns auxquels je pense: - créer des issues longues, non structurées et peu claires et largement over estimer le temps requis pour leur complétion - commit et PR description ne détaillant absolument pas ce qui a été fait - review le code des autres sans aucun effort
Je suis agréablement surpris, cette vidéo est très sympathique, limite plus dans sa forme que dans son fond. (+1 abo) Globalement je suis d'accord avec tout (surtout pour le nommage variable/method), mais je pense que la partie commentaires/docs reste à tempérer, car de mon avis, si le trop est l'ennemi du bien, pas asses n'est pas correcte pour autant.
Hello Lod, merci pour votre message ! Pour moi la doc d'un projet pour les développeurs doit tenir sur une feuille A4 dans le Readme.md. Pour le reste c'est le code qui parle. Je pourrai faire une vidéo dédié là-dessus.
A propos des "magic strings" que penses-tu de la déclaration de variables dont le nom représente la valeur, genre toto="toto"? Je vois ça absolument partout dans un projet, c'est un enfer absolu.
Je me souviens d'un collègue qui donnait des noms de variables comme "batman", "robocop" ou "luckyluke" dans son code. Dans le domaine bancaire, je précise…
Haaa, enfin quelqu'un qui valide officiellement l'anti-pattern des commentaires obligatoires dédoublant le nom d'une méthode avec un commentaire inutile. //Cette méthode multiplie par deux MultiplyByTwo(x) => x*2; D'ailleurs, ça porte un nom en anglais : *un-documentation* ("dé-documentation").
Je passe une bonne partie de mon temps à me battre avec mon équipe pour que les noms de variables, de classe ou de méthode veuillent dire quelque chose. Ouf, me voilà rassuré grâce à ta vidéo : je ne suis pas fou 🤣
Salut Aram, c'est chose courante dans VueJS, mais il me semble que ce n'est pas dans la philosophie d'Angular. Cependant, je n'ai rien contre en soi, c'est un choix de l'équipe. Bon développement, Simon.
C'est assez drôle, si on veut mettre le chaos dans son équipe on sait comment faire au moins😂 et sinon j'ai rejoins ta formation pour maitriser angular et j'ai un petit problème je t'ai tout expliqué dans un mail ^^
Quand tu regardes cette vidéo en tant que dev junior et que tu te rends compte que ton ex leadtech (qui bossait ailleurs en même temps) a rempli 4 des 5 anti-patterns.
Bonjour Jérémy, excellent anti-pattern qui mériterait une place dans la vidéo ! Bien sûr avec le plus de documentation et de tests possibles cela va de soi. 👌
Le pire c'est comme tu l'a dis à la [10:20] minute, l'usage de cette anti-partern est une arme qui peut bien nous abattre si on imagine qu'on revient sur une portion de code plusieurs mois plus tard.
Hello, non je vous déconseille ma chaîne pour partir de zéro. Vous pouvez partir sur d'autre contenu sur Internet autour de la création d'un premier site web, générallement HTML/CSS/PHP/MYSQL/BOOTSTRAP. Bon apprentissage, Simon.
oups 12:30 déjà utilisé des compteurs i,j,k,etc puis expliqué en commentaire ce que ces compteurs faisait 🤭 Mais quand on n'a pas d'inspiration… que faire ? 🤔
Prendre ce que tu itères et rajouter Index, tu itères des products ? productIndex, tu itères des articles ? articleIndex. Pas besoin d'inspiration juste de règles de nommage
Hello, remplacer une variable de une lettre par une variable avec 2 mots comme le suggère Cédric. Si vous êtes en panne d’inspiration je vous invite à lire beaucoup de bon code (site spécialisé), on s’habitue au code lisible et efficace. Comme quand on apprend à écrire, cela aide beaucoup de lire des textes sans fautes en parallèle.
Dans une de mes boites, 1) les commentaires étaient interdits (sauf démonstration de math) 2) les acronymes/abréviations/notation-hongroise étaient interdits.
Pour les commentaires, ils ne sont pas négatifs par eux même, c'est le manque de rigueur qui les entoure qui est problématique. Par exemple, un commentaire doxygen ou javadoc maintenu avec la fonction peut être très précieux... mais cela exige d’imposer la mise a jour lorsque l’on touche a la fonction. Un commentaire TODO a l’avantage d’être géré par l’IDE et utilisé avec parcimonie (et uniquement pour signaler des ajoutes à faire dans le futur, certainement pas pour indiquer qu’un code ne doit pas être modifié) est aussi un outil utile. Le problème est à mon sens que les formations en informatique oublient l’aspect commentaires et laissent le sujet a l’appréciation/improvisation des étudiants...
Autant que possible, il vaut mieux remplacer les commentaires par du code lisible. :) Mettre à jour des commentaires ça prend du temps, c'est laborieux et ça casse un peu le fil de notre réflexion. C'est pour ça que souvent on oublie de les mettre à jour, on préfère finir de coder la fonctionnalité avant... puis après on oublie. :D Si on veut générer une documentation alors oui c'est important le style Javadoc ou autre, mais à part lorsqu'on code une API qui doit être utilisée par des tiers, on a rarement besoin de doc.
@@maoowww et puis un jour, on se retrouve a devoir gérer un code kilométrique créé par une personne qui n’est plus là, sans aucune documentation, cette dernière étant "égarée" dans une logique métier où les utilisateurs demandant une mise à jour vous répondent "je ne sais pas, c’est le programme qui le calcule"... Been there.
@@vapulabe Par code kilométrique, j'imagine que tu parles d'une énorme suite de lignes de code difficiles à lire ? Genre codée par quelqu'un qui manque cruellement d'organisation. C'est vrai, j'ai peut-être pas assez insisté dans mon message, mais l'absence de commentaires doit être associée avec des principes de codage strictes, comme la responsabilité unique, le principe KISS, le bon nommage des variables, l'utilisation de Design Patterns appropriés, etc. A une époque j'écrivais beaucoup de commentaires. Puis j'ai rejoint une entreprise assez grosse, dans une équipe de devs plus compétents que moi. Et une des 1° choses qu'ils m'ont appris c'est que le code doit s'auto-documenter. Par exemple au lieu d'avoir une fonction de 100 lignes de code, tu sépares en plusieurs fonctions de 10 lignes (je caricature un peu), chaque fonction étant bien nommée pour décrire son action. A partir de là il n'y a plus besoin de commentaires. Il faut aussi associer ça au travail en équipe, avec des reviews de code régulières en binôme, et moins régulièrement en sale de réunion sur le vidéoprojecteur, avec toute l'équipe présente. :) Il n'est pas admissible qu'un gars code des trucs illisibles dans son coin pendant des mois, c'est un échec de l'équipe, pas seulement de ce dev. :) Amicalement.
@@maoowww le code complet avait été réalisé par une personne seule (pas par une équipe, il n'y avait tout simplement pas d'équipe). Il était bien structuré mais le programme était très complexe et manipulait pas mal de formules sans aucune information sur l'origine de la dite formule (gestion d'un service social dans l'enseignement, on imagine pas le nombre de contraintes, de calculs et autres derrière les conditions d'octroi, les calculs fiscaux etc... C'était loin d'un simple CRUD.. et ce n'était pas la partie CRUD qui posait problème.
Pour donner un exemple, le nombre de "personnes à charge" était calculé de 3 ou 4 manières différentes selon les contextes (octroi et montant de bourse, calculs de revenus imposables et autres)... sans aucune information pointant le contexte législatif et permettant donc de s'y retrouver. Et la documentation papier avait été égarée avec le temps... La personne ressource était pensionnée et les remplacantes incapable d'expliquer quoi que ce soit parce que "le programme calculait tout"
Pas trop fan de la partie sur les noms de variables courts plus performants pour la machine. Ce n’est pas "en partie vrai". C'est "rarement" vrai. Tout dépend des cas. Généralement avec un langage compilé vers du natif (C, Rust) ou vers un bytecode (Java, C#), le nom des variables n'est pas inclus dans le livrable et n'a donc aucun impact sur les performances. Certains noms peuvent être inclus (nom des classes, méthodes, champs…) si la réflexion est supportée par le langage mais ça ne va pas avoir des masses d'impacts sur les perfs. Avoir des noms courts peut impacter les performances sur les langages où le nom des variables est inclus dans le livrable tel que JavaScript et PHP. Et l’impact peut en effet être important pour le JavaScript, non seulement à cause de l’exécution mais aussi à cause du téléchargement du fichier .js si la connexion est en carton. Une solution est la minification, mais dans ta vidéo, on pourrait croire que c’est la machine qui va exécuter le livrable qui va minifier, alors que la minification se fait généralement lors de la création du livrable, sur la machine du développeur.
Je croise tellement pire au quotidien, une bonne partie de ce qui est mentionné ici peut être détecté et corrigé avec une analyse sonar (pour les Magic number c'est vrai à partir du moment où c'est utilisé à plusieurs endroits par contre). Au final, dans mon travail j'ai l'impression que ce n'est pas le code qui est le plus problématique mais les process à la con qui te font endosser le rôle de chef de projet en étant dev (le mot alarme étant DevOps, faut surtout pas donner d'autonomie à un dev, il pourrait péter la prod tu comprends!). Du coup si tu veux empêcher un projet de voir le jour, tu demandes à créer une tâche qui va passer dans 3 mains différentes au minimum. Tu laisses bien la demande pourrir en faisant fi du SLA de la demande. Tu réalises la demande à moitié et tu la fermes sans laisser la possibilité de la rouvrir, et quand la personne vient te voir pour te dire que ce que tu fais ne marche pas, tu lui demandes de recréer une demande. Point bonus, tu renvoies la patate chaude à un autre service pour faire une partie de la demande.
l'exemple de départ était foireux pour le file de ta présentation, meme si je comprend l'intention, il n y a pas de rapport hormis la mauvaise gestion du stress lié au deadline. Mais le plus problématique dans l'ensemble, c'est qu'on part du constat qu'on a largué des dev junior sans aucun chaperonnage... Rien de tel pour détruire un projet ainsi que les compétences futur des juniors qui risque de se conforter dans des méthodes de travail et réflexions de conception biaisé >>
Je suis mort de rire, comment t'arrive à ne pas éclaté de rire, avec tout ses phrases antilogique? et si proche d'un réel "tuto" ? J'approuve ton travail ! ( même si je me doute qu'il faut faire tout l'inverse )
Alors je m'attendez pas du tout à ce genre de vidéo ! Mais le pire c'est que dans mon équipe j'ai un lead qui fait le "silo" et le pro de la "comm". Tout le monde le vois sauf le responsable, son taff est fait pas 90% des devs mais pas lui. On l'appelle l'anguille 😆
