23 - Glossaire — tous les termes de la serie

Ce que tu vas apprendre

Les définitions de tous les termes utilises dans la serie
Des liens vers l'article ou chaque concept est traite en profondeur
Un document de référencé rapide a garder sous la main

Prerequisites

Cette serie compte 23 articles et beaucoup de vocabulaire technique. Ce glossaire rassemble tous les termes au meme endroit. Chaque entree contient une définition courte et un lien vers l'article qui traite le sujet. Tu peux l'utiliser comme référencé rapide quand tu croises un terme que tu ne connais pas ou que tu veux reviser. D'autres ressources sont disponibles sur paltemps.fr.

A

Abstraction

Mecanisme qui cache les détails d'implementation derrière une interface simplifiee. Une fonction est une abstraction : elle cache sa logique interne derrière un nom et des paramètres. Trop d'abstraction rend le code difficile a suivre. Pas assez rend le code duplique et rigide. Voir 11 - Composition vs héritage.

ADR (Architecture Décision Record)

Document court qui capture une décision d'architecture : le contexte, la décision prise et ses consequences. Les ADR vivent dans le repository et sont versiones avec le code. Voir 20 - Conventions et ADR.

As const

Assertion TypeScript qui transforme une valeur en type literal readonly. Permet de créer des types union à partir de tableaux ou d'objets de constantes. Voir 18 - Constantes.

B

Barrel file

Fichier index.ts qui reexporte les symboles publics d'un module. Simplifie les imports pour les consommateurs externes. Peut ralentir le bundler et créer des dépendances circulaires si mal utilise. Voir 17 - Structure projet.

Boy scout rule

Principe qui consiste a laisser le code plus propre que tu ne l'as trouve. Chaque modification est l'occasion d'une petite amelioration : renommer une variable, extraire une constante, simplifier une condition. Voir 13 - Quand refactoriser.

Biome

Outil tout-en-un écrit en Rust qui gere le linting et le formatting pour JavaScript et TypeScript. Alternative rapide a ESLint + Prettier. Voir 19 - Linting.

C

Characterization test

Test écrit pour capturer le comportement actuel d'un code existant, sans juger si ce comportement est correct. Utilise avant un refactoring pour créer un filet de sécurité. Voir 16 - Tests et refactoring.

Clean code

Code dont quelqu'un s'est occupe. Du code lisible, comprehensible et modifiable. Pas du code parfait — du code soigne. Voir 00 - Introduction.

Code smell

Signal dans le code qui indique un problème plus profond. Pas un bug — le code fonctionne — mais un indicateur que quelque chose merite attention. Exemples : fonction trop longue, classe god object, paramètres en exces. Voir 13 - Quand refactoriser.

Cognitive complexity

Mesure de la difficulte a comprendre un morceau de code. Prend en compte l'imbrication, les ruptures de flux lineaire et les structures repetees. Sonar utilise cette metrique plutot que la complexité cyclomatique pour évaluer la lisibilité. Voir 03 - Conditions.

Cohesion

Degre auquel les éléments d'un module sont lies entre eux et travaillent ensemble vers un meme objectif. Un module cohesif fait une seule chose. Un module peu cohesif melange des responsabilités non-liees. Voir 10 - Separation des responsabilités.

Colocation

Principe d'organisation qui place les fichiers lies au meme endroit : tests a cote du code, styles a cote des composants, types a cote de l'implementation. Voir 17 - Structure projet.

Complexite cyclomatique

Nombre de chemins independants dans une fonction. Chaque if, for, while, case ou catch ajoute un chemin. Plus le nombre est eleve, plus la fonction est difficile a tester et comprendre. Voir 03 - Conditions.

Composition

Technique qui construit des objets complexes en combinant des objets plus simples, par opposition a l'héritage. Favorise la flexibilité et le découplage. Voir 11 - Composition vs héritage.

Convention

Regle partagee par une équipe pour standardiser la facon d'écrire du code : nommage, structure, gestion d'erreurs, workflow git. Reduit la charge cognitive et accéléré l'onboarding. Voir 20 - Conventions et ADR.

