Chapitre 1 : Refactorisation

1.1 Qu'est-ce que le refactoring ?
1.2 Compétence : Que faut-il refactoriser ?
1.2.1 Exemple de code défectueux
__1.2.2 Exemple de règle
1.3 Culture : Quand faut-il refactoriser ?
1.3.1 Refactorisation dans les systèmes existants
__1.3.2 Quand ne faut-il pas refactoriser ?
1.4 Outils : Méthodes de refactorisation (sûres)
1.5 Outils nécessaires pour débuter
__1.5.1 Langage de programmation : TypeScript
__1.5.2 Éditeur : Visual Studio Code 1
__1.5.3 Gestion des versions : Git
1.6 Exemple principal : Jeu de puzzle 2D
1.6.1 La pratique est le seul moyen de survivre : La deuxième base de code
1.7 Remarques sur les logiciels dans des environnements réels
addition

Chapitre 2 : Une analyse approfondie du refactoring

2.1 Amélioration de la lisibilité et de la maintenabilité
__2.1.1 Amélioration du code
__2.1.2 Maintenir le code sans en modifier le fonctionnement
2.2 Garantir la vitesse, la flexibilité et la stabilité
2.2.1 Privilégier la composition à l'héritage
__2.2.2 Modifications supplémentaires du code, et non des modifications
2.3 Refactorisation et travail quotidien
__2.3.1 La refactorisation comme méthode d'apprentissage
2.4 Définition d'un « domaine » dans le domaine du logiciel
addition

Chapitre 3 : Découpage du code long

3.1 Première règle : Pourquoi cinq lignes ?
3.1.1 Règle : Limite de cinq lignes
3.2 Introduction des modèles de refactorisation pour la décomposition de fonctions
3.2.1 Modèle de refactorisation : Extraction de méthode
3.3 Décomposition de la fonction pour correspondre au niveau d'abstraction
Règle 3.3.1 : Appeler ou passer, n’en faire qu’un seul.
3.3.2 Application de la règle
3.4 Propriétés d'un bon nom de fonction
3.5 Séparer les fonctions qui effectuent une part excessive du travail
3.5.1 Règle : les instructions « if » doivent être placées uniquement au début des fonctions.
3.5.2 Application des règles
addition

Chapitre 4 : Gestion des codes de type

4.1 Refactorisation d'une instruction if simple
Règle 4.1.1 : N’utilisez pas « else » dans les instructions « if ».
4.1.2 Application de la règle
4.1.3 Modèle de refactorisation : remplacement du code de type par des classes
__4.1.4 Migration du code vers une classe
4.1.5 Modèle de refactorisation : Migration de code vers une classe
4.1.6 Intégration des méthodes inutiles
4.1.7 Modèle de refactorisation : Inlining de méthodes
4.2 Refactorisation des instructions if longues
__4.2.1 Supprimer la généralité
4.2.2 Modèle de refactorisation : Spécialisation des méthodes
__4.2.3 Le seul cas où le commutateur est autorisé
Règle 4.2.4 : Ne pas utiliser d’interrupteur
__4.2.5 Suppression si
4.3 Gestion de la duplication de code
__4.3.1 Ne pouvons-nous pas utiliser des classes abstraites au lieu d'interfaces ?
Règle 4.3.2 : Hériter uniquement des interfaces
__4.3.3 Qu'est-ce que la duplication de code en classe ?
4.4 Refactorisation des instructions if enchaînées complexes
4.5 Suppression du code inutile
4.5.1 Modèle de refactorisation : Supprimer et compiler
addition

Chapitre 5 : Fusion de code similaire
5.1 Intégration de classes similaires
__5.1.1 Modèle de refactorisation : regroupement des classes similaires
5.2 Intégration de conditions simples
__5.2.1 Modèle de refactorisation : Combinaison d’instructions if
5.3 Intégration de conditions complexes
5.3.1 Utilisation des règles arithmétiques pour les conditions
Règle 5.3.2 : Utilisez des conditions pures
__5.3.3 Application de l'arithmétique conditionnelle
5.4 Intégration de code entre les classes
5.4.1 Introduction aux diagrammes de classes UML pour la représentation des relations entre les classes
5.4.2 Modèles de refactorisation : Introduction du modèle de stratégie
Règle 5.4.3 : Ne créez pas d'interfaces avec une seule implémentation.
5.4.4 Modèle de refactorisation : Extraction de l’interface à partir de l’implémentation
5.5 Intégration de fonctions similaires
5.6 Fusion de code similaire
addition

Chapitre 6 : Protection des données

