46 liens privés
Tout est dans le titre
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur explique la nécessité de connaître les principes orientés objet et autres bonnes pratiques (clean code, tests, refactoring, etc.)
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur explique en quoi travailler dans du code legacy est surprenamment plus agréable que créer du code "from scratch"... Un point de vue peu commun mais intéressant !
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur donne quelques heuristiques pour choisir les parties du code à refactorer, en fonction de leur valeur business et de leur fréquence de changement
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur insiste sur le fait que le refactoring fait partie du quotidien du développeur : ce n'est pas une tâche de la todo liste mais bien une étape de chaque item de celle-ci (cf le nettoyage en fin de service dans un restaurant) Si le refactoring est plus important, alors nommer le ticket sur ce qui est refactoré et pas seulement "refactoring"
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur explique une manière revisitée de la règle du boy scout - toujours laisser le code sur lequel on a travaillé dans un meilleur état que celui dans lequel on l'a trouvé.
Notamment il donne une procédure d'amélioration continue très intéressante.
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur explique la technique de refactoring d'extraction de méthode : comment faire et surtout dans quel but - diminuer la complexité, masquer les détails d'implémentation (ne pas mélanger les degrés d'abstraction), etc. Il donne aussi quelques recommandations pour ne pas introduire de bugs subtils (manipulation de tableaux, etc.)
Tout est dans le titre
Un exemple de refactoring d'une classe pour appliquer le principe d'inversion de dépendance
L'auteur effectue le refactoring d'un test en appliquant plusieurs techniques / idées pour le rendre plus lisible.... très intéressant
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre, sauf que ça concerne PHP - à retenir, l'acronyme RIPP (Rector, Infection, PHPStan, Psalm) qui désigne des outils bien utiles pour le refactoring. L'auteur parle aussi de blackfire
Tout est dans le titre
Le 3e article de la série sur le refactoring : la méthode Mikado ^^
Pour illustrer ce concept, l'auteur montre comment éliminer une dépendance que l'on ne veut plus :
1- commencer par l'éliminer du composer.json
2- lancer les tests et repérer le 1er test qui échoue à cause de la dépendance manquante
3- remettre la dépendance dans le composer.json
4- corriger le fichier du test pour supprimer la dépendance
et recommencer...