Le sujet est très intéressant. Après un gros projet agile dans une grande entreprise avec une équipe de plus de 10 personnes, je réalise que l'action de refactoring a été négligée. Cette situation résulte de la taille du groupe et d'un client changeant. J'ai compris l'importance du refactoring, mais hélas, il est souvent mal perçu. Le facteur humain est crucial, car nous retouchons potentiellement le code écrit par nos collègues, ce qui prend du temps supplémentaire par tâche. Grâce à cette vidéo, j'ai maintenant les outils nécessaires pour mieux gérer cela dans un futur projet. Proposer des modifications progressivement via des PR est judicieux, cela facilite la discussion et l'acceptation par l'équipe. Il est plus efficace de montrer que d'expliquer. Merci Simon.
J’ai lu le livre comme tu l’avais suggéré dans une de tes vidéos précédentes. Et j’avoue que la tu as poussé encore un peu plus loin la compréhension. Merci pour tout ce travail.
Oula merci pour le compliment, c’est le meilleur commentaire que j’ai reçu côté motivation. 👍 Si les vidéos permettent de vulgariser ces livres à la valeur inestimable, c’est vraiment top ! Bon code à vous et à bientôt, Simon
Avec plaisir, je compte sur vous pour nous mettre du vent dans les voiles. Le code SENIOR doit trimpher dans tous les open-space de France et de Navarre.
Bonjour Simon, Alors déjà, merci beaucoup pour tes vidéos qui me font comprendre de nombreux concepts que je ne connaissais pas (je suis en reconversion). Par contre, je ne vois pas les liens 'sous la vidéo' dont tu parles. Oubli ou je ne regarde pas au bon endroit ? Bonne journée !
Ouf 😅. Je pense qu'il y a un cours dans mon université qui s'appelle qualité et métrique du logiciel offert en année 4 spécialement dans le programme de génie logiciel. Je pense que c'est de cela que tu parles. 😅 Est-ce que sur chaque étape on peut mettre en place une stratégie ?
Excellente vidéo mais elle ne répond pas à la question principale qu'on se pose quand on est confronté à cette tâche : on dit "refactorer" ou "refactoriser"?
Plutôt que refactorer du code l'idéal serait de maintenir une structrure cohérente du projet. Par exemple si le code utilise : - pattern MVC pour l'affichage web et c'est souvent le cas car ça permet d'isoler facilement les views du modèle et du controler, exemple struts 1, struts 2, spring MVC en java etc... - singleton pour des choses comme le systèmes de Log du logiciel - observer patter pour monitorer des métriques ... Le plus simple serait déjà de sensibiliser l'équipe sur les patterns qui structure le projet, entrainer les nouveaux arrivants sur ces derniers et vu qu'on parle d'un nombre restreint de pattern il est possible d'écrire des documentations ou simplement des exercices pratiques permettant d'apprendre chaque pattern, concept sous-jacent avec des extensions dans les exemples ou corrélation faisant penser au projet. Pour sensibiliser les membres de l'équipe. Enfin autoriser qu'un certain nombre de pratique : - pattern à utiliser sur le projet - façon de nommer les variables - message pour les PR etc... histoire d'éviter justement la divergence dans la qualité du code avec le temps. Car à la base c'est pas censé se produire je pense. et aussi pour conserver une cohérence sur le projet et permettre a tous de rapidement comprendre le code des autres
Yoo pour une prochaine video ! Est ce que tu pourrais nous expliquer le mixin en TS/JS, les cas d'usage et les limitations ? le multiheritage est compliqué dans ce language, j'ai l'impression que je vais devoir passer sur d'autres languages prenant nativement en compte ce cas de figure (Python, C++ par exemple) plutot que des trouver des alternatives pas toujours tres lisibles
@@codeursenior sans problème. Par ailleurs je voulais te remercier pour ton contenu. Je suis en reconversion et tes vidéos sont très intéressantes même si j'ai conscience certains concept ou méthode sont vu p-e un peu tôt dans mon apprentissage. Force à toi
Le refactoring, on apprend tous ça en Math au Lycée. Bah là, c'est pareil. C'est un truc que je ne peu pas m'empêcher de faire. Mais faut savoir s'arrêter pour ne pas non plus dépasser sur ce qui ne fait pas partie de la feature De mémoire, il vaut mieux refactorer de la couche la plus basse vers la plus haute. Avec les IDEs moderne, le refactoring se fait super facilement que ce soit du renommage ou extraire du code vers une nouvelle fonction
Le code c’est comme une plante. Sa pousse,sa pousse et sa pousse. Si on coupe pas, on ce retrouve avec une jungle. Conclusion : Un peu de jardinage chaque jour sa ne tue pas
Les mesures proposées sont bien légères... et bien trop cowboy, surtout si personne du métier ne passe derrière tester manuellement toutes les non régressions
Masterclass !
Merci !
Merci ! Dans la vidéo tu parles d'un lien en description sur la liste des types de refactoring mais tu as du oublier de l'y mettre 😉
Le sujet est très intéressant. Après un gros projet agile dans une grande entreprise avec une équipe de plus de 10 personnes, je réalise que l'action de refactoring a été négligée. Cette situation résulte de la taille du groupe et d'un client changeant. J'ai compris l'importance du refactoring, mais hélas, il est souvent mal perçu. Le facteur humain est crucial, car nous retouchons potentiellement le code écrit par nos collègues, ce qui prend du temps supplémentaire par tâche. Grâce à cette vidéo, j'ai maintenant les outils nécessaires pour mieux gérer cela dans un futur projet. Proposer des modifications progressivement via des PR est judicieux, cela facilite la discussion et l'acceptation par l'équipe. Il est plus efficace de montrer que d'expliquer.
Merci Simon.
J’ai lu le livre comme tu l’avais suggéré dans une de tes vidéos précédentes. Et j’avoue que la tu as poussé encore un peu plus loin la compréhension. Merci pour tout ce travail.
Oula merci pour le compliment, c’est le meilleur commentaire que j’ai reçu côté motivation. 👍 Si les vidéos permettent de vulgariser ces livres à la valeur inestimable, c’est vraiment top !
Bon code à vous et à bientôt,
Simon
Hello pinnin, tu parles du livre de Martin Fowler ?
@@simonduflot8690 Hello, le livre en question doit "Refactoring" de Martin Fowler. Il n'y en a qu'un, vous ne pouvez pas vous tromper.
je découvre la chaine et en tant qu'étudiant qui code depuis quelques années les vidéos sont des pépites.
Merci beaucoup Simon
Génial. Finalement j'applique çà depuis, en l'ayant appris par la souffrance et l'expérience.
Pareil, je découvre toujours les principes trop tard... après le cassage de dents initial. L'avantage est que c'est formateur. Bon code, Simon.
Très interessant ! J'avoue que ça m'intéresserait de voir plus de contenu sur le refactoring
Merci bcp Simon pour tes merveilleux conseils
vivement une vidéo entière avec angular 17 merci bien pour tout le travail
Toujours au top.
Je soutiens la chaîne :)
Avec plaisir, je compte sur vous pour nous mettre du vent dans les voiles. Le code SENIOR doit trimpher dans tous les open-space de France et de Navarre.
Très utile, merci et bravo !
C'est exactement ça, tout est dit !
Merci Simon ! 👍
Super ta vidéo, merci pour la ref du bouquin !
Toujours top, merci bien.
Super video merci, je suis preneur pour une vidéo plus poussée sur le refactoting !
Tellement pertinent ! à quand les podcasts pour multiplier les possibilités d'écoute ?
Merci :)
Très intéressant, un autre vidéo sur le sujet m'intéresserai 👍
Merci ta chaîne est précieuse 👌
Ton commentaire aussi ! Bon code et à bientôt, Simon.
Super contenus, mercii
Tres intéressant, merci
super , on va pouvoir montrer ça a tous nos clients :D
Super contenus. Plus de contenu 🎉
Tes videos sont toujours autant de grande qualité !! et tes Miniatures Uniques ! 🤣
100% d'accord.
Pareil.
Merci
Super vidéo…
Incroyable ta chaîne, c'est un hack, j'ai l'impression de progresser vite pour un junior dev!
Bonjour Simon,
Alors déjà, merci beaucoup pour tes vidéos qui me font comprendre de nombreux concepts que je ne connaissais pas (je suis en reconversion).
Par contre, je ne vois pas les liens 'sous la vidéo' dont tu parles. Oubli ou je ne regarde pas au bon endroit ?
Bonne journée !
super
Ouf 😅. Je pense qu'il y a un cours dans mon université qui s'appelle qualité et métrique du logiciel offert en année 4 spécialement dans le programme de génie logiciel. Je pense que c'est de cela que tu parles. 😅
Est-ce que sur chaque étape on peut mettre en place une stratégie ?
Excellente vidéo mais elle ne répond pas à la question principale qu'on se pose quand on est confronté à cette tâche : on dit "refactorer" ou "refactoriser"?
Très bonne question. À force de lire des ressources an anglais, j'utilise "refactoriser". Mais les deux semblent parfaitement valides.
Comment peut-on te contacter ?
500e par jour c'est en freelance ??
Tu ne parles de commentaires dans ton code. Utilises-tu jsdoc ?
l'avantage avec tes vidéos c'est que c'est pas spécifique ni à Angular ni même au font-end. merci
Plutôt que refactorer du code l'idéal serait de maintenir une structrure cohérente du projet. Par exemple si le code utilise :
- pattern MVC pour l'affichage web et c'est souvent le cas car ça permet d'isoler facilement les views du modèle et du controler, exemple struts 1, struts 2, spring MVC en java etc...
- singleton pour des choses comme le systèmes de Log du logiciel
- observer patter pour monitorer des métriques
...
Le plus simple serait déjà de sensibiliser l'équipe sur les patterns qui structure le projet, entrainer les nouveaux arrivants sur ces derniers et vu qu'on parle d'un nombre restreint de pattern il est possible d'écrire des documentations ou simplement des exercices pratiques permettant d'apprendre chaque pattern, concept sous-jacent avec des extensions dans les exemples ou corrélation faisant penser au projet. Pour sensibiliser les membres de l'équipe.
Enfin autoriser qu'un certain nombre de pratique :
- pattern à utiliser sur le projet
- façon de nommer les variables
- message pour les PR
etc... histoire d'éviter justement la divergence dans la qualité du code avec le temps. Car à la base c'est pas censé se produire je pense. et aussi pour conserver une cohérence sur le projet et permettre a tous de rapidement comprendre le code des autres
Yoo pour une prochaine video ! Est ce que tu pourrais nous expliquer le mixin en TS/JS, les cas d'usage et les limitations ?
le multiheritage est compliqué dans ce language, j'ai l'impression que je vais devoir passer sur d'autres languages prenant nativement en compte ce cas de figure (Python, C++ par exemple) plutot que des trouver des alternatives pas toujours tres lisibles
Faute sur le titre de ta miniature chef !
Et hop, corrigé !
Merci pour le retour rapide (immédiat ?) et bon code à toi !
Simon.
@@codeursenior sans problème. Par ailleurs je voulais te remercier pour ton contenu. Je suis en reconversion et tes vidéos sont très intéressantes même si j'ai conscience certains concept ou méthode sont vu p-e un peu tôt dans mon apprentissage.
Force à toi
@@b1899-k2v Merci pour ton feedback sur les vidéos. Force à toi aussi pour ton projet ! 💪
Le refactoring, on apprend tous ça en Math au Lycée. Bah là, c'est pareil.
C'est un truc que je ne peu pas m'empêcher de faire. Mais faut savoir s'arrêter pour ne pas non plus dépasser sur ce qui ne fait pas partie de la feature
De mémoire, il vaut mieux refactorer de la couche la plus basse vers la plus haute.
Avec les IDEs moderne, le refactoring se fait super facilement que ce soit du renommage ou extraire du code vers une nouvelle fonction
J'aime pas ranger ma chambre mais j'aime ranger mon code.
Le code c’est comme une plante. Sa pousse,sa pousse et sa pousse.
Si on coupe pas, on ce retrouve avec une jungle. Conclusion : Un peu de jardinage chaque jour sa ne tue pas
Les mesures proposées sont bien légères... et bien trop cowboy, surtout si personne du métier ne passe derrière tester manuellement toutes les non régressions