Tout est dans le titre

Tout est dans le titre

Tout est dans le titre

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 donne plusieurs règles de son équipe, qui doivent être respectées dans le code (utilisation d'exceptions, DTO, etc.) Elles méritent d'être connues

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 !

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 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.

Tout est dans le titre

Tout est dans le titre

Tout est dans le titre

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.)

Une astuce en attendant une meilleure intégration

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"

Un bundle Symfony pour faciliter l'intégration de Keycloak

L'article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur présente 3 exemples d'arbitrage qu'il a du faire pour résoudre des problèmes : cette nécessité de choisir est constante dans le développement, et il donne quelques bons conseils à ce sujet.

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 explique pourquoi il faut se débarrasser des appels statiques (classes difficilement testables unitairement) et comment faire (injection de dépendances)