Chapitre 1 Code propre
Il y aura un code
code erroné
Le prix d'un mauvais code
__ Rêver d'une refonte complète
__ attitude
__ Le défi primordial
__ L'art du code propre ?
__Qu'est-ce qu'un code propre ?

Nos pensées
Nous sommes les auteurs
Règles des scouts
Préquelles et principes
conclusion
Références

Chapitre 2 Noms significatifs
Au fur et à mesure que vous entrez
Exprimez clairement vos intentions.
Évitez la désinformation
Distinguer de manière significative
Utilisez un nom facile à prononcer
Utilisez un nom facile à rechercher
Évitez le codage
__ Notation hongroise
__ préfixe de variable membre
__ Classe d'interface et classe d'implémentation

Ne vous vantez pas de votre mémoire.
Nom de la classe
Nom de la méthode
Évitez les noms originaux
Utiliser un mot pour un concept
Ne jouez pas avec les mots
Utilisez le nom figurant dans la zone de solution.
Utilisez des noms tirés du domaine problématique
Ajouter un contexte pertinent
Éliminer le contexte inutile
Pour conclure

Chapitre 3 Fonctions
Réduisez la taille !
__ blocs et indentation

Faites juste une chose !
__ Section au sein de la fonction

Un niveau d'abstraction par fonction !
__ Lire le code de haut en bas : la règle de la descente

instruction Switch
Utilisez des noms descriptifs !
arguments de la fonction
__ Format unaire couramment utilisé
__ argument drapeau
__ Fonction binaire
fonction ternaire
__ objet argument
__ liste d'arguments
__ Verbes et mots-clés

Ne provoquez pas d'effets secondaires !
__ arguments de sortie

Commandes et requêtes séparées !
Utilisez les exceptions plutôt que les codes d'erreur !
__ Extraction des blocs Try/Catch
__ La gestion des erreurs est également une tâche.
__Error.java dépendance magnet

Ne vous répétez pas !
Programmation structurée
Comment écrit-on une fonction ?
conclusion
Références

Notes du chapitre 4
Les commentaires ne compensent pas un mauvais code.
Exprimez vos intentions avec du code !
Bon commentaire
__ Mentions légales
__ Commentaires fournissant des informations
__ Commentaire expliquant l'intention
__ Annotations clarifiant le sens
__ Avertissement concernant les résultats
__ À FAIRE commentaire
__ Notes soulignant l'importance
__ Javadocs dans l'API publique

mauvais commentaires
__ commentaire décousu
__ Commentaires qui répètent la même histoire
Commentaire trompeur
__ Commentaires obligatoires
__ Historique des commentaires
Il y a un commentaire, mais il ne suffit pas.
__ bruit effrayant
__ Si cela peut être exprimé sous forme de fonction ou de variable, n'ajoutez pas de commentaire.
__ Commentaire indiquant l'emplacement
__ Commentaires attachés aux parenthèses fermantes
__ Annotations mentionnant l'auteur
__ Code commenté
__ Commentaires HTML
__ Informations mondiales
__ Trop d'informations
Relation ambiguë
__ en-tête de fonction
__ Javadocs dans le code privé
__ Exemple

Références

Chapitre 5 Mise en forme
L'objectif de la mise en forme
Maintenir une longueur de ligne appropriée
__ Rédigez comme un article de journal
__ Séparez les concepts par des lignes vides
__ densité verticale
__ distance verticale
__ ordre vertical

Format horizontal
__ Espace horizontal et densité
__ Alignement horizontal
__ indentation

fausse gamme
Règles de l'équipe
Les règles de forme de l'oncle Bob

Chapitre 6 Objets et structures de données
abstraction des données
Asymétrie des données/objets
La loi de Déméter
__ accident de train
__ structure hybride
__ Masquer la structure

objet de transfert de données
__Enregistrement actif

conclusion
Références

Chapitre 7 Gestion des erreurs
Utilisez les exceptions plutôt que les codes d'erreur
Commencez par une instruction Try-Catch-Finally.
Utiliser des exceptions non vérifiées
Donner un sens aux exceptions
Définir les classes d'exceptions en tenant compte de l'appelant.
Définir le flux normal
Ne pas renvoyer null
Ne transmettez pas de valeur nulle
conclusion
Références

Chapitre 8 Les limites
Utilisation de code externe
Observez et apprenez les limites
Apprendre log4j
Les tests d'apprentissage sont plus que gratuits
Utilisation de code qui n'existe pas encore
frontières propres
Références

Chapitre 9 Tests unitaires
Trois règles du TDD
Maintenir un code de test propre
Les tests offrent flexibilité, maintenabilité et réutilisabilité.

Code de test propre
Langage de test spécifique au domaine
__ deux poids, deux mesures

Une assertion par test
__ Un concept par test

D'ABORD
conclusion
Références

Chapitre 10 Classe
système de classes
__ encapsulation

Les classes devraient être petites !
Principe de responsabilité unique
__ Cohésion
Le maintien de la cohésion se traduit par de nombreuses petites classes.

