Hello ! Je suis tombé par hasard sur tes vidéos et elles sont assez intéressantes, même en tant que dev iOS ! Je me demandais, est-ce que tu aurais des ressources (livres ou autre) sur les TUA ? J'aimerai savoir quel est l'état de l'art actuel sur le sujet mais je galère à trouver des infos solides Merci encore pour le boulot mis dans tes vidéos
17:00 Je pense que tu perds les débutants ici. Cette distinction n'est pas importante autant concrètement que théoriquement. Le pattern dont tu parles, au final, c'est simplement d'ajouter une couche d'abstraction pour simplifier l'interface utilisée par le client. Mais ça c'est vrai à tous les niveaux d'abstraction. On veut, le plus possible, avoir une interface simple à utiliser pour la couche du dessus. Et d'ailleurs si on veut rester puriste, faire de la refacto passe bien souvent par l'implémentation de design patterns. Leur niveau d'abstraction n'a pas d'incidence sur le travail fourni. Cela reste du refactoring, on améliore la structure du code sans modifier son comportement. Super vidéo en tout cas, et totalement d'accord avec le début, c'est un concept tellement fondamental et générique...mais bon, "facade" c'est plus stylé que "service" :)
Merci pour ce contenu de qualité pour les développeurs un peu plus avancé que la majorité des contenus de YT. As tu des conseils de livres que tu recommandes avec un mix entre hard et softskills ?
Le client désigné le « code client ». En ayant en tête comment votre code va être consommé et être attentif au contrat que vous construisez, vous pouviez construire un code plus stable pour un projet. Bon code !
J'utilise les Reactive Forms, mais c'est à vous et votre équipe de choisir. D'excellents développeurs préfèrent les templates driven form. Mais j'ai une moins bonne expérience avec sur des projets importants.
Très bonne vidéo merci ! Question HS que penses-tu de Svelte/kit notamment pour des débutants et éventuellement pour des pros ( d’ailleurs si d’autres veulent répondre aussi )
Je me concentre exclusivement sur une analyse PRO. Je regarde d'abord le marché. Et le marché dit : Angular, React et Vue. Le léger avantage de Svelte sur sa gestion de la réactivité interne va être rattrapé dans les nouvelles mises à jour de ces 3 frameworks. Je ne vois pas comment ce framework va se faire une place, même si je fais ma veille technique dessus de temps en temps.
C'est effectivement une bonne intuition. La facade implémente une interface qui vient "chapeauter" ce que Simon Dieny appelle le code legacy dans la video (les composants qui remplissent les fonctionnalités concrètes ensemble). Ainsi le code client dépend (utilise) de cette nouvelle interface tandis que les composants legacy forment un groupe qui implémente cette nouvelle interface. Le flux de dépendances n'a donc plus un sens unique puisque chaque coté voit sa dépendance converger vers la facade. C'est ce la que l'on appelle l'inversion de dépendances.
@@codeursenior ? @mrmaxwell0701 a raison même si on peut utiliser les facades sans inversion de dépendances. Autant le faire, ça permet d'injecter des interfaces plutôt que des implémentations, et donc d'avoir une facade flexible dont le comportement peut changer sans changer d'interface. Pas besoin pour une classe d'être abstraite pour lui injecter des interfaces 🤔
@@codeursenior C'est littéralement une citation du film d'animation. Alors que Blanche Neige nettoie la maison des 7 nains, deux écureuils tentent de cacher du code spaghetti derrière une façade et elle leur did "non non non, ça ce n'est pas une abstraction. Une abstraction c'est quelque chose au sujet duquel tu peux raisonner et dont tu peux prédire le comportement, alors vire-moi cette classe ou ce hook qui ne veulent rien dire car tu vas finir par dépendre d'une interface qui couple des choses qui ne devraient pas être couplées et que tu ne pourras pas simplement refactor après". Enfin, elle dit tout ça en chantant bien-sûr ;)
Pour être honnête, le danger de penser qu'un cache misère est une abstraction, il est traité à différents moments dans la vidéo, notamment quand tu précises qu'il faut une façade par client. Parce que ce qui ne manque pas d'arriver, et je l'ai vraiment vu et revu, c'est de te retrouver à avoir plusieurs composants qui ne dépendent pas de la même partie d'une même facade, et là tout l'intérêt de la façade disparaît parce qu'à l'origine ce que tu voulais c'était que tes composants ne dépendent pas de fonctionnalités dont ils n'ont pas besoin, parce que ça les rend fragiles. Mais le souci quand on crée des interfaces qui n'ont pas de sens, qui ne sont pas des abstractions, c'est que ce genre de chose peut arriver sans qu'on s'en rende vraiment compte parce qu'on n'est pas capable d'expliquer pourquoi telle fonctionnalité dont appartenir à telle classe ou à telle autre. D'autant que, comme tu le soulèves, si tu utilises une façade, tu as envie qu'elle devienne l'unique interacteur du client, si non ce serait une demi-façade. La façade, c'est simple, c'est puissant, mais c'est terriblement insatisfaisant. Je l'utiliser surtout pour ne pas exposer des parties que j'ai exporté parce que ce sont des abstractions internes que je veux tester et qui sont partagées par différentes parties de l'application ou de la bibliothèque, mais qui ne doivent pas franchir une barrière architecturale ou une API.
@@ApprendreSansNecessite Au top, merci pour ton retour. J'essaye de faire passer ce message : 1 Facade pour 1 client donné. Vous pensez que je mentionne trop le terme "cacher le bazar" ?
10:0411:24 Mdr c'est à cause des deadlines et des turnovers chacun fait à sa sauce.. et bonne chance à au lead tech qui est arrivé après un départ précipité et pas loin de la deadline..
Très intéressant merci à toi
Hello ! Je suis tombé par hasard sur tes vidéos et elles sont assez intéressantes, même en tant que dev iOS !
Je me demandais, est-ce que tu aurais des ressources (livres ou autre) sur les TUA ? J'aimerai savoir quel est l'état de l'art actuel sur le sujet mais je galère à trouver des infos solides
Merci encore pour le boulot mis dans tes vidéos
très inintéressante comme video mais un cas concret avec du code permet de consolider la compréhension de ce que tu explique
Salut, c'est entendu, je me suis noté de rester le plus possible concret dans les prochaines vidéos.
17:00 Je pense que tu perds les débutants ici. Cette distinction n'est pas importante autant concrètement que théoriquement. Le pattern dont tu parles, au final, c'est simplement d'ajouter une couche d'abstraction pour simplifier l'interface utilisée par le client. Mais ça c'est vrai à tous les niveaux d'abstraction. On veut, le plus possible, avoir une interface simple à utiliser pour la couche du dessus.
Et d'ailleurs si on veut rester puriste, faire de la refacto passe bien souvent par l'implémentation de design patterns. Leur niveau d'abstraction n'a pas d'incidence sur le travail fourni. Cela reste du refactoring, on améliore la structure du code sans modifier son comportement.
Super vidéo en tout cas, et totalement d'accord avec le début, c'est un concept tellement fondamental et générique...mais bon, "facade" c'est plus stylé que "service" :)
Salut, merci pour ton retour. Il me semble que nous sommes d'accord sur le fond, même si nous n'utilisons pas tout à fait le même vocabulaire.
vidéo encore très intéressante, beaucoup d'évolution depuis 2 ans sur la qualité de celle-ci continue comme ca 😎😎
Merci pour ton retour sur la qualité des vidéos, ça fait plaisir à entendre. 👍
Merci pour ce contenu de qualité pour les développeurs un peu plus avancé que la majorité des contenus de YT.
As tu des conseils de livres que tu recommandes avec un mix entre hard et softskills ?
Oui, tout à fait. J'envisage de proposer une vidéo prochainement, vous êtes nombreux à me l'avoir demandé.
Bon code et à bientôt,
Simon.
le client c'est le consumer? (ou le voyageur devant le comptoir de l'aeroport)?
Le client désigné le « code client ». En ayant en tête comment votre code va être consommé et être attentif au contrat que vous construisez, vous pouviez construire un code plus stable pour un projet. Bon code !
Heureux de te revoir
Yesss
Une question, tu utilises plus les templates driven form ou les reactives forms ?
J'utilise les Reactive Forms, mais c'est à vous et votre équipe de choisir. D'excellents développeurs préfèrent les templates driven form. Mais j'ai une moins bonne expérience avec sur des projets importants.
Salut quels sont les 5 projets pour débutants que tu conseillais dans une précédente vidéo ?
Bonjour, merci pour votre message, car cela me fait penser que je dois faire une vidéo sur le sujet. À très vite !
Très instructif
Au top. 👍
Peut tu nous apprendre à écrire les test unitaire 🙏🙏🙏 stp
Hello, oui il faut que je fasse une vidéo sur le sujet. Le thème est trop important et sous abordé.
Sympa, meme pour un non front-end (Data Engineer).
Salut, merci pour l’info c’est top que ça puisse parler à plus de monde.
Merci Simon
Merci à vous, bon code !
Simon.
Très bonne vidéo merci !
Question HS que penses-tu de Svelte/kit notamment pour des débutants et éventuellement pour des pros ( d’ailleurs si d’autres veulent répondre aussi )
Je me concentre exclusivement sur une analyse PRO. Je regarde d'abord le marché. Et le marché dit : Angular, React et Vue. Le léger avantage de Svelte sur sa gestion de la réactivité interne va être rattrapé dans les nouvelles mises à jour de ces 3 frameworks. Je ne vois pas comment ce framework va se faire une place, même si je fais ma veille technique dessus de temps en temps.
Pourquoi ça me fait penser au principe d'inversion de dépendance ?
La Facade n'est pas une classe abstraite, et on ne pas utiliser l'injection de dépendance.
C'est effectivement une bonne intuition.
La facade implémente une interface qui vient "chapeauter" ce que Simon Dieny appelle le code legacy dans la video (les composants qui remplissent les fonctionnalités concrètes ensemble).
Ainsi le code client dépend (utilise) de cette nouvelle interface tandis que les composants legacy forment un groupe qui implémente cette nouvelle interface.
Le flux de dépendances n'a donc plus un sens unique puisque chaque coté voit sa dépendance converger vers la facade.
C'est ce la que l'on appelle l'inversion de dépendances.
@@codeursenior ? @mrmaxwell0701 a raison même si on peut utiliser les facades sans inversion de dépendances. Autant le faire, ça permet d'injecter des interfaces plutôt que des implémentations, et donc d'avoir une facade flexible dont le comportement peut changer sans changer d'interface.
Pas besoin pour une classe d'être abstraite pour lui injecter des interfaces 🤔
le mec est dev senior depuis 125 ans tourne toujours des vidéos comme un clochard au rsa , c'est fort
Je confirme ce qui est suggéré dans ce commentaire :
J'ai bien 125 ans d'expérience en tant que développeur Senior.
Blanche Neige a dit : "Non non non ! Pas sous l'tapis"
J'ai pas la référence mais ça à l'air croustillant.
@@codeursenior C'est littéralement une citation du film d'animation. Alors que Blanche Neige nettoie la maison des 7 nains, deux écureuils tentent de cacher du code spaghetti derrière une façade et elle leur did "non non non, ça ce n'est pas une abstraction. Une abstraction c'est quelque chose au sujet duquel tu peux raisonner et dont tu peux prédire le comportement, alors vire-moi cette classe ou ce hook qui ne veulent rien dire car tu vas finir par dépendre d'une interface qui couple des choses qui ne devraient pas être couplées et que tu ne pourras pas simplement refactor après". Enfin, elle dit tout ça en chantant bien-sûr ;)
Pour être honnête, le danger de penser qu'un cache misère est une abstraction, il est traité à différents moments dans la vidéo, notamment quand tu précises qu'il faut une façade par client. Parce que ce qui ne manque pas d'arriver, et je l'ai vraiment vu et revu, c'est de te retrouver à avoir plusieurs composants qui ne dépendent pas de la même partie d'une même facade, et là tout l'intérêt de la façade disparaît parce qu'à l'origine ce que tu voulais c'était que tes composants ne dépendent pas de fonctionnalités dont ils n'ont pas besoin, parce que ça les rend fragiles. Mais le souci quand on crée des interfaces qui n'ont pas de sens, qui ne sont pas des abstractions, c'est que ce genre de chose peut arriver sans qu'on s'en rende vraiment compte parce qu'on n'est pas capable d'expliquer pourquoi telle fonctionnalité dont appartenir à telle classe ou à telle autre. D'autant que, comme tu le soulèves, si tu utilises une façade, tu as envie qu'elle devienne l'unique interacteur du client, si non ce serait une demi-façade.
La façade, c'est simple, c'est puissant, mais c'est terriblement insatisfaisant. Je l'utiliser surtout pour ne pas exposer des parties que j'ai exporté parce que ce sont des abstractions internes que je veux tester et qui sont partagées par différentes parties de l'application ou de la bibliothèque, mais qui ne doivent pas franchir une barrière architecturale ou une API.
@@ApprendreSansNecessite 😂
@@ApprendreSansNecessite Au top, merci pour ton retour. J'essaye de faire passer ce message : 1 Facade pour 1 client donné. Vous pensez que je mentionne trop le terme "cacher le bazar" ?
Merci !
Au plaisir, bon code !
10:04 11:24 Mdr c'est à cause des deadlines et des turnovers chacun fait à sa sauce.. et bonne chance à au lead tech qui est arrivé après un départ précipité et pas loin de la deadline..
Ah ça, on découvre généralement l'historique sur le terrain.
Merci
Merci à toi.
Simon.
T'as pas été l'un des plus jeunes formateurs JavaScript de France toi par hasard ?
Bon sang ! Comment est-ce que vous le savez ?
"les patterns sont la démonstration de la faiblesse d'un langage". P. Norvig.
J'ai largement changé de paradigme en passant à d'autres langages.
Vous êtes passé de quel langage à quel langage ? Et de quel paradigme à quel paradigme ?
Nom de Zeus ! Je me rends compte que je viens de mettre en place ce pattern façade dans mon application java. De façon purement intuitive
Les bons principes, on finit toujours par les inventer si on ne les connaît pas d'avance.
Vous pouvez désormais prétendre au titre de développeur Senior !
montre nous du code :p hein
Vous avez raison, c'est un peu sec. La vidéo manque de sauce là-dessus !
La musique est tellement inutile. Le contenu est là
C’est déjà mieux que le contraire : « le contenu est inutile, mais la musique est là »