Mathieu Barberot

Grand-Est

Passionné de code, je fais du TDD depuis plusieurs années, pour mon plus grand bonheur.

Aujourd'hui, on parle Clean Architecture avec Nicolas Deboose :
 
De quoi est-elle constituée ? 
Quand l’utiliser et que peut-elle amener ? 
Est-elle aussi sujette aux phénomènes de « mode »  comme certains frameworks ? 
Si tu veux aller plus loin, quelles sont les ressources ? 


Partagé par Artisan Développeur
il y a 2 mois
2

Derniers commentaires :
Mathieu Barberot il y a environ 2 mois - modifié il y a environ 2 mois
J'ai bien aimé cet épisode.
Nous avions essayé d'en s'en approcher avec un archi hexagonale + du DDD dans une de mes précédentes expériences et il y avait eu pas mal de réticences ou de frustration face à la verbosité du code lié aux différentes interfaces qui permettent d'abstraire les couches externes. J'avais alors eu pas mal de questions similaires à celles de Benoit. Hélas, je n'avais pas l'expérience de Nicolas pour y répondre.

Avec le recul, je pense que c'était un changement vraiment trop important et il aurait sûrement été plus avisé d'y aller incrémentalement. Ne serait-ce déjà que commencer par initier l'équipe à la notion de couplage du code et de son rapport gain/risque pour mieux comprendre l'intérêt des concepts qu'on applique ensuite.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.

Vue.js ne serait-il pas un jouet ?! Pourquoi ne pas faire du react plutôt ? 

Son image de framework facile à appréhender signifie-t-elle un outil moins puissant ? 

Y a-t-il un risque de miser sur Vue.js aujourd’hui ? 
Quelle opportunité représente ce framework pour les dev ? 

On en parle dans l’épisode d’aujourd’hui avec Elise Patrikaien, développeuse front end freelance sur Vu.js et Angular.

Pour suivre Elise Patrikaien sur linkedin : www.linkedin.com/... 
Pour suivre Elise Patrikaien sur Twitter : twitter.com/elisepatrikain1 


Partagé par Artisan Développeur
il y a 4 mois
0

Derniers commentaires :
Mathieu Barberot il y a 3 mois - modifié il y a 3 mois
Hello,

Merci à Élise pour son retour sur Vue.js.

Je suis entièrement d'accord avec elle sur la prise en main vraiment aisée de Vue.js. J'ai eu plusieurs fois l'occasion d'accompagner des devs backends à passer à Vue.js et effectivement, la montée en compétence s'est généralement bien passée, très graduelle et en découvrant au fur et à mesure toutes les fonctionnalités ES6.
Sans compter que depuis l'arrivée du Vue CLI, l'outil de ligne de commande, la gestion de la chaîne d'outillage sous-jacente est grandement simplifiée.

En revanche, bien que je n’aie pas encore essayé la version 3, je suis un peu inquiet entre l’image donnée par Benoît de Python 2 vs 3 sur l’écosystème, et l’impression qu’il repose beaucoup plus qu’avant sur une bonne connaissance de JS/ES laissant de côté la simplicité qui à fait son adoption, mais j’espère me tromper :)

Par contre, mon retour sur l’utilisation de Vue.js en entreprise est mitigé. Pour avoir travaillé sur plusieurs applications, j'ai pu constater que la vélocité baisse très vite dès que l'application commence à se complexifier.

Je pense que ça vient d’une part que Vue.js ne se suffit pas à lui-même. On se retrouve vite à ajouter une couche de gestion des données, généralement la combo Axios pour les appels REST et Vuex pour la gestion des données. Et puis on a plusieurs pages, alors on ajoute un routeur, généralement Vue Routeur. Cette liberté d'ajouter des briques au fur et à mesure du besoin, ça m'a surtout donné l'impression de réinventer la roue en me fabriquant un framework maison.

D’autre part, Vue.js ne propose aucune architecture pour le projet. On a quelques bonnes pratiques qui ont émergées comme le Props Down Events Up(1) et appliquer le bon vieux SRP pour éviter que ça parte trop en plat de spaghettis, mais c'est tout.
Du coup, on a dû expérimenter pour trouver nos propres conventions :
- un package "ui" avec les composants de base réutilisables
- des packages métier avec les composants qui font des traitements et le lien avec le store
- un package "page" pour les composants qui représentent les pages
- un package "store" pour le traitement des données
- un package "api" pour ne pas avoir du Axios partout dans le code
Tout ça consommant du temps et de l'énergie qui auraient pu être utilisés pour du développement de fonctionnalité.

Au final, j'ai du mal à voir l'avantage de cette approche sur les frameworks tel qu'Angular ou Ember.js.