Changement de classe facile
__ Isolement des changements

Références

Chapitre 11 Système
Et si vous construisiez une ville ?
Distinguer la création du système de son utilisation.
__ Séparation principale
__ Usine
Injection de dépendances

expansion
__ Intérêts transversaux

Proxy Java
Framework AOP Java pur
Perspective AspectJ
Élaboration d'une architecture système pilotée par les tests
Optimisez votre prise de décision
Utilisez les normes à bon escient lorsqu'elles ont une valeur manifeste.
Le système requiert un langage spécifique au domaine.
conclusion
Références

Chapitre 12 : La créativité
Mettons en œuvre un code propre grâce à une conception émergente.
Règle de conception simple n° 1 : Exécutez tous les tests
Règles de conception simples 2 à 4 : Refactorisation
Éliminer les doublons
Exprimez-vous
Réduisez au minimum le nombre de classes et de méthodes
conclusion
Références

Chapitre 13 Concurrence
Pourquoi la concurrence est-elle nécessaire ?
__ Superstitions et malentendus

Difficulté
Principe de défense contre la concurrence
__ Principe de responsabilité unique (PRU)
Corollaire : Limiter la portée des données
Suivi : Utiliser des copies des données
Suite : Implémentez les threads de la manière la plus indépendante possible.

Comprendre la bibliothèque
Collection de fils résistants

Comprendre le modèle d'exécution
__ Producteur-Consommateur
__Lecteurs-Écrivains
__ Philosophes de la table

Comprendre les dépendances qui existent entre les méthodes synchronisées.
Réduisez la taille de la partie synchronisation.
Les codes de sortie corrects sont difficiles à implémenter
Test du code multithread
__ Considérez les échecs absurdes comme des problèmes de threads temporaires.
__ Faisons en sorte que le code séquentiel qui ne prend pas en compte le multithreading fonctionne correctement.
__ Implémenter du code multithreadé afin que la partie de code multithread puisse être facilement insérée dans différents environnements.
__ Écrivez un code qui utilise plusieurs threads afin qu'il puisse être adapté à la situation.
__ Essayez d'exécuter plus de threads que le nombre de processeurs.
__ Essayez de l'exécuter sur une autre plateforme
__ Insérez l'instrument de code auxiliaire dans le code et exécutez-le.
Tentez de forcer l'échec
__ Mettez-le en œuvre vous-même
__ Automatisation

conclusion
Références

Chapitre 14 : Amélioration progressive
Implémentation des arguments
__ Comment as-tu fait ?

Arguments : Première ébauche
__ Alors ça s'est arrêté
__ s'améliorer progressivement

Argument de type chaîne
conclusion

Chapitre 15 : Un aperçu de JUnit
Cadre JUnit
conclusion

Chapitre 16 : Refactorisation de SerialDate
Tout d'abord, inversons la tendance.
Deuxièmement, corrigeons-le.
conclusion
Références

Chapitre 17 : Odeurs et heuristiques

annotation
__ C1 : Informations inappropriées
__ C2 : Commentaires inutiles
__ C3 : Commentaire en double
__ C4 : Commentaires hypocrites
__ C5 : Code commenté

environnement
__ E1 : Nécessité de construire en plusieurs étapes
__ E2 : Les tests doivent être effectués en plusieurs étapes

fonction
__ F1 : Trop d'arguments
__ F2 : Argument de sortie
__ F3 : Argument du drapeau
__ F4 : Fonction morte

commun
__ G1 : Utiliser plusieurs langues dans un seul fichier source
__ G2 : Ne met pas en œuvre le comportement attendu
__ G3 : Gestion incorrecte des limites
__ G4 : Ignorer les procédures de sécurité
__ G5 : Duplicata
__ G6 : Niveau d’abstraction incorrect
__ G7 : La classe de base dépend de la classe dérivée
G8 : Surcharge d’informations
__ G9 : Code mort
__ G10 : Séparation verticale
__ G11 : Manque de cohérence
__ G12 : Divers
__ G13 : Liaison artificielle
__ G14 : Avidité fonctionnelle
__ G15 : Arguments du sélecteur
__ G16 : Intention ambiguë
__ G17 : Responsabilité en cas d'effacement erroné
__ G18 : Fonction statique inappropriée
__ G19 : Variables descriptives
__ G20 : Fonctions avec des noms et des fonctions correspondants
__ G21 : Comprendre l'algorithme
__ G22 : Exposer physiquement les dépendances logiques
__ G23 : Utilisez le polymorphisme plutôt que les instructions If/Else ou Switch/Case.
__ G24 : Suivre la notation standard
__ G25 : Remplacer les nombres magiques par des constantes nommées
__ G26 : Soyez précis
__ G27 : Privilégier la structure à la convention
__ G28 : Encapsuler les conditions
__ G29 : Éviter les conditions négatives
__ G30 : Une fonction ne doit faire qu’une seule chose
__ G31 : Combinaison temporelle cachée
__ G32 : Soyez cohérent
__ G33 : Encapsuler les conditions aux limites
__ G34 : Les fonctions ne doivent descendre que d’un seul niveau d’abstraction
__ G35 : Placez les informations de configuration au niveau supérieur
__ G36 : Éviter la recherche transitive