6.1 Encapsulation sans accesseurs
6.1.1 Règle : N'utilisez pas de getters et de setters
6.1.2 Application des règles
6.1.3 Modèle de refactorisation : Suppression des accesseurs et des mutateurs
__6.1.4 Supprimer le dernier getter
6.2 Encapsulation simple des données
6.2.1 Règle : N’utilisez pas d’affixes courants
6.2.2 Application des règles
6.2.3 Modèle de refactorisation : Encapsulation des données
6.3 Encapsulation de données complexes
6.4 Suppression des invariants dans une séquence
6.4.1 Modèle de refactorisation : Imposition de l’ordre
6.5 Une autre façon de supprimer les énumérations
__6.5.1 Énumération via des constructeurs privés
6.5.2 Réaffectation des nombres aux classes
addition

Chapitre 7 : Utilisation du compilateur

7.1 Découverte du compilateur
7.1.1 Faiblesse : Les problèmes d'arrêt limitent les informations disponibles lors de la compilation.
__7.1.2 Avantage : La vérification de l'accessibilité garantit le retour d'une méthode.
__7.1.3 Avantage : L'affectation définie empêche l'accès aux variables non initialisées.
7.1.4 Avantage : Prend en charge l'encapsulation des données avec contrôle d'accès
7.1.5 Avantage : Le vérificateur de type garantit les propriétés
__7.1.6 Faiblesse : Le déréférencement de null provoque le plantage de l'application.
7.1.7 Faiblesse : Les erreurs arithmétiques entraînent un dépassement de capacité ou une corruption.
__7.1.8 Faiblesse : Les erreurs hors limites provoquent le plantage des applications.
__7.1.9 Les boucles infinies ralentissent votre application.
__7.1.10 Faiblesse : Les blocages et les conditions de concurrence peuvent conduire à un comportement imprévu.
7.2 Utilisation du compilateur
7.2.1 Utilisation du compilateur
7.2.2 Ne luttez pas contre le compilateur
7.3 Faire confiance au compilateur
__7.3.1 Enseignement des invariants au compilateur
7.3.2 Faites attention aux avertissements du compilateur
7.4 Ne faites confiance qu'au compilateur
addition

Chapitre 8 : S'abstenir de tout commentaire

8.1 Suppression des anciens commentaires
8.2 Suppression du code commenté
8.3 Supprimer les commentaires inutiles
8.4 Remplacement des commentaires par des noms de méthodes
8.4.1 Utilisation des commentaires pour la planification
8.5 Conserver les commentaires documentant les invariants
8.5.1 Invariants de processus
addition

Chapitre 9 : L'art de la suppression de code

9.1 La prochaine ère sera celle de l'effacement du code.
9.2 Suppression de code pour éliminer la complexité
9.2.1 Ignorance technique due à un manque d'expérience
9.2.2 Gaspillage technique dû à la pression du temps
9.2.3 Dette technique par environnement
9.2.4 Obstacles techniques à la croissance
9.3 Classification des codes par degré d'intimité
9.4 Suppression de code des systèmes existants
__9.4.1 Motif de figuier étrangleur
__9.4.2 Utilisation du modèle d'arbre en figue étrangleuse pour améliorer le code
9.5 Suppression de code d'un projet gelé
9.5.1 Définir le résultat souhaité comme valeur par défaut
__9.5.2 Réduction des déchets grâce aux pointes et à la stabilisation
9.6 Suppression d'une branche du contrôle de version
9.6.1 Minimiser le gaspillage grâce aux limites de branche
9.7 Suppression des documents de code
9.7.1 Algorithme de détermination de la manière de documenter les connaissances
9.8 Suppression du code de test
__9.8.1 Supprimer les tests optimistes
__9.8.2 Suppression des tests pessimistes
__9.8.3 Corriger ou supprimer les tests instables
__9.8.4 Refactorisation du code pour éliminer les tests complexes
__9.8.5 Accélérer la culture des tests
9.9 Supprimez le code de configuration
9.9.1 Définir la durée de vie prévue des paramètres
9.10 Supprimer le code pour la suppression de la bibliothèque
9.10.1 Limitation des dépendances aux bibliothèques externes
9.11 Supprimer le code de la fonction en cours d'exécution
addition

Chapitre 10 : Surmonter la peur d’ajouter du code

10.1 Accepter l'incertitude : prendre des risques
10.2 Utiliser des pointes pour surmonter la peur
10.3 Spécifier un ratio de temps d'utilisation pour surmonter la crainte du gaspillage ou du risque
10.4 Amélioration progressive pour surmonter la peur de l'imperfection
10.5 Comment le copier-coller affecte la vitesse
10.6 Modifications par ajout grâce à l'extensibilité
10.7 Modifications visant à assurer la compatibilité avec les versions précédentes
10.8 Modifications dues à l'ajout d'un bouton d'activation/désactivation
10.9 Modifications dues à l'ajout de la fonctionnalité « Branchage par abstraction »
addition

