Je peux comprendre qu'il faille maximiser l'efficaciter du travail, mais je trouve que ajouter autant de rigidité dans les porjets peux etre extremement stressant pour les nouveaux qui l'integre et pour les developpeurs moins expérimenté, a force de vouloir maximiser les couts, ce métier devient désagréable ..Je pense qu'il faut trouver un juste millieu et amener une gestion éfficace petit a petit...Aujourd'hui apres quelques années d'expérience je me rend compte de l'importance de la gestion projet, la gestion des bugs , la programmation modulaire, mais faut que les dev senior se rende compte que cela est une étape que tous developpeur ont rencontré un jour.: Avant de se concentrer sur l'améliorations et l'optimisation du devellopement logiciel et bien faut apprendre a maaitriser les bases ...Malheureusement ils sont passé par la mais l'ont totalement oublié.
Je pense qu'il est possible d'optimiser le workflow de façon à implémenter le traitement des bugs comme les propos Simon, en prenant en compte les forces les faiblesses de chacun afin d'assigner les tâches spécifiques en fonction des compétences pour initier un nouvel élan dans la méthode.. Autrement dit oui je te rejoins, toutes les équipes ne sont pas faites pour prendre en compte cette logique. Mais certaines team peuvent se le permettre , ici simon ne propose pas de baguettes magiques, il apporte réflexion sur l'optimisation en soulevant des points très intéressant avec son regard très personnel.
En vrais les Bug c'est extrêmement rare. Si on par du principe que c'est du as une anomalie du matériel. Insect dans un tube = bug = problème matériel et même encore plus rare car ça n'as rien avoir avec la conception du matériel mais plutôt as une anomalie inattendu lors du processus de fabrication. Inattendu! Sinon on pourrait dire eg. que la gamme des processeur est suivant les bug de gravure. Maintenant qu'on as dis ça. Ce qu'on qualifie de bug aujourd'hui c'est principalement erreurs de conception dans l'architecture de l'application. Ça peut être dû à l'architecte qui as mal évalué les plan de l'appli en ne prenant pas en compte par exemple l'environnement de construction, ou les différents risques, en bâtiment on pourrait parler de l'étude des sol, condition climatiques et/ou intérêt stratégique (attaque par des tiers). Ou par les maçons, la main d'oeuvre qui ne suivent pas les règles de bonne pratique du métier. Utilisation de matériel inapproprié, etc... Bref les développeurs se cache vite derrière un insect pour dire c'est pas notre fautes. Heureusement qu'ils font pas des bâtiments... 😂😂😂 Après tu peux faire la cabane de jardin, le coin barbecue ou des silos pour ogives nucléaires. Malheureusement j'ai peur qu'aujourd'hui encore c'est les mêmes architecte et les mêmes maçons pour les deux type de projet. Le but principal du commentaire est de dire non un bug s'en est pas un. Si déjà on appelle un chat un chat on peu commencer à trouver des solutions. Les bug existe mais c'est rare. T'es là 🎉🎉🎉🎉🎉 Met un pouces si t'as aimé merci
Bonjour, J'adore l'approche du pourquoi autant de fois que nécessaire. Par contre pas facile à mettre en oeuvre dans une équipe je pense à cause du coté humain, faut être habile pour arriver à l'utiliser sans que les gens ne se mettent tout de suite sur la défensive en ayant l'impression de se faire accuser. En tout cas je l'a retiens et j’essaierais de la tester au boulot. Toujours super tes vidéos qui comme tu le dis, représente le monde réel et pas le monde merveilleux des tutos qui marchent du premier coup.
Bonjour simon, j'ai une petite question a te poser a propos d'angular 17 pour savoir si tu as pu déjà faire un tuto dessus. Comment je peux te contacter ?
Hello, je suis entrain d'écrire le workshop pour Angular 18 ! Tu peux aller sur mon site angularsenior.fr et t'inscrire à la newsletter, j'ai déjà ouvert l'accès pour les inscrits à la newsletter.
Merci beaucoup. Euh pouvez vous me dire ou citer le pluging le plus utilisées pour test que je peux installer sur mon éditeur vscode ou autre et c'est quoi factoring de code
Le problème que j'ai avec le TDD, c'est que: - Le coût du projet devient assez vite honéreux - Ecrire des test c'est pas le plus exitant - Avoir une équipe capable d'implémenter le CI/CD sinon je considère que c'est du temps perdu Merci pour ton transfère de savoir, toujorus un plaisir Dev web laravel & React depuis 2 ans Peace !
Je te conseille de te renseigner sur Jenkins. En 1 week end tu mets en place CI/CD sur tes projets perso avec Docker, et ta config elle est presque entièrement documentée et versionnée dans ton repo. TDD, ça ne prend pas plus de temps, c'est juste une façon différente de travailler. Si tu prends plus de temps c'est parce que tu en es encore au stade où tu dois te retourner le cerveau, et c'est normal, ou alors c'est parce que tu travailles sur une codebase toute couplée (et c'est bien possible, je ne vois que ça dernièrement). Mais je t'assure que si tu as compris que tu devais écrire des tests et que tu les écris avant, déjà tu as beaucoup moins de risques d'en oublier ;) et en suite tu te rendras compte que c'est pas très différent de travailler dans un REPL ou avec un débugueur. J'ai coutume de dire que les tests automatisés il ne faut pas les comparer à pas de tests du tout, mais à des tests manuels. C'est ça qui prend du temps, tu ne t'en rends juste pas compte parce que c'est pas du temps que tu passes à taper sur ton clavier. Et puis les tests automatisés, ce sont des tests que tu gardes, alors que les tests manuels tu les écris aussi, mais sans les garder, et tu les réécris à chaque régression.
J'aime vraiment vos vidéos et ça m'aide beaucoup. Si aussi vous pourriez nous faire une playlist sur la sécurité des applications web😢 ça serait encore géniale
@@codeursenior Extreme Programming Explained et Planning Extreme Programming ce sont des livres de gestion de projet et de ressources humaines. Ce n'est pas parce que Kent Beck est associé (à raison) au TDD, à l'architecture xUnit et à l'intégration continue que XP est plus orienté sur l'aspect technique. C'est dans XP explained que j'ai entendu parler pour la première fois de Software as a Service. Les pratiques de développement de l'agilité elles rendent les pratiques de gestion de projet possibles. Sans elles, on ne pratique pas l'agilité, on gesticule en faisant des phrases compliquées pour impressionner le client. Il n'a jamais été question de travailler plus ou de faire moins de réunions. Où tu as lu un truc pareil ? C'est une pratique qui met un point d'honneur à adapter le scope et éviter le gaspillage de travail (c'est même dans le nom) et qui promeut la discussion, le pair programming, qui propose d'intégrer l'utilisateur à l'équipe, etc. XP *c'est* de l'agilité, Martin Fowler et Kent Beck is ont signé le manifest comme tout le monde. L'agilité n'a pas "gagné", remplacé XP, elle a simplement plusieurs visages. Ce n'est pas parce que Scrum en a fait une secte avec une bible, des masters, des ceremonies et des formations qui coûtent un bras que c'est un successeur. C'est simplement une branche de l'agilité qui se vend mieux et qui a plus d'opinions sur la main avec laquelle tu dois t'essuyer ;) Il y a une semaine ou deux je parlais au directeur de clientèle d'une boîte de développement et il se plaignait que l'agilité c'était valider des tickets, qu'on anticipait pas les recettes, qu'il n'y avait pas de spec, etc. j'étais dégoûté d'entendre ça. J'ai parlé un peu de BDD, on m'a dévisagé avec intérêt, comme si c'était nouveau. J'ai parlé de tests automatisés, on n'a dit que ce n'était pas possible, que ça prenait trop de temps. Le monde à l'envers. Et je les aime bien dans cette boîte. Ce que je veux faire passer c'est à quel point notre industrie est ignorante de ce que c'est l'agilité, de son histoire, de ce à quoi ça sert vraiment.
Je peux comprendre qu'il faille maximiser l'efficaciter du travail, mais je trouve que ajouter autant de rigidité dans les porjets peux etre extremement stressant pour les nouveaux qui l'integre et pour les developpeurs moins expérimenté, a force de vouloir maximiser les couts, ce métier devient désagréable ..Je pense qu'il faut trouver un juste millieu et amener une gestion éfficace petit a petit...Aujourd'hui apres quelques années d'expérience je me rend compte de l'importance de la gestion projet, la gestion des bugs , la programmation modulaire, mais faut que les dev senior se rende compte que cela est une étape que tous developpeur ont rencontré un jour.: Avant de se concentrer sur l'améliorations et l'optimisation du devellopement logiciel et bien faut apprendre a maaitriser les bases ...Malheureusement ils sont passé par la mais l'ont totalement oublié.
Je pense qu'il est possible d'optimiser le workflow de façon à implémenter le traitement des bugs comme les propos Simon, en prenant en compte les forces les faiblesses de chacun afin d'assigner les tâches spécifiques en fonction des compétences pour initier un nouvel élan dans la méthode..
Autrement dit oui je te rejoins, toutes les équipes ne sont pas faites pour prendre en compte cette logique.
Mais certaines team peuvent se le permettre , ici simon ne propose pas de baguettes magiques, il apporte réflexion sur l'optimisation en soulevant des points très intéressant avec son regard très personnel.
En vrais les Bug c'est extrêmement rare. Si on par du principe que c'est du as une anomalie du matériel. Insect dans un tube = bug = problème matériel et même encore plus rare car ça n'as rien avoir avec la conception du matériel mais plutôt as une anomalie inattendu lors du processus de fabrication.
Inattendu! Sinon on pourrait dire eg. que la gamme des processeur est suivant les bug de gravure.
Maintenant qu'on as dis ça. Ce qu'on qualifie de bug aujourd'hui c'est principalement erreurs de conception dans l'architecture de l'application. Ça peut être dû à l'architecte qui as mal évalué les plan de l'appli en ne prenant pas en compte par exemple l'environnement de construction, ou les différents risques, en bâtiment on pourrait parler de l'étude des sol, condition climatiques et/ou intérêt stratégique (attaque par des tiers).
Ou par les maçons, la main d'oeuvre qui ne suivent pas les règles de bonne pratique du métier. Utilisation de matériel inapproprié, etc...
Bref les développeurs se cache vite derrière un insect pour dire c'est pas notre fautes. Heureusement qu'ils font pas des bâtiments... 😂😂😂
Après tu peux faire la cabane de jardin, le coin barbecue ou des silos pour ogives nucléaires. Malheureusement j'ai peur qu'aujourd'hui encore c'est les mêmes architecte et les mêmes maçons pour les deux type de projet.
Le but principal du commentaire est de dire non un bug s'en est pas un. Si déjà on appelle un chat un chat on peu commencer à trouver des solutions.
Les bug existe mais c'est rare.
T'es là 🎉🎉🎉🎉🎉
Met un pouces si t'as aimé merci
Les miniatures sont toujours incroyables 😂
Oui, venant de lui c'est marrant 😂
Merci, c'est ma première passion, avant le code !
L'agilité a gagné, et c'est là tout le drame de ma vie résumée en une phrase :)
Pourquoi c’est le drame de votre vie ? 😂 vous êtes le fondateur de l’eXtrem Programming ?
@@codeursenior Mince, tu m'as demasqué....
@@dimitribalderacchi9655 😂
Bonjour,
J'adore l'approche du pourquoi autant de fois que nécessaire.
Par contre pas facile à mettre en oeuvre dans une équipe je pense à cause du coté humain, faut être habile pour arriver à l'utiliser sans que les gens ne se mettent tout de suite sur la défensive en ayant l'impression de se faire accuser.
En tout cas je l'a retiens et j’essaierais de la tester au boulot.
Toujours super tes vidéos qui comme tu le dis, représente le monde réel et pas le monde merveilleux des tutos qui marchent du premier coup.
Bonjour simon, j'ai une petite question a te poser a propos d'angular 17 pour savoir si tu as pu déjà faire un tuto dessus.
Comment je peux te contacter ?
Hello, je suis entrain d'écrire le workshop pour Angular 18 !
Tu peux aller sur mon site angularsenior.fr et t'inscrire à la newsletter, j'ai déjà ouvert l'accès pour les inscrits à la newsletter.
Merci beaucoup. Euh pouvez vous me dire ou citer le pluging le plus utilisées pour test que je peux installer sur mon éditeur vscode ou autre et c'est quoi factoring de code
Bonjour, je ne suis pas certain d'avoir compris votre question. Que voulez-vous savoir exactement ?
Le problème que j'ai avec le TDD, c'est que:
- Le coût du projet devient assez vite honéreux
- Ecrire des test c'est pas le plus exitant
- Avoir une équipe capable d'implémenter le CI/CD sinon je considère que c'est du temps perdu
Merci pour ton transfère de savoir, toujorus un plaisir
Dev web laravel & React depuis 2 ans
Peace !
Je te conseille de te renseigner sur Jenkins. En 1 week end tu mets en place CI/CD sur tes projets perso avec Docker, et ta config elle est presque entièrement documentée et versionnée dans ton repo.
TDD, ça ne prend pas plus de temps, c'est juste une façon différente de travailler. Si tu prends plus de temps c'est parce que tu en es encore au stade où tu dois te retourner le cerveau, et c'est normal, ou alors c'est parce que tu travailles sur une codebase toute couplée (et c'est bien possible, je ne vois que ça dernièrement). Mais je t'assure que si tu as compris que tu devais écrire des tests et que tu les écris avant, déjà tu as beaucoup moins de risques d'en oublier ;) et en suite tu te rendras compte que c'est pas très différent de travailler dans un REPL ou avec un débugueur. J'ai coutume de dire que les tests automatisés il ne faut pas les comparer à pas de tests du tout, mais à des tests manuels. C'est ça qui prend du temps, tu ne t'en rends juste pas compte parce que c'est pas du temps que tu passes à taper sur ton clavier. Et puis les tests automatisés, ce sont des tests que tu gardes, alors que les tests manuels tu les écris aussi, mais sans les garder, et tu les réécris à chaque régression.
J'aime vraiment vos vidéos et ça m'aide beaucoup. Si aussi vous pourriez nous faire une playlist sur la sécurité des applications web😢 ça serait encore géniale
Hello, vous avez raison cela semble une bonne idée ! J’ai ajouté l’idée à la liste des vidéos à tourner 👍
Bon code,
Simon.
Moi c'est le tajine sur le bureau qui me retient sur cette chaine 😅
Le bon tajine n’est jamais loin !
je trouve ça cool le nouveau setup, bureau derrière ça te rapproche du spectateur !
Au top, merci pour ton retour sur le setup. Je vais rester là dessus les prochains mois 👍
Excellent
Vous avez raison 👍
Encore et toujours merci
💪
1:03 hein ?
Oui ?
@@codeursenior Extreme Programming Explained et Planning Extreme Programming ce sont des livres de gestion de projet et de ressources humaines. Ce n'est pas parce que Kent Beck est associé (à raison) au TDD, à l'architecture xUnit et à l'intégration continue que XP est plus orienté sur l'aspect technique. C'est dans XP explained que j'ai entendu parler pour la première fois de Software as a Service. Les pratiques de développement de l'agilité elles rendent les pratiques de gestion de projet possibles. Sans elles, on ne pratique pas l'agilité, on gesticule en faisant des phrases compliquées pour impressionner le client.
Il n'a jamais été question de travailler plus ou de faire moins de réunions. Où tu as lu un truc pareil ? C'est une pratique qui met un point d'honneur à adapter le scope et éviter le gaspillage de travail (c'est même dans le nom) et qui promeut la discussion, le pair programming, qui propose d'intégrer l'utilisateur à l'équipe, etc.
XP *c'est* de l'agilité, Martin Fowler et Kent Beck is ont signé le manifest comme tout le monde. L'agilité n'a pas "gagné", remplacé XP, elle a simplement plusieurs visages. Ce n'est pas parce que Scrum en a fait une secte avec une bible, des masters, des ceremonies et des formations qui coûtent un bras que c'est un successeur. C'est simplement une branche de l'agilité qui se vend mieux et qui a plus d'opinions sur la main avec laquelle tu dois t'essuyer ;)
Il y a une semaine ou deux je parlais au directeur de clientèle d'une boîte de développement et il se plaignait que l'agilité c'était valider des tickets, qu'on anticipait pas les recettes, qu'il n'y avait pas de spec, etc. j'étais dégoûté d'entendre ça. J'ai parlé un peu de BDD, on m'a dévisagé avec intérêt, comme si c'était nouveau. J'ai parlé de tests automatisés, on n'a dit que ce n'était pas possible, que ça prenait trop de temps. Le monde à l'envers. Et je les aime bien dans cette boîte. Ce que je veux faire passer c'est à quel point notre industrie est ignorante de ce que c'est l'agilité, de son histoire, de ce à quoi ça sert vraiment.
@@codeursenior Ah, je pense que ma réponse a fini dans tes spams
@@ApprendreSansNecessite Probablement malheureusement !