Je trouve que ca manque d'exemple concret, pour un neophyte il est difficile de se faire un idée de ce que concrètement ca implique et de comment appliquer ce concept
J'aime beaucoup cette nouvelle définition plus claire pour moi que la notion de responsabilité. Merci beaucoup pour tout ce contenu qu'on ne trouve pas ailleurset ce genre de réflexion plus peofonde m'aide à structuree ma façon de penser le code.
Je ne sais pas si tu abordes le sujet quelque part, mais une structuration du code en couche technique vs couche business, permet de bien aborder le problème : ta couche technique va être composée de "composant spécialistes d'aspect techniques" (et donc c'est le techos qui va savoir comment splitter ça au mieux), mais la couche "business" elle, on se rend bien compte tout de suite que ce n'est pas au développeur de décider comment se découpe le business de la société (compta, rh, commercial avant-vente, etc), , mais bien au fonctionnel. Ca a l'avantage également de séparer les problématiques techniques (réseau, filesystem, DB, etc), des problématiques métiers, et d'avoir plus de chance de garder un coeur fonctionnel "pure" (sans I/O).
C'est interessant ce que tu dis, je partage ton avis. je travaille dans une grosse structure ou je n'ai même pas un accès directe aux bases de données. je ne gere pas la sécurité non plus(JWT, Oauth2, gateway...) etc... nous n'avons même pas le droit de créer des champs n'importe comment, c'est le metier qui le decide. Il y a beaucoup de chose que nous ne gerons pas. Notre code doit juste s'adapter au business logic de l'entreprise et non le contraire.
100% d’accord avec ce qui est dit en commentaires. Ce n’est pas les développeurs qui décide du business, on « découvre » le métier à modéliser (domain driven design). L’architecture hexagonale/DIP est notre meilleure atout pour séparer le code business des implémentations techniques.
Hello, 2 chose, un du contenue de cette qualité sont vraiment RARE. Le workshop et génial. Vraiment merci pour tous le travail que tu mais à dispo. ça aide vraiment
Hello, tout à fait. Cela rentrerait dans une série de vidéo "review de livre" sur Clean Architecture. Ce n'est pas prévu tout de suite, mais c'est sur la todo list. 👍
C'est un sujet très intéressant. C'est un principe qui semble à prime abord simple mais en réalité, il est très difficile à comprendre et à appliquer efficacement. J'essaie de le mettre en pratique en entreprise mais j'avoue que je ne suis toujours pas sur de l'avoir vraiment compris.
Hello, selon la dernière définition, pour bien appliquer le principe il faut comprendre les ressources (équipe & tech) et les problème de votre client. Donc rien de très simple effectivement !
J'avais déjà lu cette définition dans un article de Uncle Bob, mais sans l'avoir bien intégrée. Je comprend mieux le principe avec cette vidéo, et j'ai bien aimé l'exemple du garagiste, qui est bien parlant. Donc, vidéo très intéressante.
Salut Philippe, merci pour ton retour. C'est ce qui m'est arrivé aussi en préparant la vidéo. Je me suis rendu compte que j'étais passé à côté de la version la plus "à jour" de ce principe. Bon code !
Merci pour votre retour, j'envisage de poursuivre certains vidéos dans ce format, en essayant d'ajouter un peu plus d'exemple de code concret, comme dans l'article en rédaction que vous m'avez envoyé. 👍
En écoutant cette vidéo je me suis posé la question sur l'incohérence avec l'idée du DRY. Si un objet doit être dédié à un seul type d'acteur. Si deux acteurs différents font des choses qui sont en partie identiques alors dans l'idée il va falloir se répéter à deux endroits différents. Du coup ça nécessite encore de la réflexions quand on met en place ce type de solutions.
@@StarshipBattlesystem avant tous ces concepts d'optimisation et de clean code toussa y'a un principe de base : si un morceau de code se répète, tu peux en faire une fonction et l'appeler où c'est nécessaire.
Ce n’est pas une incohérence, c’est une alternative. Le principe DRY est sur côté et pause autant de problèmes qu’il n’en résout. Vous allez passer votre temps à créer des abstractions. Je préfère la règle de 3 de Martin Fowler dans Refactoring.
Merci pour tes éclaircissements. Dans un programme, les besoins d'un utilisateur peuvent évoluer. La séparation du code en fonction de ses acteurs permet de réaliser des ajouts de fonctionnalités sans créer de désordre dans une autre partie du code.
c'est très intéressant et merci pour ce travail. J'avais en effet posté un commentaire pour critiquer la difficulté de mettre en pratique les principes à partir de la précédente vidéo. Cette série de vidéo s'annonce de salubrité publique pour les développeurs
L'avis de ThePrimeagen dans sa vidéo est aussi pertinent, à savoir que l'abstraction c'est bien en principe mais il ne faut pas forcément appliquer tous les principes SOLID systématiquement, on peut très bien s'abstenir du SRP par exemple dans un projet de petite envergure dont on sait très bien à l'avance qu'il n'aura pas beaucoup de stakeholders. La maîtrise d'un principe c'est aussi savoir quand il faut s'en abstenir.
Oui 100% d'accord. À dégainer quand cela crée de la valeur à court ou moyen terme. Le but n'est pas d'appliquer les principes SOLID, c'est de déployer un logiciel fiable en minimisant les coûts pour le client.
Analyse très intéressante ! Cette idée de raccrocher aux acteurs avait aussi été évoquée par José Paumard côté Java mais ce rappel est le bienvenu ! Merci et bravo ! Tes vidéos sont top, ton travail m'a beaucoup aidé à progresser. Hâte de voir les suivantes : "O.L.I.D" !
J'aimerais bien lire le livre, je vais sans doute essayer de m'y mettre. au vu de ce que tu as présenté, j'aurais plutôt ressenti "l'acteur" comme celui d'un use case, on n'est pas si loin ceci dit. mais du coup, ça nous ramène au fonctionnel. et je reste persuadée que le fonctionnel doit nous guider dans l'organisation du code, que ce soit les packages, les classes et les méthodes. d'un côté on a les données Employee, et de l'autre on a la représentation. Au milieu on va faire notre couche de business avec des classes qui auront un *vrai sens métier*, pour la paie, la ventilation des heures, le décompte des congés, etc. Et on peut avoir des classes utilitaires pour gérer les pourcentages et qui seront utilisées dans nos classes métier, pour éviter de dupliquer du code.
Bonjour, merci pour votre retour. Je trouve intéressant le fait que le fonctionnel doit nous guider. J'ai l'approche du diagnostic chez le médecin, avant de proposer un Doliprane, il faut se renseigner un peu sur le problème, le besoin et les contraintes.
😂 ouais métaphore marrante sauf que quand on achète une voiture elle est deja toute faite alors qu'un projet logiciel c'est pas rare que des gens aient intervenu dessus et l'aient saboté par leur refus à entendre les réalités techniques
Personne n'a jamais été capable de bien définir le terme "changer"... Changer, changer quoi ? C'est comme si je vous disais : "Pour améliorer la qualité de ta vie, tu devrais changer...". Changer ? Changer quoi ? Bah là, y'a plus personne pour te répondre!!! Ça peut peut-être déplaire, mais parfois il est préférable de se fier à son feeling.. Et votre feeling peut très bien gérer cette règle qui es très ambiguë : si vous ressentez le besoin de morceler votre code, alors faites-le, sinon ne le faites pas. votre experience vous permettra d'avoir un meilleur feeling.
Le but de cette vidéo est de définir cette raison de changer via la question : "Qui peut demander des raisons de changer ?". Effectivement, avec de l'expérience, on peut d'instinct se rendre compte que coupler A et B va beaucoup plus pénible que B et C sur tel projet. Mais je ne recommanderai à personne de simplement suivre son "feeling".
Très très intéressant, comme d'habitude ! Je suis totalement d'accord avec le propos : je trouve qu'il y a toujours un souci de compréhension des termes, quasiment des soucis de français en fait. Quand j'entends 'une seule responsabilité', j'ai toujours plusieurs interprétation possibles.
Hello, merci pour votre retour. Vous avez tout à fait raison. Je pense qu'une partie du problème à résoudre est comment rendre des principes de code avancés beaucoup plus accessible et agréable à apprendre. Il y a du "chamanisme" mal placé dans notre industrie à mon avis.
Hello, oui je vous recommande de le tester par vous-même et voir ce que cela donne. Par contre, si vous travaillez seul sur un projet, ce sera compliqué de se rendre compte ce qu'implique ce principe. C'est plus simple en équipe avec des demandes qui viennent de partout, et voir comment son code "encaisse" tout ça. 👍
Très cool comme discussion. Je te propose de remplacer l'expression "raison de changer" par entropie, car ce terme définit également un potentiel de chaos (et donc de la maintenance à prévoir), en plus des raisons de changement. Qu'en penses tu ?
Hello, merci pour ta suggestion. Par contre, pas sûr que le terme "entropie" parle à grand monde. Je ne sais pas si cela améliorera la situation. Mais si tu as d'autres propositions n'hésite pas, nous avons un problème de nommage dans cette industrie !
Mouais perso j en ai un peu marre du monde du dev ... J ai l impression que les devs ne sont que des fashion victimes, des perroquets... Ils passent d une mode a une autre, d une certitude a une autre... Ajouter a ca souvent bcp d arrogance, de certitudes, de prosélytisme. J aime bien le dev mais je n aime pas trop les développeurs.
Je pense que le problème c'est plutôt qu'à chaque fois qu'une personne moins bête que les autres essaie tant bien que mal d'exprimer une intuition qu'il a de façon univoque, tu as une marrée humaine de développeurs plus ou moins doués qui en parlent mal et c'est la déformation de l'idée d'origine qui se propage. C'est exactement ce qui s'est passé avec Kent Beck concernant les tests automatisés et l'extreme programming. Il a lui-même expliqué qu'en entendant certaines questions ou commentaires lors de conférences il avait limite les larmes aux yeux tellement on avait travesti ce qu'il avait mis tant d'efforts à exprimer clairement et succinctement dans deux petits livres très faciles à lire. Par contre je suis d'accord avec ta perception de la communauté des développeurs. J'aimerais voir plus d'humilité, de curiosité et d'esprit critique.
C'est bien, ça veut dire que tu es arrivé au stade d'après: Arrêter la branlette intellectuelle et la perte de temps qu'elle entraîne et simplement focus sur livrer du code suffisant pour les besoins et rien de plus.
@@Trusty22 Entièrement d'accord ! Faut arrêter de se prendre la tête avec toutes ces conneries et faire son boulot correctement point barre. Après ça dépend du projet, des collègues, de la boite, de la sensibilité du projet, etc...
Pour moi le plus important c’est un code testable et tested et le ci cd si le truc est assez gros et rentable pour avoir une team de dev dessus. Et mettre des outils d’analyses static et après en prod pour analyser la performance et l’optimiser ça c’est le Pareto de ce qui est important le reste je m’en fiche ça rapporte pas de thune ni à moi si à la boîte.
J'ai écouté toute la vidéo (bon ok jusque 14:16 j'avoue), et je me demande si la confusion que tu exposes ne vient pas juste des mots utilisés ? Perso, je trouve que les 3 définitions données sont bonnes et tendent (justement) vers la même chose, mais ne sont pas exprimer de la même manière (dans le sens où ce sont des définitions propres à ce que l'auteur avait en tête au moment de la formuler). Typiquement, on est d'accord que la définition de base du SRP est imbuvable, mais l'utilisation des mots "classe" et "fonction" (méthode) ne devrait-elle pas être considérée au sens stricte de la POO ? L'exemple que j'aime bien donner pour le SRP, c'est un projet Calculatrice en Java, qui dans un premier temps serait utilisable dans la console uniquement (sans interface graphique). Il serait séparé en 3 fichiers : - 1 Classe "Application", qui gère les interactions utilisateurs, lui permettant d'utiliser l'application et notamment d'accéder au moteur de la calculatrice pour faire ses calculs. - 1 Classe "Calculatrice", qui gère les calculs en tous genres, et qui sera donc "consommé" par la classe "Application". - 1 Énumération "FonctionCalculatrice", qui "structure" les choix que peuvent faire les utilisateurs, avec notamment "/" pour la division, "*" pour la multiplication, etc. Dans l'exemple ci-dessus, on serait tenté de ce dire qu'on met le code de la Classe "Calculatrice" dans l'Énumération "FonctionCalculatrice" directement, après tout, ce ne sont que quelques méthodes, qu'elles soient dans un fichier ou un autre ça revient au même. Mais justement, ça violerait le SRP. Chaque fichier (ou classe) possède sa propre responsabilité: - L'Application pour faire interface avec l'utilisateur, le guider, lui proposer d'arrêter le programme, etc. - La Calculatrice pour faire le moteur de calcul à proprement parler (ce n'est pas ce qu'on "utilise" directement, ce n'est qu'un module de l'application, qui gère les calculs). - L'Énumération pour structurer, avec un rôle de "validateur" parmi une liste de choix définis possibles (car une calculatrice standard ne peut rien faire de plus que ce pour quoi elle a été codée). Avec cette exemple, le SRP est respecté (si tu n'es pas d'accord, je suis intéressé d'avoir ton pov), et pour "preuve", même si on décide de faire une énorme (tout est relatif) mise à jour pour cette calculatrice en intégrant la notion d'interface graphique, ou en proposant même différents types de calculatrices (scientifiques, etc.) avec différentes fonctionnalités disponibles selon l'affichage : ça fonctionne nickel, c'est extensible et maintenable, tout ce qu'on aime. (J'avoue j'ai abusé sur la taille du commentaire 😂 vu le peu de vidéo avancée en français, je fais l'effort)
Salut, merci pour ton long commentaire. Au contraire, c'est le genre de commentaire que j'apprécie : une audience de développeurs compétents regardent les vidéos, on n'est pas sur une audience TikTok. 👍 Concernant ta proposition, cela me paraît très bien. Surtout que comme tu le précises, c'est "maintenable et extensible". Je rajouterai même "testable". Et on est bon, car on retombe sur nos pattes, les 3 piliers du code Senior : maintenabilité, flexibilité et testabilité. On est bon ! Bon code à toi et à bientôt, Simon.
Merci pour les vidéos, elle sont super! Par contre ici le discours me dérange un peu. Séparer les features en fonction des acteurs je trouve ça simpliste ça induit qu'il n'y a pas un fort couplage entre les besoins utilisateurs, ce qui est pourtant souvent le cas (ex : admin et user :) ). Personnellement je suis pas d'accord avec cette définition.
Dans votre exemple "admin" et "user", vous avez bien deux raisons de changer. On peut vous demander de faire évoluer le code relatif à l'administrateur et à l'utilisateur pour deux raisons différentes. Donc même si le code se "ressemble beaucoup", c'est typiquement le genre de code où un couplage gênant peut être mis en place.
Pour moi le srp s’applique de façon différente en fonction du niveau, j’ai tendance à appliquer ce type d’approche du niveau global jusqu’au plus fin. La notion d’acteur c’est un use case donc une api la requête api n’a qu’une responsabilité servir le use case. Chaque class nécessaire à l’api n’a qu’une responsabilité le contrôleur reçoit et répond, le repository reçoit et sauve les données, le service ou le domaine gère les règles. On va pas faire 10 repository car il y a dix utilisateurs findbyid c’est le même. Par contre plusieurs controller ça a du sens. Et côté régle métier une classe une règle. Une fonction un calcul. La on revient au principe de base du srp. Si je résume mon point de vue je ne fais pas du srp mais du sop single objective principe. Un objectif et seul. Objectif d’un use case, technique, règle, calcul
Hello, j’aborde en fin de vidéo qu’il y aurait effectivement plusieurs niveau de SRP. (Separation of concern, common closure principle..) effectivement plusieurs repository a beaucoup moins de sens que pour dés contrôleurs ou des entités métiers. Le terme d’objectif est différent du terme de responsabilité initial ?
Super intérressant ! Pour un junior comme moi, c'est encore un peu obscure cette "notion de changer". Quand on dit changer, c'est une refactorisation de la classe ? C'est un changement d'état de l'instance ou d'une de ses propriété ? Désolé pour ce manque de recul de ma part. J'aurai bien aimé avoir un contre exemple de ce qu'il aurait fallu faire avec la classe "employee" présentée à la 8,51 minute.
Je pense qu'il s'agit de la notion de maintenance du code, souvent en entreprise tu vas surtout maintenir du code existant, si le précédent développeur a travaillé comme un cochon alors tu vas avoir du mal à implémenter les nouvelles fonctionnalités demandées par la MOA, et toi aussi tu risques d'aggraver la chose en codant mal, d'où ces auteurs qui sortent des bouquins avec des propositions de règles, de principes pour bien coder. Il faut bien sûr rester critique et ne pas suivre aveuglément toutes ces règles, ce sont juste des principes, pas des obligations, car il ne faut pas perdre de vue qu'en entreprise on veut surtout un code qui marche, simple, facile à comprendre (le principe KISS, on ne veut pas d'usine à gaz) et que le délai de livraison soit respecté.
Ton client peut te demander d'implémenter le comportement X au mois d'avril et d'implémenter le comportement Y au mois de juin, ce qui te force à écrire du code deux fois. C'est de ça qu'on parle. Il faut faire 2 changements, mais est-ce que pour implémenter ces changements tu dois aller dans la même partie de ta codebase ou pas ? Le SRP c'est la fusion de la notion de séparation des préoccupations et de la notion de couplage et de cohésion : on regroupe dans le code les choses qui ont tendance à changer en même temps pour les mêmes raisons, et on sépare les choses qui ont tendance à changer à des moments différents pour des raisons différentes. Si tu appliques ce principe, ce qui va naturellement se passer c'est que certaines parties de ta codebase vont se stabiliser : elles changeront très peu souvent, et donc il y aura très peu de régressions accidentelles les concernant, et d'autres parties changeront toujours pour les mêmes raisons, donc elles seront faciles à retrouver et deux personnes qui travaillent sur la même codebase et qui doivent faire des choses différentes ne toucheront pas au même code et auront moins de chances de se tirer dans les pattes. En appliquant ce principe, l'ampleur de chaque modification est plus réduite. Et l'intuition derrière ça, l'expérience de vieux routard, c'est que souvent les choses changent parce qu'une personne avec un certain rôle dans l'entreprise a besoin qu'elles changent (une même personne peut avoir plusieurs casquettes, donc on s'intéresse ici à la casquette). Par exemple, l'UX designer dans certains projets va changer des choses tous les jeudis, et dans d'autres projets quasiment jamais. En fonction du projet, ce ne sont pas les mêmes parties du code qui sont stables ou instables, mais dans tous les cas si elles sont bien séparées par responsabilité, tu t'y retrouveras.
Hey, En effet, quand on parle de raison de changer, on parle du code en lui même. Pour en revenir à l'exemple de l'employé, on peut identifier au moins 2 raisons de changer: - Un changement contractuel qui amènerait soit à une augmentation de salaire ou changement des heures travaillées, ce qui impliquerait de changer au moins une des deux méthodes - Un changement dans la base de données qui entraînerait un changement de code Par conséquent, cela fait au moins deux raisons de changer avec des acteurs différents, ce qui est à éviter selon le SRP ! On pourrait découper avec une classe qui s'occupe de gérer la partie du CFO de l'employé, et une autre de la partie COO. Et dans l'avenir, on pourrait également re découper ces parties si jamais le besoin s'en fait sentir
Merci beaucoup. Ça va faire genre 4 ou 5 playlist ou vidéos + article que je me tape sur les principes SOLID et à chaque fois c'est tjrs le SRP qui me fait défaut. Je trouve que la définition du changement fonction des responsabilités était un peu trop abstrait pour mon QI. Mais grâce à cette définition un peu plus concrète du groupage en fonction des acteurs, ça me parait un peu plus intuitif que l'ancienne définition. Mais à ce qu'il parait, il y aurait une autre Acronyme/méthode qui serait mieux que le SOLID (paroles de ArjanCode, youtubeur) et certes plus abstrait mais qui couvre plus les besoins d'une bonne codebase en plus du clean code, ce serait la méthode GRASP. Votre avis ? Sinon, merci beaucoup pour l'atelier gratuit. En ce moment je fais un stage en entreprise qui devrait ne pas excéder Juin mais je ferais un tour sur votre atelier dès que j'aurais le temps. Je souhaite en effet me spécialiser dans le JavaScript ; j'éprouve un petit attachement à ce langage pcq c'est le premier avec lequel que j'ai appris à coder et que donc je me sens plus à l'aise de tryhard dessus que sur d'autres langages.
Bonjour, merci pour votre retour. Avez-vous un article d'introduction à la méthode GRASP pour la production de code en entreprise ? Je n'ai rien trouvé de très fructueux après une courte recherche Google. L'atelier proposé est disponible jusqu'à fin juin 2024, vous pouvez vous inscrire pour garder l'accès à l'atelier au-delà de cette date. Après, il ne sera plus disponible. J'espère que cela pourra vous aider à vous spécialiser en JavaScript avec des bases solides. Bon tryhard JS ! 💪
Le schéma de la fin semble très honnetement etre une évidence pour tout développeur qui aurait suivi un cursus solide en informatique, coté back end ca fait 20 ans que les applications sont concus comme ça avec plus ou moins de réussite, de nos jours les framework moderne forcent presque la bonne séparation, du moins sur sur les technos serieuse de grandes entreprise comme JEE, sur les petits projets en python c'est souvent n'importe quoi avec des classes fourre tout je l'ai vu tellement de fois. Pour le front c'est un peu plus récent il a fallut attendre Angular 2 et React j'ai l'impression pour que quelqu'un se dise que ça serait bien d'appliquer des bonnes pratiques de developpement au front, sans offense 😅
Assez d'accord, la plupart des frameworks te poussent dans cette direction. Après, sauf incompréhension de ma part, la vidéo met fortement l'accent sur un découpage par Classe. Ca sous-entendrait dans son exemple... 9 classes... Clairement, je ferai jamais ça sur une app standard.
@@sparqueur Tu me met le doute. Dans ce cas je suis pas d'accord avec le schema et l'idée derrière, si le schéma exprime la necessité de faire 9 classes pour ca on rentre vraiment dans l'exemple d'over engineering. @Simon pourra peut etre nous eclairer si il lis ce com car je suis pas sur d'avoir compris la vidéo alors. Pour moi ce schéma doit aboutir sur un controlleur ( la couche REST ) genre UserController, un service UserService qui contiendras getUser(), deleteUser(), createUser(). La couche Controller renvoie des objets "vue" ( DTO en Java, data transfer object ), et une Dao UserDao qui manipuler les objects de la base et qui hérite surement d'une GenericDao ( en java des Entity, mais le principe est le même avec n'importe quel ORM ), et bien sur notre classe UserEntity basé sur la techno ORM de votre langage et mappé sur la base de données. J'ajouterai encore une couche de mapping "UserMapper" qui convertira les objets entre les differentes couches Si vraiment on parle de 9 classes, j'ai jamais vu ça, et je veux pas particulierement intervenir dans un code ou ca serait fait comme ça ... Un bon code t'es capable de mettre un point d'arret dans l'entrée (l API rest souvent ) et de remonté facilement tout le code et avec 3+ classes on le fera aussi bien que 9+. En plus y aurait de forte chance que les differentes fonctions liés aux utilisateurs dependent de même fonctions, par exemple "updateUser" peut surement etre factorisé a 80% avec "createUser" et si la fonction en commun est dans le même service (meme classe) c'est quand même beaucoup plus simple sinon ça voudrait dire encore des classes tiers en plus des 9 classes ou de la répétition de code, et en plus ça risque de poser plein de problemes d'inclusion a un moment qui vont encore necessité des classes tiers pour éviter toute cyclicité. Pour moi découpler encore c'est pas bon, y a plein d autres choses a faire bien plus importante comme une gestion propre des Exceptions, interceptés au même endroit et qui renvoient les erreurs/succes HTTP appropriés. Une gestion propres des checks metiers, des accès aux ressources etcs ... Ou alors c'est vraiment une spécificité React ou on veut associé chaque vue a son unique composant mais ça doit pas etre une généralité selon moi en tout cas.
Hello, je tout à fait d’accord. L’écosystème backend a l’air beaucoup plus mature sur tout un tas de sujet, par rapport au front end. Comme vous dites c’est plus récent, donc cette « immaturité » me paraît logique. Bon code et si vous avez des conseils de back eux, je suis preneur !
Hello, oui c’est une représentation mentale plus qu’autre chose. Par exemple, c’est probablement le même acteur qui vous demandera de devoir intervenir sur getUser, createUser, updateUser et deleteUser. Donc 1 classe. Est-ce que ça fait sens pour vous ?
L'énoncé d'un principe doit être testable. Il faut pouvoir formuler un arbre de décision qui dirait si le principe est respecté ou pas. Avec des questions claires. Et ta définition ne le respecte pas cette règle. Ton premier énoncé "une seule raison de changer" le faisait. Il suffisait de répondre à la question "est-ce qu'une ligne de ton code est exécutée par plus d'un test end-to-end ?" pour dire si le SRP est respecté. Et on comprend tout de suite pourquoi, formulé comme ça, c'est un mauvais principe de codage : ça interdit la factorisation, multiplie les copier-coller etc. Mais il a le mérite d'être compréhensible et ré-applicable dans n'importe quel projet. Alors que ta définition finale est trop floue, et tu ne réponds pas vraiment à la question si on parle d'une SR par classe ou par méthode ou autre. Je ne suis pas sûr de bien comprendre. Est-ce que tu veux dire que : Pour tout élément de code, je demande : 1. Qu'est-ce qui y fait appel ? 2. À quoi il touche ? Si les deux éléments répondent pareillement l'un que l'autre aux deux questions, ils ont le droit d'être ensemble, sinon, on les sépare. Ta vidéo sur TypeScript était beaucoup plus compréhensible ;)
Hello, merci pour votre retour. Je pense que la vidéo sur Typescript comprenait plus d’exemple de code et était plus concrète. Concernant la définition finale, justement le sujet est que le SRP dépend de la structure organisationnelle dans laquelle vous opérez, et moins d’une réalité technique sur le votre en soi. Mais j’aime bien l’idée de pouvoir « tester » si on respecte ou non un principe. Je retiens le principe pour les prochaines vidéos sur les principes Solid, merci !👍
Ton contenue est très qualitatif mais la forme n'est pas assez travaillée. Je te conseille d'améliorer tes minatures pour qu'elles soient beaucoup plus descriptives. et ce serait bien aussi d'améliorer ton décor avec un bon éclairage pour que cela soit plus professionnel. Idéalement, aussi avoir un rythme de parole un peu plus élevée car on est sur RU-vid et les gens ils aiment quand ça va vite.
Le débit de parole est très bien. Un débit de paroles rapide est adapté pour les vidéos débiles qui ne nécessitent aucune réflexion. Ce n'est pas le cas ici. Un débit de parole lent pour avoir le temps de bien capter ce qui est dit sans faire des pauses toutes les 20 secondes c'est très bien.
Hello, merci pour votre retour, cela me rassure. La dernière chose que j'ai envie de faire est d'installer des néons violets dans mon salon et de faire la promotion de Nord VPN. 🔥
Je ne partage pas exactement ton point de vue. Pour moi le SRP sert uniquement à decoupler les raisons de changer de nature technique. Ce qui fait qu'on ne met pas de logique métier dans un mapper ou d'accès en base dans un service, ce genre de choses... Ce dont tu parles, plus proche du DDD et de la clean archi, considère le découpage et la duplication des fonctions selon les acteurs du système, est de nature fonctionnelle, et c'est un concept différent du SRA, puisque il peut par exemple s'agir de dupliquer plutot que factoriser des fonctions qui peuvent diverger du fait meme qu'elles sont consommées par différents acteurs. bref, c'est plus un concept à part entière selon ma conception, car, certes, c'est intéressant d'intégrer à la responsabilité les acteurs qui la consomme. Mais cela complexifie aussi cette notion, et je préfère séparer les responsabilités, de nature technique ou fonctionnelle, des business boundaries, qui définissent les ségrégations de nature métier.
Tu viens de me mettre une claque très intéressant Je suis un dev junior Web perdue dans ce qu'il faut apprendre de fois et la voir aussi vulgariser ce principe SoliD que j'ai lit congratulation bro t'es vraiment trop fort
Pour aller plus loin, si ça peut intéresser, ça vaut le coup d'aller regarder l'opposition entre l'OOP et un paradigme plus récent comme le DoD (Data Oriented Design) en ce qui concerne la SRP. Ce paradigme est pas mal utilisé notamment dans le jeu vidéo, avec une version d'implémentation qui est l'ECS. Même si ce paradigme est vu comme un moyen de gagner en perf (moins de cache misses...etc), c'est surtout une vision d'archi complètement différente sur la SRP et sur le couplage entre données/opérations. Sans rentrer dans le détails, je vais essayer par un exemple de montrer ce qui me semble avec mes connaissances actuelles une limite de la vision SRP discutée dans la vidéo. Si on part sur le principe qu'on sépare les responsabilités par acteur, à un moment, à force de demandes, on va se retrouver avec disons une classe x qui a (possède ou référence/accède) un ensemble de données créant un couplage hyper fort entre les opérations effectuées par ses méthodes et les données présentes (même si elles ne sont pas possédées par la classe, le simple fait de visualiser ces données dans un certain domaine - représentation - suffit). A ce moment-là, même si on a fait de la composition, de la DI...etc, on va se retrouver avec des données qui sont inutiles ou couplées dans x opérations et des api dont les contrats vont refléter ces données. Le drame arrivera quand un acteur/client va nous demander quelque chose qui forcera à repenser ces contrats publics haut niveau des api et là, les couplages que l'on a créé entre données et entre visualisation des données / opérations vont obligés à faire des refacto et d'exploser d'autres principes SOLID. Aussi intelligemment que l'on essaie de penser l'archi, il est difficile de garder des api publiques haut niveau qui ne changent pas quand on organise les opérations et données en mode OOP. En c++ (qui est mon langage de prédilection), on le voit bien avec certaines free functions qui ont été pensées sans domaine et en mode opérations séparées des données avec la librairie stl algorithm (qui travaille de manière générique sur les containers avec un range ou start iterator + sentinel et des lambda d'opérations) vs des choses plus anciennes comme toutes les fonctions membres dans std::string. Je ne sais pas si c'était intéressant mais si c'est le cas, tant mieux :)
Hello, est-ce que tu as un article d'introduction sur le sujet ? De mon côté, DoD signifie "Definition Of Done".. pas "Data Oriented Design". Ah le nommage, c'est quelque chose ! ^^
@@codeursenior @ApprendreSansNecessite Désolé, j'ai pas réussi à expliquer clairement mon message ! Le gros problème de ce paradigme est - de ma petite expérience de programmeur moteur dans le jeu vidéo - est qu'il a été pensé par et pour cette industrie à la base, qui est très centrée sur le langage c++. Je ne suis pas convaincu qu'il soit des plus intéressants dans sa totalité dans d'autres situations, d'autant plus quand il y déjà une visualisation des données dans un modèle de DB relationnelle (au-cas-où, je vous partage la ressource que j'ai trouvé la plus intéressante sur le sujet, à savoir le livre "Data-Oriented Design' de Richard Fabian). Sans même aller aussi loin que tout ce qu'implique ce paradigme, j'ai retrouvé une phrase du livre qui peut être un point de départ de réflexion et que je trouve intéressante pour parler de SRP avec la Programmation Orientée Objet. J'espère qu'elle arrivera mieux à décrire le problème que je n'ai réussi à le faire😅 : "I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions-all the data comes in its input arguments and everything goes out and leaves no state behind-it's incredibly reusable." (Peter Seibel, Coders at Work: Reflections on the Craft of Programming)
@@hugotraverson J'aime bien l'analogie avec la banane. Ok pour les avantages des fonctions pures versus les objets. Comme il n'y pas d'état à gérer, c'est tout de suite plus simple. Mais je ne suis pas certains que SRP ne s'applique pas aux objets pour autant. J'ai ajouté le livre dans mon panier tout de même !
Merci beaucoup pour la suggestion de lecture. J'étais intrigué parce qu'il me semblait avoir déjà entendu parler de l'Entity Component System dans le contexte du jeu vidéo justement, mais je n'ai pas pris le temps d'investiguer et les rapprochements que tu fais avec la programmation fonctionnelle me parlent. Oui l'analogie de la banane est connue. Après ça cible plutôt les hiérarchies de classes basées sur l'héritage et comportant fatalement des classes dérivées dégénérées qui héritent de choses dont elles n'ont pas besoin. J'ai toujours trouvé le système de classes de types ou de traits à la Haskell ou Rust plus naturels et entendre parler de transparence référentielle dans un paradigme adapté au jeu vidéo me plaît autant que ça me surprend. Un reproche que je fais à l'OOP c'est que les types et les noms qui font surface dans le code sont une représentation de la solution et couplent ces noms et ces types à des comportements, des changements d'état, des facteurs externes, des contraintes d'architecture, etc. tandis qu'en fonctionnel on modélise d'un côté les données du problème et de l'autre la solution, et tout ce qui est impur est injecté comme une dépendance, ce qui le rend visible dans le code et dans le système de type, et on n'a pas de soucis du style "un carré n'est pas un rectangle" parce que, n'ayant pas d'états mutables, les noms qu'on donne aux choses ne peuvent pas mentir. Tout se simplifie. Ton commentaire me rappelle aussi quelques intuitions que j'ai trouvé en m'intéressant au domain driven design et aux architectures event-driven, CQRS, etc: on fait souvent des erreurs quand on amalgame données et comportements. C'est en fonction des comportements qu'il est souvent plus sain de positionner ses frontières architecturales mais l'OOP nous donne cette habitude de coller des comportements à des entités qui ont du sens et du coup à structurer le code en fonction de ces entités. Enfin bref, je suis deux fois plus motivé qu'avant à creuser.
en fait, la "responsabilité unique" dont il était question était celle du donneur d'ordre et non celle de la classe. Mais là, il me semble que l'on court-circuite une notion essentielle du point de vue de l'ingénierie système : l'exigence- qui est allouée à la classe. Certes on le fait pour gagner en réactivité, mais ce court-circuit fait la part un peu trop belle au donneur d'ordre, et le déresponsabilise , avec l'aléa moral assorti ("vous m'avez mal compris")... L'ingénierie système, c'est ce qui sert à envoyer des fusées dans l'espace sans se planter : ils ont comme qui dirait un peu réfléchi au sujet.
Cela fait depuis peu que je suis abonné à ta chaine et j'adore ce que tu fait :) J'ai suivi ton workshop que tu recommande dans ta vidéo, ce qui m'a permet de faire une piqure de rappel et me rappeler à quel point j'aime ce langage. Si je peu me permettre de revenir sur la partie "Le cœur de JavaScript" de ton workshop, dans la partie "les fonctions en JavaScript"... j'ai été surpris de l'effet de l'invocation de la fonction sum. Logiquement, une fonction déclarée (assignée à une variable) est invocable dans tous ce qui suit sa déclaration (y compris les scope locaux). En testant sur runjs, j'ai eu le même effet que toi mais en revanche si je passe par un console.log, la fonction est bien invoquée. Je pense si je ne m'abuse pas que le problème est lié au runjs. En dehors de ça, j'adorai qu'un jour tu puisse interviewer John papa :)
Salut, j'ai tourné ce workshop, il y a quelques années et si c'était à refaire, je ne repasserais pas par RunJS mais directement par du code exécuté par le navigateur. On serait beaucoup plus prêt du "vrai" environnement. Pour John Papa, ce serait le end game mais on y croit :) Bon code, Simon.
