Guide

Code Durable

Comment programmer du code facile à maintenir.

En vidéo

Código Sostenible

Chapitre 1

Qu'est-ce que le Code Durable ?

Fondamentaux pour écrire du code maintenable et durable

Définition

Code facile à maintenir, avec une conception intuitive et une complexité minimale

Conception intuitive
Complexité essentielle minimale
Bonne couverture de tests

Écrire pour les Humains

Le code doit être lisible et compréhensible pour les autres développeurs

Prioriser la lisibilité
Utiliser des noms descriptifs
Documenter les décisions complexes

Dégénérescence du Code

Comment éviter que le code se détériore avec le temps

Complexité Accidentelle vs. Essentielle
Refactorisation continue
Maintenir une architecture propre

Les Personnes d'Abord

L'empathie comme principe fondamental du développement

Prendre en compte l'équipe
Faciliter la maintenance
Réduire la charge cognitive

Chapitre 2

Refactorisation

La pratique quotidienne d'amélioration du code existant

Pratique Quotidienne

La refactorisation doit faire partie du flux de travail quotidien

Petites améliorations constantes
Ne pas attendre de grands refactors
Intégrer au développement habituel

Améliorations de la Lisibilité

Se concentrer sur la simplification de la lecture et de la compréhension du code

Renommer les variables et les fonctions
Extraire les méthodes complexes
Simplifier les expressions

Code Smells

Identifier et éliminer les schémas problématiques dans le code

Méthodes trop longues
Classes avec trop de responsabilités
Code dupliqué
Commentaires excessifs

Chapitre 3

Fondamentaux

Principes de base pour un code durable

Concevoir pour le Présent

Éviter la sur-ingénierie et se concentrer sur les besoins actuels

