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.
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
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
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"?
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
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
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 ?
@@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
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 !
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
