Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Mickaël Azerat, Mickaël bonjour.
Bonjour, bonjour.
Merci d'accepter l'invitation sur le podcast.
Pour les auditeurs qui ne te connaissent pas encore, est-ce que tu peux te présenter en une minute ?
En une minute, alors, pour ceux qui ne me connaissent, ils ne me connaissent pas.
Je suis passionné de développement en fait depuis bien longtemps, depuis plus dix ans.
En gros, je suis vraiment expert dans tout ce qui est clean coding et clean architecture,
et tout ce qui est élégance du code.
Je suis très perfectionniste à ce niveau-là,
et du coup je suis intéressé par tous les ouvrages et tous les concepts qui en émanent.
C'est pour ça que du coup j'aime bien parler et transmettre les connaissances,
et surtout apprendre aussi, mais j'ai pas mal de connaissances et j'aime bien les transmettre
pour essayer de conforter, soit de défacer de mauvaises idées reçues, de fausses idées,
soit d'apprendre de nouvelles choses, voire casser des préjugés sur certains concepts.
Super.
Aujourd'hui je te propose de parler du SRP, du Single Responsibility Principle.
Qu'est-ce que ça évoque pour toi ?
Le signal est responsable du principal.
Qu'est-ce que ça évoque pour moi ?
Je crois que c'est l'un des concepts les moins compris déjà,
parce qu'en fait ça vient du solide, donc c'est l'acronyme solide,
donc le bol alias Robert St. Martin avait évangélisé.
Donc solide, le premier on va s'intéresser au S, donc c'est le S, SRP,
donc signal responsable du principal, c'est en gros le concept le moins pris au sérieux par les développeurs,
parce que tout le monde pense que c'est du temps perdu, ou que c'est de la création de fichier pour rien.
En quoi ça consiste, le signal responsible principal,
c'est l'art de se dire qu'une place ou un fichier a maximum une raison de changer.
À partir du moment où il y a deux raisons au plus de changer,
c'est qu'il n'y a pas eu un split assez fort de la classe,
et qu'en gros ça va entraîner beaucoup de problématiques par la suite.
Est-ce que je rentre direct dans le sujet ?
Oui, mais c'est nickel.
Moi ça me plaît quand tu rentres comme ça, parce que c'était une des questions que j'avais préparé.
Moi je partage ton point de vue sur le fait que ça ne soit pas pris au sérieux.
En même temps, j'ai l'impression que c'est mal compris,
enfin que c'est même pas une question d'être mal compris,
c'est que c'est une question que c'est pas un enjeu qui est perçu.
Parce que pour moi ça va avec la qualité du nommage,
et quand tu vois que quand je poste un truc sur LinkedIn qui dit
si vous commentez votre code, c'est qu'il y a un problème,
je me fais encore rabrouer, c'est qu'on a du chemin,
je me dis il y a du boulot à faire passer certains messages.
Et du coup je me dis le SRP c'est quand même un super guide,
je trouve, pour aller vers ces enjeux de nommage et se poser des questions.
Et du coup il y a une question que je trouve passionnante,
parce que moi j'ai toujours peur de l'over engineering, de l'over design.
Quand est-ce que toi tu décides de splitter une classe qui en fait trop ?
Alors comme je viens de lui dire, c'est à partir du moment où je juge,
il y a le mode complexe et le mode facile, on va en rendre un mode facile,
à partir du moment où je juge que la classe a deux raisons de changer.
Je donne un exemple tout bête.
J'ai un petit logiciel qui doit générer un rapport et ensuite imprimer, ok très bien.
Je peux avoir carrément un document de service par exemple,
et dedans à l'intérieur je peux avoir une méthode qui fait Generate
et une méthode qui fait Print par exemple.
Ok donc on a un service assez global qui fait Generate et Print.
Quels sont les problèmes qu'on peut avoir là-dedans ?
Déjà on est bien d'accord que Generate et donc Generate un document est une chose,
l'imprimer en est une autre, qui conceptuellement n'ont rien à voir en fait,
même si la source donnée est la même.
Ouais là c'est évident, moi je te parle de choses qui, au moment où ça émerge,
parce que Sandy dans son bouquin, elle te parle pas de tout faire justement,
tout de suite tu vois, elle parle pas au contraire, mais elle dit
si vous avez une interface qui émerge, attendez d'avoir deux trois instances concrètes,
quand vous voyez qu'une classe s'en fait trop, à la rigueur isolée,
isolée, l'autre responsabilité dans une méthode, le temps de bien s'assurer
que vous avez trouvé le bon messager, le bon expéditeur, le bon receveur du message.
Pour toi c'est systématique, dès que tu vois le truc tout de suite tu rentres dans le tas.
Je le vois, en fait ce qu'il faut comprendre c'est que c'est pas forcément,
il y a fait plusieurs choses, alors voilà on casse, c'est pas juste ça,
Sandy participe à juste ça, c'est surtout au niveau de la cohésion.
Il faut qu'il y ait une cohésion forte dans l'objet ou la classe,
ou les fonctions même, ça s'applique aussi aux fonctions elles-mêmes.
Un exemple tout bête, il y a des gens qui appliquent, qui font du over-engineering
sur le SRP qui se disent, moi je dois pouvoir créer,
updater, diliter et émire, donc un read, dédonner, pas ça fait quatre classes.
La problème c'est qu'ils n'ont pas compris vraiment les sens du SRP
ou qu'ils l'ont trop appliqué à la lettre, alors qu'en fait,
create, update, delete, read, en fait c'est le crud,
ça veut dire que le crud est en une cohésion à être toute seule.
On sait très bien que ces choses là vont être utilisées ensemble,
c'est lire, écrire, etc. C'est le cycle de vie d'un objet, le crud.
Donc à ce moment là on en fait qu'une classe,
là où des gens vont se pliter amort le truc.
Par contre ce qui est avantageux et du coup pour s'y retrouver,
pour moi le SRP engendre vraiment un bénéfice énorme,
c'est la réutilisabilité du code.
Moi si demain je veux imprimer quelque chose qui n'a rien à voir
avec un document, mais je veux toujours imprimer,
ça m'énerverait si la méthode print était dans le document de service.
Parce que moi ce n'est plus le document de service,
c'est non c'est avec curriculum, curriculum service par exemple.
Dans ce cas là je suis bloqué, il faudrait que je refactore.
Et des fois il refactore engendre une recompilation,
alors que j'ai touché le général,
parce que j'ai touché la classe qui fait aussi le généreit.
Donc dans les projets remontés plus et plus,
je vais recompiler carrément énormément de données,
alors que ce n'était pas concerné.
Et aussi potentiellement, surtout s'il n'y a pas de test,
potentiellement je casse la feature de générateur.
Pendant que c'est mon petit refactor,
j'ai cassé la générateur alors que normalement je ne devais pas le faire.
Le fait d'avoir isolé ces concepts là
me permet de travailler, c'est le cas de le dire,
de manière isolée sans toucher
ce qui n'est pas affecté,
ce qui doit rester vraiment indépendant.
Et surtout au niveau des fonctions,
c'est là où vraiment le SRP a son sens,
c'est que justement on parlait tout à l'heure des commentaires, etc.
Comment éviter ça, c'est qu'en fait ce que je fais c'est des kilom fonctions.
Dès que je fais un commentaire en fait j'émerge une fonction qui le fait.
Et le truc c'est que plus la fonction est fine,
et plus elle fait une seule chose, et plus elle est réutilisable,
même dans la même chier.
Et ça c'est génial, par exemple on a à savoir
est-ce que c'est un mutiple de 3,
par exemple on a donné,
c'est une fonction est-ce que c'est un mutiple de 3,
il est mutiple of 5,
et bien c'est sympa que si on voit plusieurs occurrence de modules 5
dans le même fichier,
tu sais que je peux réutiliser ta fonction.
Et donc ta logique de ta fonction est à l'intérieur.
Donc en fait tu appliques le SRP à la fonction,
et dans ce cas là,
plus la fonction fait une seule chose,
plus elle est réutilisable,
et même à grande échelle, pas qu'un fichier.
Et donc ça c'est génial,
et donc voilà, ça s'applique vraiment à tout type de composantes,
ce soit les classes, les fonctions, les méthodes, etc.
Et c'est une bonne manière de se pliter son code,
et surtout de s'y retrouver,
et d'éviter en fait des classes qui font 200, 300 limes pour rien en fait,
et que dès qu'on touche, on risque de casser un existant.
Moi c'est surtout ce point là que je retiens
plus que les temps de compilation de compagnie,
c'est que ça rend le code plus lisible,
plus maintenant, plus évolutif, et ça ça me...
Et ça permet comme tu l'as dit,
au départ de nommer les choses.
Document service pour moi ça va rien dire,
document manager pour moi ça va rien dire.
Par contre document printer ça me fait plaisir.
Document generator ça me fait plaisir aussi.
Voilà donc c'est...
ça permet de nommer les choses,
et de l'expliquer,
et surtout de migrer facilement vers les autres,
les autres parties de l'acronyme,
le O, le L, le I et le D de Solide,
parce qu'ils demandent justement une bonne maîtrise de la certé,
je pense que c'est pour ça que ça commence par S d'ailleurs,
parce que les autres demandent
une certaine maîtrise de ce truc là,
parce que les avantages sont hyper nombreux pour la suite des acronymes.
Je suis complètement d'accord avec toi, c'est la base,
et c'est d'ailleurs pour ça que j'ai commencé par ça
dans mon cycle de formation,
mais j'en dis juste, j'en dis un peu plus juste après.
Merci Michael d'être venu aujourd'hui.
Si les auditeurs vont en savoir plus,
ils viennent, ils viennent ou ils viennent sur LinkedIn, c'est ça ?
C'est plus simple c'est par LinkedIn,
après peut-être que j'ai duré ailleurs,
j'ai fait pas mal de vidéos aussi sur qui étaient aidées,
toutes les principes des LinkedIn sont sur YouTube,
mais je crois que la bonne entrée c'est mon LinkedIn,
et en général tu réactifes,
et je réponds rapidement aux questions,
les questions remarquent ou critiques,
je suis assez réactif sur cette super plateforme.
Super Michael, merci, merci encore.
Quant à toi chère auditeurs,
eh bien écoute, je viens justement de sortir une formation
qui t'explique comment appliquer le single responsibility principle,
pourquoi le maître en oeuvre, comment le maître en oeuvre,
c'est surtout ça, quand tu vas te poser des questions en face à ton code,
quels sont les éléments concrets qui vont te guider
dans sa mise en place,
c'est dans la maison des compagnons que je t'invite
à rejoindre tout de suite.
Je te remercie pour ton écoute et je te dis à demain.