Benoit GANTAUME
Pertuis
Passionné par le code depuis ma tendre enfance, j'essaie de donner le virus du code bien fait avec artisandeveloppeur.fr.
Développeur, entrepreneur, webmarketeur, podcasteur, youtuber, enseignant, formateur, créateur, auteur sont autant de facettes de mon quotidien.
Ma dernière lubie ? Faire de compagnon un saas utile aux développeurs.
Comment et pourquoi créer un design system ? Quelles sont les sources de motivation des devs ?
Pourquoi le rendre open source ? Peut-il vraiment être transposable sans difficulté ?
Quels sont les défis de sa maintenance ?
Le code de qualité est-il une évidence pour tous les développeurs ?
Déjà, merci pour ce podcast, c'est toujours des sujets intéressant avec des intervenants qualitatif et ça fait plaisir ^^.
Ensuite, merci à Xavier d'apporter son témoignage sur le sujet.
Je suis dev web depuis 10 maintenant et j'ai eu l'occasion de changer d'entreprise plusieurs fois.
J'ai eu l'occasion de pratiquer pendant 1 an les tests unitaires mais surtout les tests fonctionnelles. Ce n'était pas du TDD car on faisait les tests après avoir coder nos solutions, mais j'ai quand même pu comprendre l'intérêt de la démarche et surtout de comprendre que ce n'était pas du temps perdu.
Mais voilà, j'ai fais 8 boîtes différentes et seulement 1 seules d'entre-elles encadrait le code de l'application avec des tests. C'était d'ailleurs la seule entreprise ou presque à avoir en tête les principes agiles, les bonnes pratiques, à mettre en pratique les design pattern de manière propre et justifiée.
Force est de constaté que si l'entreprise ne possède pas cet état d'esprit à l'origine et la force de s'y tenir sur le long terme, c'est vraiment pas possible de faire attention à la qualité de son travail de manière rigoureuse et complète.
En tout cas, c'est mon ressentit
Et encore, tu as eu de la chance : je suis pas sûr qu'une boite sur 8 utilise les tests automatiques (je ne parle même pas de faire du TDD).
Si c'est important pour ta pratique, je t'invite à en faire un critère de choix pour tes futurs jobs.
Est-ce que les frameworks et l'architecture hexagonale font bon ménage ?
Y-a-t-il des projets qui s’adaptent mieux que d’autres avec de l’hexa ou du framework ?
Quelles sont les contraintes, les atouts ?
Comment choisir et adapter son projet à l'une de ces 2 patterns ?
Merci pour ce podcast très chouette, j'ai particulièrement apprécié la partie sur la gestion/priorisation de la dette technique liée à l'absence d'archi hexa.
J'aurais bien aimé quelques précisions sur le fait de switcher vers de l'archi hexa avec Rails. Qu'entends-tu Benoit précisément ? Sur le sujet rails/harchi hexa j'ai la référence suivante que j'avais trouvée très intéressante : martinfowler.com/.... Ce que j'en ai retenu : si le métier s'y prête, il peut être pertinent de partir sur du Rails, donc avec la partie sgbd dans l'hexagone. En revanche cela n'empêche pas de faire de l'hexagonal sur les interactions que l'on considère à droite de l'hexagone, comme les appels vers d'autres partenaires. Et ce point me fait réagir aussi sur la définition de l'archi hexa qui serait "une standardisation du principe d'inversion de dépendance". L'inversion de dépendance me semble effectivement un point important de l'archi hexa, mais l'isolation des modèles (le côté anticorruption layer de l'archi) me parait tout aussi important et n'a pas été évoqué. Car on peut avoir de l'inversion de dépendance, mais se trimballer des objets d'api comme modèle métier, et ça, c'est bien galère :)
Bonne remarque.
Vis-à-vis de rails, mon point est simplement de dire que l'hexa dénature par mal le framework.
Si c'est pour faire ça, autant partir sur autre chose (ou créer un autre framework ?).
Ce n'est que mon avis.
Je me bats avec notre code base pour faire des tests lisibles et pas trop répétitifs mais je ne suis pas ravi par le résultat. Récemment, nous avons décidé d'arrêter de mocker le "domaine" lorsque nous testons les contrôleurs. Les tests sont moches mais éfficaces et testent les grandes lignes (le domaine est plus facile à tester pour couvrir tous les cas). Mais je m'étonne d'être de moins en moins convaincu par les tests unitaires (unité=classe).
blog.sebastian-daschner.com/...
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.
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.
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 !
Qu'est-ce que le pattern stratégie ?
Comment l'utiliser ?
Maxime nous partage ce qu'il a appris.
Qu'est-ce que le pattern stratégie ?
Comment l'utiliser ?
Maxime nous partage ce qu'il a appris.
Dans GenerationRemote, je reçoit des chefs d’entreprise, des digital nomads et des salariés qui pratiquent le télétravail au quotidien.
Dans GenerationRemote, je reçoit des chefs d’entreprise, des digital nomads et des salariés qui pratiquent le télétravail au quotidien.
Pour suivre le cursus Artisan Développeur : ad302.fr/3syGBo
Pour faire ton diagnostic de pratiques gratuit : ad302.fr/vA9131
Sinon tu as celui-là que j'aime bcp : adventofcode.com
Très intéressant, comme toujours ;-)
Mais il y a une question que je me posais tout de même : quand tu as abordé l'intérêt d'utiliser le design system de Welcome to the Jungle, les invités ont indiqués qu'il y en avait des bien plus personnalisables déjà sur le marché, pourquoi alors en avoir développé un maison ?
Je me suis dit que ça pouvait peut-être permettre de ne pas se reposer sur un projet qui pourrait faire des breaking change trop souvent et ainsi permettre de migrer les sites de l'entreprise en douceur, mais non, ils nous indiquent en être à la 5e versions majeure en l'espace de 3 ans (si j'ai bien suivi), de migrations compliquées et d'un refactoring en mode "hardcore" de 6 mois !
Est-ce qu'il y a un bénéfice caché qu'ils n'ont pas mentionné et que je n'arrive pas à voir ?
Un peu comme ces éditeurs qui ont un framework maison : ils l'ont souvent fait avant que des projets matures émergent.