↓Aller au contenu
  1. Tags/

#Php

32 articles avec ce tag.

Sécurité & Performance Authentification et sessions sécurisées Une authentification sécurisée repose sur trois piliers : ne jamais stocker un mot de passe en clair ni avec un hachage faible, protéger le cycle de vie de la session (création, régénération, expiration), et verrouiller les cookies avec les bons attributs. Un seul maillon faible suffit à compromettre un compte. Avancé · 6 min Sécurité & Performance CSRF expliqué simplement Le CSRF (Cross-Site Request Forgery) exploite le fait que le navigateur envoie automatiquement les cookies de session avec chaque requête, même déclenchée depuis un site tiers. Résultat : un site malveillant peut faire exécuter une action à un utilisateur authentifié, sans qu'il s'en rende compte. Intermédiaire · 6 min Sécurité & Performance L'injection SQL expliquée simplement L'injection SQL survient quand une entrée utilisateur est intégrée directement dans une requête SQL au lieu d'être traitée comme une simple donnée. Résultat : un attaquant peut lire, modifier ou supprimer des données qu'il ne devrait jamais pouvoir toucher. Débutant · 5 min Sécurité & Performance Optimiser les performances PHP La majorité des lenteurs d'une application PHP viennent de quelques causes récurrentes : OPcache mal configuré, requêtes N+1 invisibles derrière un ORM, ou optimisation menée sans mesure préalable. Profiler avant d'optimiser évite de perdre du temps sur un problème qui n'existe pas. Intermédiaire · 6 min Sécurité & Performance PHP 8.1 : ce qui change vraiment PHP 8.1 a introduit plusieurs fonctionnalités qui changent réellement la façon d'écrire du code robuste : les enums, les propriétés en lecture seule, les fibers, le type never, la syntaxe de callable de première classe, et les types d'intersection. Intermédiaire · 6 min Sécurité & Performance XSS (Cross-Site Scripting) expliqué simplement Le Cross-Site Scripting (XSS) permet à un attaquant d'injecter du JavaScript malveillant dans une page, exécuté ensuite dans le navigateur d'autres utilisateurs. Contrairement à l'injection SQL qui cible le serveur, le XSS cible directement les visiteurs du site. Intermédiaire · 5 min Architecture logicielle Architecture hexagonale L'architecture hexagonale (Ports & Adapters) place le métier au centre et le connecte au monde extérieur via des ports — des interfaces définies par le métier — implémentés par des adaptateurs interchangeables. La base de données, l'API REST ou la CLI ne sont que des détails branchés sur ces ports. Intermédiaire · 6 min Tests BDD avec Gherkin Le BDD (Behavior-Driven Development) décrit le comportement attendu d'un système en langage naturel structuré, via la syntaxe Gherkin (Given/When/Then), pour que développeurs, testeurs et experts métier partagent une seule source de vérité, exécutable comme un test. Intermédiaire · 6 min Clean Code Bien nommer ses variables et fonctions Un nom de variable ou de fonction porte une information : pourquoi ça existe, ce que ça fait, comment s'en servir. Un mauvais nom oblige le lecteur à ouvrir le code pour comprendre ce qu'un bon nom lui aurait dit directement. Débutant · 4 min Bases de données Cache Redis Redis est une base clé-valeur en mémoire, utilisée principalement comme cache devant une base relationnelle. Le pattern cache-aside, un TTL bien choisi et une stratégie d'invalidation claire sont les trois piliers d'un cache Redis fiable. Intermédiaire · 5 min Architecture logicielle Clean Architecture expliquée simplement La Clean Architecture organise le code en cercles concentriques : le métier au centre, les détails techniques (base de données, framework, UI) à l'extérieur. La règle est simple — les dépendances ne pointent jamais vers l'extérieur. Avancé · 5 min Architecture logicielle Couplage fort vs faible Le couplage mesure à quel point un composant dépend d'un autre. Un couplage fort rend le système fragile et difficile à faire évoluer ; un couplage faible, obtenu via des interfaces et l'injection de dépendance, permet de changer une implémentation sans toucher au code qui l'utilise. Débutant · 5 min Architecture logicielle Domain Driven Design (DDD) Le Domain Driven Design (DDD) est autant une démarche de modélisation métier qu'une technique de code. Il propose un vocabulaire partagé avec les experts métier, des frontières explicites entre sous-domaines (bounded context), et des règles précises pour modéliser entités, value objects et agrégats. Avancé · 6 min Clean Code Écrire des fonctions courtes et lisibles Une fonction longue n'est pas un problème de longueur : c'est un symptôme qu'elle mélange plusieurs intentions à des niveaux d'abstraction différents. La découper par intention rend le scénario principal lisible comme un sommaire. Intermédiaire · 4 min Clean Code Gérer proprement les exceptions Une exception bien gérée porte un nom qui dit ce qui s'est passé, ne disparaît jamais silencieusement dans un catch vide, et se traduit en réponse utilisateur à un seul endroit — pas dans chaque contrôleur. Intermédiaire · 4 min Design Patterns Le Pattern Abstract Factory expliqué simplement L'Abstract Factory va plus loin que la Factory simple : elle garantit qu'un ensemble d'objets liés entre eux (une famille) reste toujours cohérent, en regroupant plusieurs méthodes de création derrière une seule interface. Avancé · 5 min Design Patterns Le Pattern Adapter expliqué simplement Le Adapter Pattern permet à deux interfaces incompatibles de fonctionner ensemble, sans modifier ni l'une ni l'autre. Il s'intercale entre le code appelant et une librairie tierce pour traduire les appels d'un contrat vers un autre. Débutant · 5 min Design Patterns Le Pattern Builder expliqué simplement Le Builder Pattern sépare la construction d'un objet complexe en une série d'étapes chaînées, chacune configurant une partie de l'objet. Il évite les constructeurs à rallonge et rend le code de construction lisible, même avec de nombreux paramètres optionnels. Intermédiaire · 5 min Design Patterns Le Pattern Decorator expliqué simplement Le Decorator Pattern permet d'ajouter dynamiquement des responsabilités à un objet, en l'enveloppant dans une ou plusieurs couches qui respectent la même interface. Une alternative à l'héritage quand les combinaisons de comportements se multiplient. Intermédiaire · 5 min Design Patterns Le Pattern Dependency Injection expliqué simplement L'injection de dépendances (Dependency Injection) consiste à fournir à un objet ce dont il a besoin depuis l'extérieur, plutôt que de le laisser construire lui-même ses dépendances. Un principe simple qui rend le code testable et remplaçable. Intermédiaire · 6 min Design Patterns Le Pattern Factory expliqué simplement Le Factory Pattern encapsule la logique de création d'un objet dans une méthode ou une classe dédiée, plutôt que de disperser des `new` conditionnels dans tout le code. Le client dépend d'une interface, jamais des classes concrètes créées derrière. Intermédiaire · 4 min Design Patterns Le Pattern Observer expliqué simplement L'Observer Pattern définit une relation un-à-plusieurs : quand un objet change d'état, tous ses abonnés sont notifiés automatiquement, sans que l'émetteur ait besoin de connaître leur nature exacte. C'est le pattern derrière les event listeners et les systèmes pub/sub. Intermédiaire · 5 min Design Patterns Le Pattern Repository expliqué simplement Le Repository Pattern cache les détails de stockage (SQL, ORM, API externe) derrière une interface orientée métier. Le domaine manipule des objets, pas des requêtes — l'implémentation concrète du stockage reste un détail interchangeable. Intermédiaire · 6 min Design Patterns Le Pattern Singleton expliqué simplement Le Singleton garantit qu'une classe n'a qu'une seule instance, accessible depuis n'importe où dans l'application. Pratique en apparence, mais c'est aussi l'un des patterns les plus critiqués : il introduit un état global qui rend le code difficile à tester et à faire évoluer. Débutant · 4 min Design Patterns Le Pattern Strategy expliqué simplement Le Strategy Pattern permet de faire varier un comportement indépendamment du code qui l'utilise. Au lieu d'empiler des `if/else`, on encapsule chaque variante dans sa propre classe, interchangeable à tout moment. Intermédiaire · 4 min Tests Mock vs Stub Un stub et un mock remplacent tous deux une vraie dépendance dans un test, mais pour des raisons différentes : le stub fournit des données prêtes à l'emploi, le mock vérifie que le code testé a bien effectué certains appels. Intermédiaire · 5 min Tests Pourquoi écrire des tests ? Écrire des tests coûte du temps immédiat, mais ce temps est un investissement : les tests deviennent un filet de sécurité contre les régressions et une documentation toujours à jour du comportement réel du code. Débutant · 4 min Tests Pyramide des tests La pyramide des tests décrit une répartition saine de l'effort de test : de nombreux tests unitaires rapides à la base, un nombre plus restreint de tests d'intégration au milieu, et très peu de tests end-to-end, lents mais réalistes, au sommet. Débutant · 5 min Architecture logicielle Séparation des responsabilités Séparer les responsabilités, ce n'est pas seulement écrire des petites classes : c'est isoler chaque raison de changer dans sa propre unité, que ce soit une classe, un module ou une couche entière du système. Bien fait, un changement métier ne touche qu'un seul endroit du code. Débutant · 5 min Architecture logicielle SOLID expliqué simplement SOLID est un acronyme regroupant cinq principes de conception orientée objet formulés par Robert C. Martin : Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation et Dependency Inversion. Ensemble, ils visent un seul objectif : pouvoir faire évoluer le code sans le casser. Intermédiaire · 6 min Tests TDD expliqué simplement Le TDD (Test-Driven Development) consiste à écrire un test qui échoue avant d'écrire le code qui le fait passer, puis à améliorer la structure une fois le comportement validé. Ce cycle court — Red, Green, Refactor — guide la conception au lieu de la vérifier après coup. Intermédiaire · 5 min Tests Test unitaire vs intégration Un test unitaire vérifie une seule unité de code en isolation, en général en mockant ses dépendances. Un test d'intégration vérifie que plusieurs composants réels — base de données, API, autres classes — collaborent correctement ensemble. Intermédiaire · 5 min