Les Arbres Syntaxiques Abstraits (AST) sont essentiels pour les développeurs, servant de base à des outils comme les compilateurs et les linters. Ils transforment le code source en une structure arborescente, facilitant l'analyse et la manipulation du code. Par exemple, un AST peut clarifier les priorités d'opération dans une expression arithmétique. Le processus de parsing, incluant l'analyse lexicale et syntaxique, convertit le code en AST, permettant des applications variées comme le linting, la transpilation et le refactoring automatique. Des outils comme AST Explorer aident à visualiser et comprendre ces structures, rendant les AST indispensables pour l'analyse et la transformation du code.
L'article décrit une refonte pratique en C# pour transformer des modèles anémiques en modèles riches en comportement, en utilisant les principes du Domain-Driven Design. Il montre comment déplacer la logique métier des services vers les agrégats, améliorant ainsi la maintenabilité et la clarté du code. L'auteur illustre chaque étape avec des exemples de code avant et après la refonte, soulignant les avantages de cette approche.
Un très bon résumé
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