Chapitre 11 : Suivre la structure du code

11.1 Classification des structures par étendue et source
11.2 Trois façons de codifier les actions
__11.2.1 Actions de codage dans le flux de contrôle
__11.2.2 Intégration du comportement dans les structures de données
11.2.3 Codage des comportements dans les données
11.3 Ajout de code pour exposer la structure
11.4 Observation plutôt que prédiction, et utilisation de techniques empiriques.
11.5 Comment garantir la sécurité sans comprendre le code
11.5.1 Garantir la sécurité par les essais
11.5.2 Garantir la sécurité par la maîtrise
11.5.3 Garantir la sécurité grâce au support des outils
11.5.4 Garantir la sécurité par une certification officielle
11.5.5 Garantir la sécurité par la tolérance aux pannes
11.6 Utilisation des structures inutilisées
__11.6.1 Utilisation des espaces blancs pour l'extraction et l'encapsulation
__11.6.2 Utilisation de code dupliqué pour l'intégration
__11.6.3 Utilisation des affixes courants avec encapsulation
__11.6.4 Exploitation des types d'exécution avec l'exécution dynamique
addition

Chapitre 12 : Éviter l’optimisation et la généralisation

12.1 La recherche de la simplicité
12.2 Moment et méthode de généralisation
12.2.1 Éviter la généralisation en minimisant l'implémentation
__12.2.2 Intégration de la stabilité similaire
__12.2.3 Éliminer les généralisations inutiles
12.3 Quand et comment optimiser
12.3.1 Refactorisation avant l'optimisation
12.3.2 Optimisation selon la théorie des contraintes
__12.3.3 Optimisation à l'aide de métriques
__12.3.4 Choisir de bons algorithmes et de bonnes structures de données
__12.3.5 Utilisation du cache
__12.3.6 Séparation du code optimisé
addition

Chapitre 13 : Rendre le code défectueux identifiable

13.1 Comment gérer un code défectueux
13.2 Séparation du code propre et du code hérité
13.2.1 Théorie des vitres brisées
13.3 Comment trouver un code défectueux
__13.3.1 Règles de ce livre : Code simple et concret
13.3.2 Odeur de code : Code complet et abstrait
__13.3.3 Complexité cyclomatique : Algorithmes (Objectif)
__13.3.4 Complexité cognitive : Algorithme (Subjectif)
13.4 Règles pour faire apparaître du code comme du code défectueux en toute sécurité
13.5 Comment rendre un mauvais code illisible
__13.5.1 Utilisation des énumérations
__13.5.2 Utilisation des entiers et des chaînes de caractères comme codes de type
__13.5.3 Insertion de nombres magiques dans le code
__13.5.4 Commenter votre code
__13.5.5 Ajout d'espaces au code
__13.5.6 Regroupement des éléments par nom
__13.5.7 Ajouter du contexte à un nom
__13.5.8 Création d'une méthode longue
__13.5.9 Passage de plusieurs paramètres à une méthode
__13.5.10 Utilisation des accesseurs et des mutateurs
addition

Chapitre 14 : Conclusion

14.1 Retour sur le parcours de ce livre
14.1.1 Introduction : Motivation
__14.1.2 Partie 1 : Le rendre spécifique
__14.1.3 Partie 2 : Élargir vos horizons
14.2 Exploration de la philosophie fondamentale
14.2.1 Toujours choisir le pas le plus court
14.2.2 Recherche de la structure de base
14.2.3 Utilisation des règles de collaboration
14.2.4 Prioriser l'équipe plutôt que l'individu
14.2.5 Privilégier la simplicité à l'exhaustivité
14.2.6 Utilisation d'objets ou de fonctions d'ordre supérieur
Voyage après 14h30
__14.3.1 Voyage vers la microarchitecture
__14.3.2 Voyage vers la macro-architecture
14.3.3 Le parcours vers la qualité logicielle
addition

Annexe A : Installation des outils pour la pratique

Node.js
Manuscrit
Code Visual Studio
Git
Mise en place d'un projet TypeScript
Créer un projet TypeScript
Comment modifier les niveaux

Ce que ce livre couvre

◎ Caractéristiques d'un code de mauvaise qualité
◎ Comment améliorer du code en toute sécurité sans le comprendre
◎ Équilibrer l'optimisation et la généralité du code
◎ Utilisation d'un compilateur approprié
◎ Introduction des modèles d'extraction de méthodes et de stratégies, ainsi que de divers autres modèles de refactorisation
◎ Écrire du code stable permettant des modifications par ajout de code
◎ Écrire du code qui ne nécessite pas de commentaires
◎ Exemples concrets de refactorisation réussie