YAGNI (You Aren't Gonna Need It)
Solutions simples en premier
Évolution incrémentale

Usage Concret vs Réutilisation

Prioriser les solutions spécifiques plutôt que les abstractions prématurées

Résoudre le problème actuel
Abstraire lorsque des schémas clairs apparaissent
Éviter la généralisation prématurée

Règles du Code Durable

Quatre règles fondamentales pour maintenir un code de qualité

1. Couvert par des tests
2. Les tests sont durables
3. Les abstractions ont du sens
4. Intentionnalité explicite

Chapitre 4

Techniques pour Choisir les Noms

L'art de nommer les éléments du code

Caractéristiques d'un Bon Nom

Propriétés que doivent avoir les noms dans le code

Faciles à prononcer
Sans information technique
Concrets et spécifiques
Forment des phrases naturelles (is, has)

Éviter les Mauvaises Pratiques

Ce qu'il ne faut pas faire en nommant les éléments

Pas d'alias confus
Éviter les abréviations
Ne pas utiliser de numéros en séquence
Éviter les noms génériques

Stratégies de Nommage

Techniques pour créer des noms efficaces

S'appuyer sur le contexte
Utiliser des noms, verbes et adjectifs appropriés
Nommer les valeurs littérales
Renommer le lendemain si nécessaire

Chapitre 5

Principe de Moindre Surprise

La boussole du code durable

Définition du Principe

Le code doit se comporter comme les développeurs s'y attendent

Comportement prévisible
Cohérence de l'API
Suivre les conventions établies

Application Pratique

Comment appliquer ce principe au quotidien

Des méthodes qui font ce que leur nom indique
Des paramètres dans un ordre logique
Des valeurs de retour attendues

Éviter les Effets de Bord

Minimiser les comportements inattendus

Des fonctions pures autant que possible
Documenter les effets de bord nécessaires
Séparer les commandes des requêtes

Chapitre 6

Cohésion et Couplage

L'étoile polaire de la conception logicielle

Forte Cohésion

Les éléments liés doivent être regroupés

Responsabilités liées entre elles
Fonctions qui travaillent ensemble
Données et comportements réunis

Faible Couplage

Minimiser les dépendances entre modules

Loi de Déméter
Dis-le, ne demande pas (Tell, Don't Ask)
Interfaces bien définies

Connascence

Mesure de la force de dépendance entre les éléments

Connascence de nom
Connascence de type
Connascence de signification
Connascence d'algorithme

Chapitre 7

Principes SOLID

Cinq principes fondamentaux de la conception orientée objet

SRP - Responsabilité Unique

Une classe doit avoir une seule raison de changer

Une responsabilité par classe
Facilite la maintenance
Réduit le couplage

OCP - Ouvert-Fermé

Ouvert à l'extension, fermé à la modification

Extensible sans modifier le code existant
Utilisation d'abstractions
Polymorphisme et héritage

LSP - Substitution de Liskov

Les objets dérivés doivent pouvoir se substituer à leurs classes de base

Contrats bien définis
Préconditions pas plus fortes
Postconditions pas plus faibles

ISP - Ségrégation des Interfaces

Plusieurs interfaces spécifiques valent mieux qu'une seule générale

Interfaces cohésives
Éviter les dépendances inutiles
Les clients ne dépendent pas de méthodes qu'ils n'utilisent pas

DIP - Inversion des Dépendances

Dépendre des abstractions, pas des implémentations concrètes

Les modules de haut niveau ne dépendent pas de ceux de bas niveau
Les deux dépendent d'abstractions
Facilite les tests et la flexibilité

Chapitre 8

Implémentation Durable

Techniques pratiques pour écrire du code maintenable

Structure et Formatage

Organisation visuelle du code

Indentation cohérente
Réduire la portée au maximum
Clauses de garde et symétrie

Composition vs Héritage

Préférer la composition à l'héritage

Plus grande flexibilité
Moins de couplage
Plus facile à tester

Constructeurs et Fonctions

Bonnes pratiques pour les méthodes et les constructeurs

Constructeurs simples
Constructeurs nommés
Séparer le contrôle de flux de la logique
Préférer les fonctions pures

Paramètres et CQS

Gestion des paramètres et séparation des responsabilités

Pas de paramètres de configuration
Réduire l'arité
CQS : Séparer Requêtes et Commandes

Chapitre 9

Gestion et Prévention des Erreurs

Stratégies pour un code robuste et résilient

Prévention des Erreurs Humaines

Concevoir des systèmes qui minimisent les erreurs

Comprendre le langage en profondeur
Valeurs, références, objets
Comparaison (equals, hashCode)
Copie superficielle vs profonde

Zones de Concentration des Incidents

Zones du code les plus sujettes aux erreurs

Gestion de l'état
Asynchronisme et concurrence
Gestion des ressources
Validation des entrées

Code Résilient vs Défensif

Stratégies pour gérer les situations inattendues

Fail fast vs fail safe
Validation aux frontières
Récupération élégante

Gestion de l'Absence et des Erreurs

Patrons pour gérer les valeurs absentes et les erreurs

Patron Objet Nul
Type Optional/Maybe
Type Either
Patron Notification
Type Try

Chapitre 10

Types Spécifiques au Domaine

Expressivité et cohésion grâce aux types

Avantages des Types Spécifiques

Pourquoi créer des types propres au domaine

Plus grande expressivité
Meilleure cohésion
Anti-Primitive Obsession
Validation à la compilation

Objets Valeur vs Entités

Différences fondamentales de conception

Objets Valeur : immuables, sans identité
Entités : mutables, avec identité
Quand utiliser l'un ou l'autre

Génériques et Types Algébriques

Outils avancés de typage

Génériques pour la réutilisation
Types Somme (Union Types)
Types Produit (Record Types)
Composition de types

Chapitre 11

Principes Mal Interprétés

Démystifier les règles de programmation obsolètes

Contexte Historique

Pourquoi certaines règles sont apparues et pourquoi elles ne s'appliquent plus

Limitations du matériel ancien
Outils de développement rudimentaires
Évolution des langages et des paradigmes

Règles Obsolètes

Principes qui ne sont plus pertinents, voire contre-productifs

Un seul return par fonction
Déclarer les variables au début
Les interfaces découplent toujours
Getters et Setters pour tout

Optimisation Prématurée

L'équilibre entre lisibilité et performance

Le code doit être optimal (mythe)
Lisibilité d'abord, optimisation ensuite
Mesurer avant d'optimiser
Commenter seulement le nécessaire

Chapitre 12

Crédits

Livre

Basé sur le livre

Auteur : Carlos Blé Jurado
Préface : Javier Ferrer

Résumé

Points principaux

Auteur : Daniel Boggiano

Audio

Podcast généré par IA

Auteur : Daniel Boggiano
YouTube :