Transformez votre Code avec le Principe de Responsabilité Unique (Guide avancé)

je vous recommande fortement de regarder des vidéos de personnes qui ne sont pas d'accord avec vous et surtout dans le code parce que ce que nous allons voir dans cette vidéo m'a particulièrement mis une claqueque sur ce que je croyais savoir cette vidéo fait partie de la playlist dédiée au principes solid de code les principes de code solide sont très importants si vous souhaitez développer du code de qualité pour l'entreprise puisqu'ils vont vous permettre de renforcer les trois piliers du code professionnel qui sont la maintenabilité c'est-à-dire diminuer le coût opérationn de votre code base combien de bug votre code crée combien de temps il faut pour monter en compétence sur le code que vous avez produit et cetera deuxième pilier la flexibilité est-ce que le code que vous avez écrit jusque là vous permet d'aller plus vite ou vous ralenti au fur à mesure des développements troisème pilier la testabilité est-ce que le code que vous avez écrit pourrait être couvert par des tests unitaires ou pas et en appliquant les cinq principes solide et bien généralement vous vous rapprochez de ces trois piliers quasiment mécaniquement et ce que nous allons voir dans cette vidéo et bien c'est le premier principe solide le S de solide qui est le principe SRP le principe de single responsability et nous allons vraiment passer une vidéo entière à creuser ce principe et vous allez voir que contrairement à ce qu'on peut penser on se dirait qu'on peut passer 20 secondes sur ce principe et passer à la suite et bien pas du tout on va s'attarder pour creuser ce principe jusqu'à le maîtriser totalement et on attaque tout de suite sur ma première théorie autour du principe de single responsability et si vous vous renseignez sur sur internet à propos de ce principe et bien vous allez retrouver tout un tas de vidéos qui disent des choses similaires mais assez élémentair c'est-à-dire que dès qu'une classe ferait par exemple trois méthodes et bien il faudrait la découper en trois classes différentses et on retrouve cette idée un peu partout je l'ai même vu sur Open classroom qui est le site sur lequel j'ai appris à coder il y a maintenant plusieurs années où on retrouve le message suivante la bonne nouvelle de ce principe c'est qu'il est très simple à mettre en place il suffit de diviser vos classes en de multiples classe ayant chacune une et une seule responsabilité pourtant de mon expérience ce principe n'est pas du tout aussi simple que ça à mettre en place et même au contraire si on commence à l'appliquer un peu bêtement sans vraiment savoir ce qu'on fait et bien on se retrouve avec du code extrêmement couplé puisqu'on a tellement découper qu'on est obligé de refaire des paquets un petit peu au-dessus et ça devient vite du code spaghetti alors que c'est ce qu'on voulait éviter au départ donc avec une application aussi sommaire du SRP généralement on n'arrive pas à grand-chose donc moi ce que j'avais fait à l'époque c'est repartir de la définition du SRP un petit peu officiel qui avait été posé par Robert C Martin au début des années 90 la définition est la suivante une classe doit avoir une et une seule raison de changer donc une classe doit avoir uniquement une responsabilité et en lisant cette définition et bien on voit que avant de poser la question de la responsabilité de la classe en question que vous êtes en train de développer et bien se pose la question de la raison de changer et c'est quelque chose de très important c'est que on va créer du code qui va encaisser des raisons de changer et si un code a deux raisons de changer différents et bien à ce moment-là on va vouloir le séparer mais si on a un fichier de 500 lignes par exemple qui n'a qu'une seule raison de changer et bien il n'y a pas spécialement de raison de découper on va se retrouver avec beaucoup de codes qu'on devra recoupler par la suite donc autant manipuler une seule entité et dans ma vidéo initiale sur les principes solides où je présente les cinq principes d'un coup sans rentrer plus que ça dans les détails et bien on voit l'exemple suivant on crée par exemple un objet qui représente une une évolution entre deux pourcentages par exemple entre 50 et 75 on veut modéliser l'évolution plus 25 % mais ce qu'on fait ensuite ici est un peu dangereux puisqu'on va rajouter deux méthodes à cet objet qui est utilisé sur deux pages différentes on va déduire un label à afficher par exemple pour dire que l'évolution est très forte moyenne ou négative cette information qui est liée à une page spécifique et bien on va venir la mettre dans cet objet percentage evolution et puis on va venir ajouter une deuxième méthode qui est liée à une autre page qui elle a besoin de calculer des arrondis autour de l'évolution entre deux pourcentages donc au lieu d'afficher + 0 33333 on va par exemple afficher plus 30 % sur telle page le problème ici c'est que ces deux pages peuvent avoir deux raisons complètement différentes de changer le marketing peut en effet vouloir changer le label sans changer la stratégie autour des arrondis et inversement donc il est très bizarre entre guillemets de venir coupler la logique d'affichage de deux pages à un objet qui devrait avoir qu'une seule responsabilité qui est le percentage evolution on veut le calcul algorithmique bas niveau dans cette classe sans dépendre de sa représentation sur différentes pages ainsi on a découpé le logiciel en fonction de ses raisons de changer potentiel qui est une approche déjà plus intelligente que de simplement découper parce que il faudrait que chaque classe ait une méthode en exagérer et honnêtement c'est ma définition initiale et j'en étais très satisfait et j'adorais raconter l'histoire que le but c'est pas de donner forcément une responsabilité tant qu'on n' pas clarifié la raison de changer mais cette théorie initiale est tombée à l'eau lorsque je suis tombé sur la vidéo qu'on va voir tout de suite et qui m'a met une claque parce que je me suis demandé est-ce que cette définition est réellement scientifique ou c'est quelque chose de complètement subjectif et on passe à la théorie numéro 2 qui est la contre-théorie du youtubeur américain prime agent en tombant sur la vignette suivante et bien j'étais obligé d'être interpellé puisque je préparais à ce moment-là la playlist complète sur les principes solides et donc quand je vois quelqu'un qui dit qu'il ne faut pas utiliser le SRP j'ai été quasiment obligé de regarder cette vidéo surtout que la personne en question est un développeur qui est très talentueux et qui est un ex ingénieur de chez Netflix donc c'est pas juste une vidéo pour faire le buzz et cetera il vient apporter une réelle réflexion derrière et dans cette vidéo et bien ce youtubeur américain réagit à un article qui s'intitule j'ai vraiment mal compris le single responsibility principle et je vous ai mis le lien en description de cet article et cet article présente tout simplement que la définition du SRP sur laquelle je me basais est bien daté de il y a a plus de 25 ans et qu'elle avait largement été remis en cause critiqué challengé pour que même l'auteur Robert C Martin du principe initial et bien soit revenu sur sa définition plusieurs fois et j'ai donc été obligé de challenger la version du SRP que je croyais être la vérité et que j'étais toujours en train à expliquer autour de moi et j'ai trouvé pas moins de trois définitions différentes du SRP qui avait l'air de cohabiter complètement la première qui ressemble beaucoup à la version initiale est que une classe ou une fonction ne doit avoir qu'une seule raison de changer ici il y a pas de notion de responsabilité il y a la notion de raison de changer il y a une autre définition qui vient pas de Robert C Martin mais qui vient de Michael fer dans son livre où il explique comment travailler avec du code Legacy et ici on retrouve que chaque classe doit avoir une seule responsabilité elle doit avoir un seul objectif dans le système et il doit y avoir qu'une seule raison de la changer et enfin on retrouve une autre définition alternative de Robert C Martin qui est qu'il faudrait regrouper les éléments qui doivent changer pour les mêmes raisons et séparer les choses qui doivent changer pour différents raison donc ces trois définitions sont assez confusantes puisque il y a des fois on parle d'éléments de choses des fois on parle de fonction et des fois on parle de classe de manière très précise donc on sait pas réellement ce qu'on doit manipuler et puis on parle aussi des fois de responsabilité mais pas dans tous les cas en tout cas il y a un dénominateur commun très intéressant dans toutes ces définitions c'est la fameuse raison de changer tout le monde est d'accord que le code doit être construit en fonction des raisons de changer que vous allez devoir encaisser avec votre code base et je trouve ce concept très intéressant en effet si du code même Legacy n'a aucune raison de changer et bien finalement ça n'est pas si grave le problème c'est comment rendre ce principe un peu scientifique académique puisque pour l'instant on a l'impression que on a juste une guerre d'opinion qui est en place et on sait pas vraiment sur quoi se baser et donc on passe tout de suite à la théorie numéro 3 qui est la théorie de Robert S Martin à la rescousse pour le moment nous avons trois définitions du SRP qui cohabit et nous ne savons absolument pas sur laquelle nous baser par contre nous savons que il y a un dénominateur commun très intéressant c'est la raison de changer et tant que nous n'arrivons pas à nous mettre d'accord sur qu'est-ce qu'une raison de changer dans le développement logiciel et bien nous n'allons pas pouvoir avancer sur une définition sur laquelle tout le monde pourrait se mettre d'accord concernant le SRP et en fait c'est en relisant le livre clean architecture qui est sorti en 2017 c'est-à-dire bien plus tard que la définition initiale de 1990 que je me suis rendu compte qu'il y avait en fait toutes les réponses dedans et j'étais passé à côté lamentablement dans ce livre clean architecture et bien Robert C Martin présente les design principes solides qui ont une partie complète dédiée dans le livre et dans le chapitre sur le SRP et bien il explique qu'il y a bien trois définitions qui cohabitent mais qui se sont juste àosé dans le temps c'est-à-dire qu'il y a des versions entre guillemets périmé du SRP et des versions plus à jour et il présente donc la version la plus à jour du SRP qui est pas celle que j'avais et pour prendre un exemple regardez la classe suivante employé on retrouve trois méthodes associées à cette classe une méthode pour calculer la paye d'un employé une méthode des changements qui ont été faits sur cette classe en base de données et enfin une méthode pour reporter tout toutes les heures de travail qu'à effectué le salarié si on réfléchit ici non pas en terme de responsabilité ou d'autres choses mais en terme de raison de changer sur ce projet et bien on va tomber sur quelque chose de très intéressant en effet la première méthode qui permet de calculer combien les employés sont payés et bien fait référence à un acteur très particulier dans une entreprise qui va être le CFO c'estàd celui qui s'occupe des finances dans l'entreprise ça va être sa responsabilité de savoir combien doivent être payés les gens par contre le fait de sauvegarder un employé dans la base de données va pas être de sa responsabilité puisque ça va être de la responsabilité d'une autre personne généralement le ctoo qui va déterminer où sont persisté les données de l'entreprise c'està-dire le directeur technique dans une entreprise et puis enfin la dernière méthode qui est de reporter les heures de travail et bien ça va être la responsabilité d'un C c'estàdire le directeur opérationnel de l'entreprise ici ce qui est intéressant c'est que la notion de responsabilité est directement couplée à une personne ou un groupe de personne dans une entreprise et c'est là on arrive à notre nouvelle définition du SRP c'est que on veut organiser notre e en fonction des raisons de changer et ces raisons de changer viennent de gens donc ce principe n'a pas de réalité technique objective il a une réalité par rapport aux personnes et aux groupes de personnes qui peuvent exiger des changements sur votre logiciel donc c'est pour ça que ce principe n'a pas de vérité absolue et que c'est si dur de se mettre d'accord dessus puisque ça va dépendre de la structure organisationnelle dans laquelle vous codez qui demandent les requirement et les requirement peuvent venir de partout ils peuvent venir du marketing ils peuventenir ir de contraintte technique par rapport au langage au framort que vous utilisez vous êtes obligé de vous mettre à jour personne vous a demandé votre avis vous pouvez avoir des politique de sécurité globale au niveau de l'entreprise il va falloir adapter votre code par rapport à ça et cetera et cetera et donc notre définition initiale qui est qu'une fonction ou qu'une classe doit avoir une seule responsabilité très dur de savoir ce qu'on doit réellement faire et bien la nouvelle définition devient la suivante vous devez séparer le code qui supporte différents acteurs et ça c'est une elle définition qui me plaît beaucoup puisque ça a beaucoup plus de sens que de passer son temps à découper des classes d'un point de vue technique sans comprendre comment ça crée réellement de la valeur pour le projet et cette nouvelle définition autour d'acteur et bien regardez comment elle peut créer beaucoup plus de valeur que la définition initiale imaginons que vous alliez chez le garagiste pour faire réparer vos vitres électriques et que quand vous retournez récupérer votre voiture et bien les vitres électriques marchent parfaitement mais la voiture ne démarre plus et bien vous auriez raison de penser que votre garagiste est un abruti puisque en répare une fonctionnalité de la voiture il en a cassé une autre qui était en l'occurrence encore plus important et donc essayez de vous projeter qu'est-ce que vous penseriez de ce garagisme après une telle opération normalement vous auriez une mauvaise image et bien dans le code c'est quelque chose de très commun le marketing va vous demander de modifier telle fonctionnalité sur cette page et puis sans faire exprès vous allez casser un accès en base de données sur une autre page et bien dites-vous qu'à ce moment-là le marketing vous voit comme vous vous voyez le garagiste et en appliquant cette nouvelle définition du SRP c'est-à-dire en découplant votre code en fonction de différents acteurs et bien quand quelqu'un va venir vous voir pour vous demander un changement sur votre code et bien en ayant appliqué cette nouvelle définition du SRP vous aurez un découpling qui fait que vous pourrez prendre en compte ce changement sans casser autre chose entre guillemets vous allez pouvoir vous concentrer sur réparer les vitre électrique sans avoir un coouoping gênant sur le moteur de la voiture et donc pour terminer vous donner un exemple un petit peu plus concret vous pouvez voir sur le schéma affiché à l'écran et bien une vision un peu macro de ce que je ferais sur un projet on va essayer créer une matrice pour respecter au mieux ce nouveau principe du SRP organisé autour des acteurs qui pourraient demander une raison de changer dans cette matrice vous pourrez voir à l'horizontale et bien les fonctionnalités juxtaposées que délivre votre logiciel et verticalement on va essayer d'avoir un découpage à un autre niveau autour des couches logicieles la couche de persistance pour sauvegarder des données sur un serveur distant la couche de domaines ou d'application qui va encapsuler des règles plus haut niveau liées spécifiquement à votre projet et puis la couche de persistance qui permet au final d'afficher quelque chose à l'utilisateur et en quadrillant un petit peu votre projet comme ça vous allez pouvoir avoir un niveau de découpage qui permet généralement de se rapprocher de cette nouvelle définition du SRP et ensuite une fois qu'on a ce niveau de découpage et bien on peut toujours se poser la question est-ce que dans la couche de persistance pour la fonctionnalité de récupérer d'afficher un utilisateur est-ce que là aussi il y a différents acteurs qui vont pouvoir nous demander différentes choses par exemple le designer qui va s'occuper de la couleur des boutons et le marketing qui va s'occuper de savoir si cette fonctionnalité sera affichée ou non sur une autre page finalement donc on peut toujours redécouper à l'intérieur de cette matrice un peu au niveau en fonction des acteurs qui pourraient demander des requirements sur votre projet et de ce que j'ai compris jusqu'à maintenant le découpage en couche logicielle s'appellerait le separation of concern SOC et le découpage en feature se rapprocherait de quelque chose qui s'appelle le Common closure principle qui est présenté aussi dans clean architecture ensuite à moins haut niveau en terme d'architecture quand vous êtes un peu plus bas autour de la manipulation de classe ou de service comme on peut le voir sur schéma et bien ici on parlerait du single responsability principal de ce que j'ai compris jusqu'à maintenant encore une fois c'est très amusant de lire partout que les bonnes pratique de code il faut avoir des règles strictes sur le nommage et cetera alors que même les experts de notre industrie ont parfois quatre noms différents pour désigner la même chose et c'est assez difficile de s'y retrouver sur tous ces principes qu'est-ce qu'il désigne exactement voilà en tout cas c'est une vidéo qui m'a pris beaucoup de temps à faire parce que je voulais vraiment aller au bout des choses sur un principe solide et on va les faire tous pour vraiment regarder qu'est-ce qu'il y a de sérieux de scientifique de qu'est-ce qu'on pourrait se mettre d'accord en tant qu'industrie sur chacun de ces principes en tout cas ça m'a permis de découvrir cette nouvelle définition du SRP que je trouve effectivement bien plus efficace et bien plus orientée sur la valeur que produit votre logiciel que la définition initiale que j'avais en tête et si ces vidéos où on creuse vraiment un sujet à fond vous intéressent et bien n'hésitez pas à me le mettre en commentaire parce que ça me permettra d'avoir vos retours sinon j'aurai l'impression que vous vous ennuyez avec ce genre de contenu plus poussé que d'habitude en tout cas merci d'avoir pris le temps de m'écouter et si cette vidéo vous a apporté de la valeur et que vous cherchez à devenir développeur web professionnel rapidement et bien voici trois manières dont je peux vous aider gratuitement premièrement je poste une nouvelle vidéo chaque semaine sur des principes de code avancés pour l'entreprise donc si ça vous intéresse vous pouvez repasser sur la chaîne quand vous en avez besoin pas besoin de vous abonner deuxièmement si ça vous intéresse d'avoir des interviews d'un techit chez Google ou d'un architecte chez Netflix sur la chaîne c'est-à-dire d'avoir des pointures de notre industrie qui passe sur la chaîne et bien n'hésitez pas à interagir en mettant des pouces bleus en mettant des commentaires pour faire connaître la chaîne et nous donner plus de crédibilité si demain on est 100000 au lieu de 20000 et bien une personne qui travaille chez Netflix sera plus enclin à venir passer du temps avec nous et donc ça ça pourrait être vraiment top et enfin troisièmement j'ai mis en libre accès à un workshop pour être prêt pour votre premier jour en entreprise sur sur JavaScript c'est un workshop qui dure entre 3 et 4 He et qui est gratuit donc si ça vous intéresse vous pouvez y accéder en cliquant sur le premier lien en description sous cette vidéo ce workshop sera accessible jusqu'à fin juin de cette année ensuite il sera retiré pour être remplacé par un autre voilà je vous dis à bientôt pour une prochaine vidéo bon code seigneor d'ici là Ciao