Donc pour répondre à la question initiale du podcast : pour moi, oui, Vue.js est un jouet. Tout comme React d'ailleurs.
Les libs de composant, c’est parfait pour une démo ou un widget météo, mais pour faire une app, c'est vraiment insuffisant. Mon regard se porte maintenant sur les frameworks qui se construisent par dessus ces libs. Élise en a mentionné quelques-uns pour Vue.js : Nuxt et Quasar, qui me semblent également être les plus prometteurs.

(1) jasonformat.com/...

EDIT: reformulations
Marc Bouvier il y a 3 mois
Hello Mathieu. Yeps, sur le sujet de la complexité pour des applications d'entreprise, je trouve que Nuxt et se conventions adressent plutôt bien ces problématiques.

Pour aller un peu plus loin, je trouve que les webcomponents ont pas mal de potentiel. Ils peuvent être écrits en vanilla js , avec vuejs ou autre. Puis être intégrés avec d'autres frameworks.
Un bon exemple chez Clever Cloud : www.clever-cloud.com/...

Hubert Sablonnière en parle par ici : www.youtube.com/...
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.

Tester des composants graphiques, ok mais comment ? 


Partagé par Artisan Développeur
il y a 6 mois
1

Derniers commentaires :
Mathieu Barberot il y a 5 mois - modifié il y a 5 mois
Super épisode, on entend pas assez parler des tests dans le monde du frontend, même si personnellement, je ne suis pas un grand fan des snapshots.

Voir les snapshots passer régulièrement au rouge et devoir les ré-accepter est quand même assez pénible et à la longue ça m'a poussé à les accepter sans me poser de question, ce qui ne me convenait pas.

Au final, j'utilise l'approche des "test selectors" que j'ai découvert avec Ember.js (si vous en avez marre de réinventer la roue et de faire de la plomberie avec React/Vue, allez jeter un coup d'oeil). J'apprécie cette méthode car elle se repose uniquement sur le fait qu'un élément ciblé de manière unique est bien présent, quelque soit son emplacement dans le DOM et ça me permet de refactorer des composants sans que le test passe au rouge.

Quelques ressources sur les tests selectors :
simplabs.com/...
docs.cypress.io/...
testing-library.com/...
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Bonnes pratiques

Récemment, Dart 2.12 a été livré dans Flutter 2. Cette mise à jour contient l’une des fonctionnalités les plus importantes du langage qui est le Null Safety.


Partagé par Benoit GANTAUME
il y a 7 mois
1

Derniers commentaires :
Mathieu Barberot il y a 6 mois
Venant de Java et ayant adopté Kotlin (qui implémente aussi le Null Safety) pour mes projets perso, j'apprécie beaucoup cette sécurité de ne plus avoir à me soucier de la fameuse NullPointerException qu'on rencontre si souvent en Java lorsqu'on tente d'utiliser une variable "null".
Au final, lorsque je programme en Java (le monde professionnel ne semble toujours pas prêt pour Kotlin) je me rends compte que mon code est devenu plus défensif qu'il y a quelques années justement pour vérifier ce genre de chose et retrouver la sérénité que j'ai sur du Kotlin :/
Marc Bouvier il y a 6 mois
En effet la null safety par défaut permet de déporter le problème à un seul endroit : les entrées-sorties (I/O). Dans la plupart des autres cas, je trouve que le fait de ne pas pouvoir utiliser des valeurs null par défaut nous oblige a nous poser la raison métier du cas particulier et a questionner notre conception.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Agilité

Agile est de très loin la méthodologie phare du développement logiciel. Mais est-elle aussi parfaite qu'elle en a l'air ? C'est ce qu'on va voir.


Partagé par Léo Driat
il y a 7 mois
0

Derniers commentaires :
Mathieu Barberot il y a 7 mois
C'est marrant, je n'avais jamais interprété le point n°6 comme ça. Pour moi, j'y ai toujours lu "si tu as une question, adresse toi directement à la personne plutôt que de lui envoyer un mail", quitte à payer un café, j'ai toujours été gagnant à appliquer cette règle. Par contre, je te rejoins sur le besoin de garder des notes écrites sur le contenu de la discussion et de les partager à l'ensemble de l'équipe qui n'était probablement pas présente lors de l'échange, surtout dans cette époque de télétravail qui ne facilite pas les échanges spontanés qu'on aurait dans un espace de travail ouvert.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Agilité

Agile est de très loin la méthodologie phare du développement logiciel. Mais est-elle aussi parfaite qu'elle en a l'air ? C'est ce qu'on va voir.


Partagé par Léo Driat
il y a 7 mois
1