Java
__ J1 : Évitez les longues listes d’importation et utilisez des caractères génériques
__ J2 : Les constantes ne sont pas héritées
__ J3 : Constantes vs. Énumérations

nom
__ N1 : Utilisez des noms descriptifs
__ N2 : Choisissez un nom au niveau d'abstraction approprié
__ N3 : Utiliser la nomenclature standard si possible
__ N4 : Nom clair
__ N5 : Utilisez des noms longs pour les plages longues
__ N6 : Évitez l’encodage
__ N7 : Décrivez l'effet secondaire par son nom.

test
__ T1 : Tests insuffisants
__ T2 : Utilisez l'outil de couverture !
__ T3 : Ne négligez pas les tests triviaux
__ T4 : Les tests ignorés entraînent une ambiguïté
__ T5 : Tester les conditions aux limites
__ T6 : Tester minutieusement autour des bogues
__ T7 : Rechercher les schémas de défaillance
__ T8 : Examiner le modèle de couverture des tests
__ T9 : Les tests doivent être rapides

conclusion
Références

Annexe A Concurrence II

Exemple client/serveur
__ serveur
__ Ajouter une discussion
__ Consultez le serveur
__ conclusion

Chemins d'exécution possibles
__ nombre de chemins
__ Calculez le nombre de permutations possibles
__ Analyse approfondie
__ conclusion

Comprendre la bibliothèque
__ Cadre d'exécution
Méthode non bloquante qui ne bloque pas le thread
__ Classes qui ne sont pas sûres dans les environnements multithread

Attention aux dépendances entre les méthodes.
__ Tolérer l'échec
__ Verrouillage côté client
__ Verrouillage côté serveur

Augmenter le débit
__ Calcul du débit - environnement monothread
__ Calcul de la charge de travail - Environnement multithread

impasse
__ Exclusion mutuelle
__ Verrouiller et attendre
__ Aucune préemption
__ Attente circulaire
__ Rupture de la condition d'exclusion mutuelle
__ Briser le verrou et attendre la condition
__ Rupture de la condition de non-préemption
__ Rompre la condition d'attente circulaire
__ Test de code multithread
__ Outils pour faciliter le test du code multithread

conclusion
Tutoriel : Exemples de code complets
__ Client/Serveur - Version mono-thread
__ Client/Serveur - Version multithread

Annexe B org.jfree.date.SerialDate

Annexe C : Liste de références croisées des heuristiques

Épilogue
Glossaire des termes
Liste des abréviations
Recherche

Un code défectueux fonctionne quand même.
Mais si le code n'est pas propre, l'équipe de développement va le dénigrer.
Chaque année, d'innombrables heures et des ressources considérables sont gaspillées à cause d'un code mal structuré.
Il n'y a aucune raison de faire cela.

Dans cet ouvrage, Robert Martin présente un paradigme révolutionnaire.
Avec ses collègues d'Object Mentor, il a condensé les meilleures techniques agiles pour créer du code propre « pendant le développement » dans un ouvrage qui vous inculquera les valeurs du savoir-faire logiciel et améliorera vos compétences en programmation.
Si seulement vous essayiez.
Quel effort est nécessaire ? Il faut lire le code.
Beaucoup de code.
Et pendant que vous lisez le code, vous devriez également réfléchir à ce qui est correct et à ce qui est incorrect dans ce code.
Plus important encore, cela vous amène à réfléchir à vos propres valeurs en tant que professionnel et à votre dévouement à votre travail d'artisan.

Ce livre est divisé en trois parties.
Les premiers chapitres expliquent les principes, les modèles et les pratiques d'écriture d'un code propre.
La deuxième partie présente plusieurs études de cas, dont la complexité ne cesse de croître.
Chaque étude de cas est un exercice de nettoyage de code, c'est-à-dire le remplacement du code problématique par un code plus robuste et plus efficace.
La troisième partie est la conclusion. Le dernier chapitre recense les heuristiques et les « indices » recueillis lors de la création de l'étude de cas.
De ce fait, nous acquérons une base de connaissances qui décrit notre façon de penser lorsque nous lisons, écrivons et organisons du code.


Les lecteurs de ce livre apprendront :

Comment distinguer un bon code d'un mauvais code
Comment écrire du bon code et comment transformer du mauvais code en bon code
Comment écrire de bons noms, de bonnes fonctions, de bons objets et de bonnes classes
Comment formater votre code pour une meilleure lisibilité
* Comment implémenter parfaitement la gestion des erreurs sans perturber la logique du code.
Comment appliquer les tests unitaires et le développement piloté par les tests

Ce livre est une lecture incontournable pour les programmeurs, les ingénieurs logiciels, les chefs de projet, les chefs d'équipe et les analystes de systèmes qui s'efforcent de créer un meilleur code.