L’article de Marcos F. Lobo identifie quatre signes révélateurs d’un mauvais design logiciel et propose des solutions pour y remédier. Parmi ces symptômes, la rigidité, qui se manifeste par un système difficile à modifier sans déclencher des réactions en chaîne, est souvent causée par un couplage excessif entre les modules. L’auteur illustre ce problème avec un exemple concret où une classe monolithique gère les frais de livraison via des instructions conditionnelles, rendant toute modification complexe et coûteuse.
Un autre problème abordé est la fragilité du code, où une modification dans un module peut entraîner des dysfonctionnements imprévus dans d’autres parties du système. Cette situation résulte généralement de dépendances cachées ou d’une logique trop interconnectée, comme l’utilisation de variables globales ou de singletons partagés entre modules. La solution proposée repose sur l’encapsulation et la séparation des interfaces pour limiter l’impact des changements.
Enfin, l’immobilité désigne l’incapacité à réutiliser des composants logiciels dans d’autres projets ou contextes, en raison d’un design trop lié à son environnement. L’auteur souligne que cette rigidité empêche une extraction efficace des fonctionnalités, souvent parce que le code mêle règles métier et détails d’implémentation.
Cet article de JoliCode présente une méthodologie pour migrer vers Tailwind CSS v4, en détaillant une approche progressive et peu douloureuse. L’idée principale est de remplacer les anciennes solutions CSS basées sur Sass (comme Bootstrap v4 ou des frameworks maison) par des technologies plus modernes, en s’appuyant sur le CSS natif et les fonctionnalités de Tailwind v4, qui ne nécessite plus de dépendances comme Sass. La migration se fait en deux phases clés, la première consistant à convertir les variables et fonctions Sass en variables CSS natives et en syntaxes modernes.
La première phase se concentre sur la migration des feuilles de styles CSS, notamment en remplaçant les variables Sass par des custom properties (variables CSS) définies dans :root. Par exemple, $color-primary: [#f7d325](https://raphael.salique.fr/liens/./add-tag/f7d325); devient --color-primary: [#f7d325](https://raphael.salique.fr/liens/./add-tag/f7d325);. L’article souligne l’importance d’adopter dès cette étape la nomenclature de Tailwind CSS v4 pour faciliter la transition. Les fonctions Sass comme darken() ou les calculs mathématiques (math.div()) sont remplacées par des équivalents natifs, comme hsl(from var(--color-primary) h s calc(l - 15)) pour les manipulations de couleurs.
Enfin, l’article aborde un piège courant : l’imbrication des sélecteurs (& en Sass) et les conventions comme BEM. Il met en garde contre les sélecteurs trop imbriqués, qui compliquent la migration, et recommande de simplifier la structure CSS pour éviter les conflits. L’objectif est de rendre le code plus maintenable et compatible avec les standards modernes, tout en préparant le terrain pour une adoption plus large de Tailwind CSS v4.
L’article explique la migration d’un outil de génération de PDF, wkhtmltopdf, vers Gotenberg dans une application Symfony legacy, en évitant de perturber les endpoints existants. L’idée principale est de découpler la génération de PDF du conteneur API pour améliorer les performances et la maintenabilité, car wkhtmltopdf consommait trop de ressources CPU et reposait sur des dépendances locales (fichiers, polices, images). Le processus a nécessité de refactoriser l’architecture pour externaliser le rendu HTML vers un conteneur dédié, tout en gérant les différences de rendu entre les moteurs (problèmes de polices, de mise en page ou de chemins d’accès).
La migration a révélé des défis techniques, comme la gestion des chemins de fichiers (remplacement des références locales par des URLs accessibles) et les écarts de rendu entre wkhtmltopdf et Chromium (Gotenberg), entraînant des modifications de mise en page inattendues. L’approche adoptée a consisté à migrer progressivement, type de document par type de document, pour limiter les risques et permettre des ajustements fins. L’objectif était de préserver la compatibilité des endpoints tout en améliorant l’infrastructure.
L'article explique le Decorator Pattern en PHP, une solution élégante pour ajouter des comportements à un objet sans modifier son code existant. L'auteur illustre les problèmes des classes "Dieu" (trop de responsabilités) et de l'héritage multiple avec des exemples concrets comme un système de logging. Le pattern permet de wrappper dynamiquement un objet (ex: FileLogger) dans des décorateurs (ex: DatabaseLogger, SlackLogger) pour étendre ses fonctionnalités, tout en gardant le code modulaire, testable et ouvert à l'extension. Une alternative propre aux cascades de sous-classes et aux couplages forts.
Ce catalogue en ligne de refactorings, créé par Martin Fowler, accompagne son livre "Refactoring 2nd Edition". Il répertorie diverses techniques de refactoring, classées par tags, pour améliorer la structure et la lisibilité du code. Parmi les refactorings listés, on trouve des actions comme "Extract Method", "Inline Variable", "Replace Conditional with Polymorphism", et bien d'autres, chacune visant à optimiser et clarifier le code. Une ressource précieuse pour les développeurs cherchant à améliorer leurs compétences en refactoring.
Ce billet de blog explique le processus de refactoring de chaînes de caractères en énumérations (enums) dans le code de l'outil d'analyse statique Exakat. Initialement, les chaînes étaient utilisées partout, mais avec l'évolution de PHP, les enums offrent des avantages comme une meilleure typage, une structure dédiée et une analyse plus facile. Bien que les gains de performance ne soient pas significatifs, le passage aux enums simplifie l'analyse statique et améliore la précision. L'article détaille le choix des noms d'atomes comme candidats idéaux pour ce refactoring, en conservant la convention de nommage existante.
L’article présente une sélection d’essais influents qui ont marqué la pensée et les pratiques de l’auteur en tant qu’ingénieur logiciel. Parmi les textes cités, on retrouve des classiques comme « Choose Boring Technology » de Dan McKinley, qui prône l’utilisation de technologies éprouvées pour éviter les risques inutiles, « Parse, Don’t Validate » d’Alexis King, qui encourage à transformer les données en types riches pour éliminer les états invalides, ou « Things You Should Never Do, Part I » de Joel Spolsky, mettant en garde contre les réécritures complètes de code. D’autres essais, comme « The Majestic Monolith » de DHH ou « The Rise of ‘Worse is Better’ » de Richard P. Gabriel, remettent en question les tendances architecturales (microservices, perfectionnisme) au profit de solutions pragmatiques et adaptées au contexte. L’auteur souligne aussi l’importance de la qualité (« Software Quality at Top Speed » de Steve McConnell) et de la valeur métier (« Don’t Call Yourself a Programmer » de Patrick McKenzie). Enfin, des conseils plus larges, comme « How To Become a Better Programmer by Not Programming » de Jeff Atwood, rappellent que les compétences techniques ne suffisent pas : comprendre le domaine, communiquer et éviter la complexité inutile sont tout aussi cruciaux. Une lecture inspirante pour repenser sa pratique du développement.
Suite de https://css-tricks.com/a-better-api-for-the-resize-observer/ , l'article propose une refonte des API pour MutationObserver et IntersectionObserver afin de les rendre plus simples à utiliser. L'auteur montre comment simplifier l'utilisation de ces observateurs en utilisant des motifs de rappel et d'écouteurs d'événements. Pour MutationObserver, il explique comment observer les mutations du DOM et se déconnecter proprement en utilisant une méthode disconnect. Concernant IntersectionObserver, il détaille comment observer les changements d'intersection d'un élément avec un ancêtre ou une fenêtre de visualisation. Enfin, l'article mentionne une bibliothèque pratique, Splendid Labz, qui offre des utilitaires pour ces observateurs, facilitant leur intégration dans des projets web.
L'article propose une amélioration de l'API pour le ResizeObserver, un outil JavaScript utilisé pour observer les changements de taille des éléments DOM. L'auteur suggère d'encapsuler la logique du ResizeObserver dans une fonction plus simple et réutilisable, ce qui rend son utilisation plus intuitive et proche des modèles d'écouteurs d'événements familiers. En passant un élément et une fonction de rappel à cette fonction personnalisée, les développeurs peuvent facilement réagir aux changements de taille sans avoir à réécrire le code standard du ResizeObserver à chaque fois. De plus, l'article montre comment intégrer des options supplémentaires et gérer l'arrêt de l'observation, offrant ainsi une solution plus flexible et maintenable. Enfin, il mentionne une bibliothèque appelée Splendid Labz qui offre une version améliorée de cet observateur, capable de gérer plusieurs éléments simultanément.
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.)