Couplage

Degre de dépendance entre deux modules. Un couplage fort signifie que modifier un module oblige a modifier l'autre. L'objectif est un couplage faible : les modules interagissent via des interfaces stables. Voir 10 - Separation des responsabilités.

D

Dead code

Code qui n'est jamais exécuté : fonctions non appelees, branches de conditions impossibles, imports inutilises. Le dead code ajoute du bruit et de la confusion. Supprime-le — le contrôle de version te permet de le retrouver si besoin. Voir 14 - Techniques de refactoring.

Dependency Inversion Principle (DIP)

Le D de SOLID. Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d'abstractions. Voir 08 - SOLID.

Dette technique

Raccourci technique pris consciemment qui accéléré la livraison mais impose des "interets" sous forme de complexité accrue. A distinguer du code sale écrit par manque de competence. Voir 21 - Dette technique.

DRY (Don't Repeat Yourself)

Principe qui dit que chaque piece de connaissance doit avoir une representation unique dans le système. Attention : DRY concerne la connaissance, pas le code. Deux blocs de code identiques qui representent des concepts différents ne doivent pas etre fusionnes. Voir 09 - DRY, KISS, YAGNI.

E

Early return

Pattern qui consiste a sortir d'une fonction le plus tot possible quand une condition d'erreur ou un cas special est détecté. Reduit l'imbrication et ameliore la lisibilité. Voir 03 - Conditions.

Effet de bord (side effect)

Modification d'un état extérieur a la fonction : écriture en base, modification d'une variable globale, envoi d'un email, log dans la console. Les effets de bord rendent le code difficile a tester et a raisonner. Voir 05 - Immutabilite.

Extract function

Technique de refactoring qui consiste a prendre un bloc de code et a le deplacer dans une nouvelle fonction nommee. La technique de refactoring la plus frequente. Voir 14 - Techniques de refactoring.

F

Fail fast

Stratégie qui consiste a détecter et signaler les erreurs le plus tot possible, plutot que de laisser l'exécution continuer avec des donnees invalides. Voir 07 - Programmation defensive.

Feature flag

Constante (souvent dynamique) qui permet d'activer ou désactiver une fonctionnalité sans déployer du code. Utile pour les déploiements progressifs et les experimentations A/B. Voir 18 - Constantes.

Fonction pure

Fonction sans effets de bord dont le résultat depend uniquement de ses paramètres. Appeler une fonction pure avec les memes arguments retourne toujours le meme résultat. Facile a tester et a raisonner. Voir 05 - Immutabilite.

G

God object

Objet ou classe qui fait trop de choses et connaît trop de détails sur le reste du système. Anti-pattern classique qui viole le principe de responsabilité unique. Voir 08 - SOLID.

Guard clause

Condition en début de fonction qui vérifié une precondition et sort immédiatement si elle n'est pas remplie. Synonyme d'early return applique a la validation. Voir 03 - Conditions.

I

Immutabilite

Propriété d'une donnee qui ne peut pas etre modifiee apres sa création. Reduit les bugs lies aux modifications inattendues. En TypeScript, readonly et as const renforcent l'immutabilité au niveau du type system. Voir 05 - Immutabilite.

Interface Segregation Principle (ISP)

Le I de SOLID. Les clients ne doivent pas etre forces de dépendre d'interfaces qu'ils n'utilisent pas. Prefere plusieurs interfaces spécifiques a une interface générale et massive. Voir 08 - SOLID.

K

KISS (Keep It Simple, Stupid)

Principe qui favorise la simplicité. La solution la plus simple qui resout le problème est généralement la meilleure. Ne confonds pas simple et facile : une solution simple peut demander du travail pour etre trouvee. Voir 09 - DRY, KISS, YAGNI.

L

Legacy code

Code existant sans tests, difficile a modifier. Selon Michael Feathers, tout code sans tests est du legacy code. La stratégie pour le gerer : ajouter des tests, puis refactoriser. Voir 15 - Refactoring legacy.

Lint / Linter

Outil d'analyse statique qui détecté des erreurs, des patterns dangereux et des violations de conventions dans le code source. ESLint et Biome sont les linters principaux de l'ecosysteme TypeScript. Voir 19 - Linting.

Liskov Substitution Principle (LSP)

Le L de SOLID. Un objet d'un type derive doit pouvoir remplacer un objet du type de base sans casser le programme. Voir 08 - SOLID.

Loi de Demeter

Principe qui dit qu'un objet ne doit parler qu'a ses voisins directs. Evite les chaînes d'appels comme order.getCustomer().getAddress().getCity(). Voir 12 - Loi de Demeter.

M

Magic number

Valeur numérique qui apparaît directement dans le code sans nom ni explication. Rend le code incomprehensible et fragile. La solution : extraire la valeur dans une constante nommee. Voir 18 - Constantes.

O

Open/Closed Principle (OCP)

Le O de SOLID. Les modules doivent etre ouverts a l'extension mais fermes a la modification. Ajouter un comportement ne devrait pas nécessiter de modifier le code existant. Voir 08 - SOLID.

R

Red-green-refactor

Cycle TDD en trois étapes : écrire un test qui echoue (red), écrire le code minimal pour le faire passer (green), ameliorer la structure sans casser les tests (refactor). Voir 16 - Tests et refactoring.

S

Separation des responsabilités (Separation of Concerns)

Principe qui dit que chaque module doit gerer un seul aspect du système. La presentation ne gere pas la logique métier. La logique métier ne gere pas la persistance. Voir 10 - Separation des responsabilités.

Single Responsibility Principle (SRP)

Le S de SOLID. Un module doit avoir une seule raison de changer. Plus precisement : un seul acteur (stakeholder) qui pourrait demander une modification. Voir 08 - SOLID.

SOLID

Acronyme de cinq principes de conception orientes objet : Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion. Voir 08 - SOLID.

Strangler fig pattern

Stratégie de migration qui remplace progressivement un système legacy par un nouveau système. Le nouveau code entoure l'ancien comme un figuier etrangleur entoure un arbre. L'ancien code est retire par morceaux. Voir 15 - Refactoring legacy.

T

Test d'intégration

Test qui vérifié le comportement de plusieurs modules qui interagissent ensemble. Survit mieux au refactoring que les tests unitaires car il teste le comportement observable. Voir 16 - Tests et refactoring.

Test unitaire

Test qui vérifié le comportement d'une unité isolee de code (typiquement une fonction). Rapide a exécuter et precis dans la localisation des erreurs, mais couple a l'implementation. Voir 16 - Tests et refactoring.

Y

YAGNI (You Aren't Gonna Need It)

Principe qui dit de ne pas implementer une fonctionnalité tant qu'elle n'est pas effectivement nécessaire. Lutte contre la tendance a anticiper des besoins futurs qui ne se materialisent jamais. Voir 09 - DRY, KISS, YAGNI.

Comment utiliser ce glossaire

Ce document est une référencé, pas un article a lire de bout en bout. Mets-le en favori. Quand tu tombes sur un terme dans la serie ou dans une discussion technique, reviens ici pour une définition rapide et un lien vers l'article complet.

Si un terme manque, c'est probablement que je l'ai oublie. La serie evolue et ce glossaire avec.

Résumé

Ce glossaire couvre plus de 40 termes techniques de la serie
Chaque terme est défini en une a trois phrases
Les liens renvoient vers l'article qui traite le sujet en profondeur
Utilise ce document comme référencé rapide, pas comme lecture lineaire

Article précédent : 22 - Code review

Serie suivante : a venir.

Sources

Martin Fowler, "Refactoring: Improving the Design of Existing Code" (2018) - https://martinfowler.com/books/refactoring.html
Robert C. Martin, "Clean Code: A Handbook of Agile Software Craftsmanship" (2008) - https://www.oreilly.com/library/view/clean-code-a/9780136083238/
Michael Feathers, "Working Effectively with Legacy Code" (2004) - https://www.oreilly.com/library/view/working-effectively-with/0131177052/