Derniers commentaires :
Benoit GANTAUME il y a 7 mois
"Agile est de très loin la méthodologie phare du développement logiciel."
Je suis ému de lire ça... Il y a 20 ans quand j'en parlais, je passais pour un fou...
Quelque part, je suis rassuré de voir que l'outil miracle n'existe pas.
Mathieu Barberot il y a 7 mois - modifié il y a 7 mois
C'est peut être effectivement en raison du flou autour des implémentations du manifeste, mais effectivement j'ai l'impression que nombreux sont ceux qui se disent d'un seul coup "Allez, ce nouveau projet on le fait en agile" et tombent dans le "Dark Agile".
Je pense au contraire que l'agilité est un état qu'on atteint lorsqu'on à mis en place au fur et à mesure les méthodes et pratiques qui vont dans le sens des concepts du manifeste.
L'exemple typique : on ne peut pas décréter du jour au lendemain qu'on va déployer souvent si on ne l'a jamais fait avant. Il faut une bonne culture devops pour avoir l'automatisation, des bonnes pratiques de dev pour ne pas livrer des tonnes de bugs et de l'organisationnel pour livrer des jalons incrémentaux avec de la valeur.
Rien que ça, c'est déjà tout un projet pour bon nombre d'entreprises et ça ne couvre qu'une partie du manifeste !
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Bonnes pratiques
Clean Code

Du code impeccable écrit partout pareil, ça donne envie, non ? Et pourtant, l’idée s’avère bien plus risquée qu’elle n’y parait.


Partagé par Léo Driat
il y a 8 mois
2

Derniers commentaires :
Mathieu Barberot il y a 8 mois - modifié il y a 8 mois
Globalement d'accord.
J'aurais quand même tendance à poser un .editorconfig d'office dans n'importe quel projet pour les conventions les plus basiques : encodage des fichiers, espaces/tabulations, cr/lf en fin de ligne...
C'est supporté par tous les éditeurs, ça ne mange pas de pain et ça évite bien des problèmes (je pense à toi, le caractère de fin de ligne différent selon l'OS et aussi à toi fichier YAML qui ne supporte pas les tabulations).
Pour les aspects plus avancés, je recommanderais les conventions officielles (s'il y en a) et de n'en diverger qu'exceptionnellement : un nouvel arrivant aura déjà bien assez de sujets qui nécessitent une réadaptation.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Bonnes pratiques
Design Pattern

Qu'est-ce que le pattern stratégie ?
Comment l'utiliser ?
Maxime nous partage ce qu'il a appris.


Partagé par Benoit GANTAUME
il y a 8 mois
3

Derniers commentaires :
Romain Fallet il y a 8 mois
@Benoit GANTAUME j’ai pas d’exemple d’articles mais moi le concept que j’aime bien c’est celui des utilisateurs. Ça parle à tout le monde (je pense ?), un utilisateur peut être réduit à juste une adresse email si on veut un exemple méga simple, ou on peut en faire un méga-truc complexe avec de la persistence, des droits d’accès, de l’authentification... si on a besoin de matière pour illustrer un concept pointu
Romain Fallet il y a 8 mois
Ce commentaire a été supprimé par son auteur.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Architecture Hexagonale
Clean Architecture
front-end

Le concept de « Clean Architecture », qu’on appelle aussi l’« Architecture hexagonale » ou encore « Ports/Adapters Architecture » a déjà fait ses preuves dans le développement d’application backend. Si cette technique a gagné en popularité ces dernières années, elle ne s’est pas beaucoup démocratisée dans le développement d’application frontend.


Partagé par Manu Dss
il y a 9 mois
3

Derniers commentaires :
Mathieu Barberot il y a 9 mois
Vraiment intéressant, j'ai apprécié le passage progressif du concept à l'implémentation, les exemples tout au long de la présentation et surtout la mise en pratique.
Par contre, la question que je me posais : le présentateur utilise un objet passé en paramètre pour "retourner" le résultat de ses use cases. Je n'arrive pas à voir ce que cela apporte de bénéfique par rapport a un bon vieux return. Ou est-ce juste un détail d'implémentation ?
Marc Bouvier il y a 9 mois
Coucou Mathieu :)
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Architecture
Design Pattern

Les patrons de conception, que sont-ils et pourquoi sont-ils si indispensables ? Je vous explique ça avec mes piètres talents de dessinateur.


Partagé par Léo Driat
il y a 11 mois
8

Derniers commentaires :
@Romain Fallet, ce site est fait pour toi
refactoring.guru/fr
Mathieu Barberot il y a 11 mois - modifié il y a 11 mois
Intéressant, quoiqu'un peu dubitatif sur le passage des phases de réalisation et d'architecture : "identifier les patrons de conception qui se cachent derrière une exigence client" et " assembler les patrons de conception [...] avant même d’avoir commencé à coder".
Je me suis bien trop souvent brûlé les ailes en faisant des abstractions prématurées sur des exigences client bien souvent mouvantes.
Je préfère largement laisser émerger les abstractions de l'étape de refacto du cycle TDD, qui s'apparente à la phase de réusinage de l'article du coup.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Artisan Développeur utilise des cookies afin de t'offrir les meilleurs services. En poursuivant ta navigation, tu acceptes l’utilisation de cookies. En savoir plus