L’auteur explique comment les arguments booléens positionnels dans les appels de fonctions rendent le code difficile à lire et à comprendre. Il illustre ce problème avec des exemples comme createUser(user, true, false) où il est impossible de savoir ce que signifient les booléens sans consulter la définition de la fonction. Cette pratique, bien que pratique à écrire, force les développeurs à "décoder" plutôt qu'à lire le code, ce qui ralentit la compréhension.
Pour résoudre ce problème, l’auteur recommande d'utiliser des objets nommés à la place des booléens positionnels, comme createUser(user, { isAdmin: true, sendWelcomeEmail: false }), ce qui rend l'appel de fonction immédiatement compréhensible. Il suggère également de remplacer les booléens par des noms de fonctions plus explicites, comme createAdminUser(user) au lieu de createUser(user, true), lorsque cela est pertinent.
Enfin, l’auteur reconnaît que cette approche n'est pas toujours nécessaire pour des cas simples comme toggleMenu(true), mais devient indispensable dès qu'il y a plusieurs booléens ou que la signification n'est pas évidente. Il conclut que cette pratique améliore significativement la lisibilité du code, surtout dans des projets complexes où la maintenance et la compréhension sont cruciales.
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 partage Shaarli présente le "DDD Symfony Bundle", un outil pour intégrer le Domain-Driven Design (DDD) dans Symfony. Ce bundle offre un noyau (Kernel) prêt pour le DDD, permettant une importation automatique des configurations des différents contextes délimités (Bounded Contexts), et une intégration avec Symfony Messenger pour gérer les commandes et les requêtes via des bus dédiés. Il facilite ainsi l'autonomie des contextes délimités et maintient une architecture propre et évolutive. Le bundle est disponible sur GitHub et peut être installé via Composer.
Nicolas Jourdan explique comment combiner trois patterns de conception (Specification, Rule et Chain of Responsibility) pour gérer efficacement les règles métier complexes en PHP. L'article détaille d'abord le pattern Specification, qui transforme les conditions métier en objets réutilisables et testables, évitant ainsi les if imbriqués et le code dupliqué. Il présente ensuite une implémentation moderne de ce pattern avec une interface de base et des classes pour les opérations logiques (AND, OR, NOT). Cette approche permet de construire des conditions métier claires et modulaires, facilitant ainsi la maintenance et l'extensibilité du code.
Cet article présente une sélection de neuf livres essentiels pour tout ingénieur logiciel. La liste inclut des ouvrages classiques comme "Clean Code" et "The Pragmatic Programmer", ainsi que des titres plus spécialisés comme "Software Engineering at Google" et "Designing Distributed Systems". Chaque livre est brièvement décrit, mettant en avant ses points forts et son public cible. L'article souligne l'importance de la lecture pour améliorer ses compétences en développement logiciel et offre une ressource précieuse pour les professionnels à tous les niveaux.
Une adaptation des concepts du Clean Code en PHP
Tout est dans le titre
Tout est dans le titre
Pour résumer, le principe de dépendance stable (SDP) déclare que les composants d'une application doivent toujours dépendre de composants plus stables qu'eux.
Des exemples (parfois discutables) en JavaScript de pratiques du clean code
... en utilisant un value object regroupant les paramètres entre eux
L'auteur explique comment rendre plus lisible des conditions booléennes
L'auteur montre l'utilisation des Callback Lifecycle de Doctrine, des Entity Listeners et des Lifecycle Listeners - il précise notamment les bons cas d'usage (et montre comment rester découplé même en utilisant les callback lifecyle)
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 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 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.
L'auteur met l'accent sur des bonnes pratiques concernant le code : lisibilité, expressivité, complexité réduite, etc.
L'auteur développe l'idée que le code lisible est infiniment supérieur au code "intelligent". Pour juger de la lisibilité, il se demande si un junior pourrait comprendre le code sans souci...