1 of 100

Clean Code

Clément Defaux

Redouane Boutraa

Sébastien Laoût

2 of 100

Qui sommes-nous ?

2

Sébastien Laoût

Développeur full-stack (Java / TypeScript) depuis 13 ans

Principalement sur de l'e-commerce

Actuellement Tech Leach chez Auchan

Chez Ubik Ingénierie depuis 9 ans

Clément Defaux

Développeur Java & Spring Boot (+ de la CI et du front)�A travaillé chez Adeo / Leroy Merlin�Actuellement chez Decathlon

Chez Ubik Ingénierie depuis 3 ans

Redouane Boutraa

Développeur full-stack depuis un peu plus d'un an�Back-end Java et Node.js / front-end Angular, JSP et EJS

Actuellement chez Brico Dépôt

Chez Ubik Ingénierie depuis moins d'un an

3 of 100

Auteur : Robert C. Martin�Date de publication : Août 2008

3

Clean Code: A Handbook of Agile Software Craftsmanship

Définitions multiples :�Certains choix sont subjectifs.

4 of 100

4

Plan

Objectifs
Exemple en fil rouge
Principes & méthode
Ⓐ Nommage
Ⓑ Paradigmes & classes
Ⓒ Fonctions
Refactoring

Des questions ?

Prenez-note ✏ :

5 of 100

Exemple : avant

5

6 of 100

Exemple : après

6

7 of 100

Objectifs

7

8 of 100

Objectifs

Compréhensible par tous
Facilement maintenable
Réduit la complexité
Indépendant du développeur initial

8

9 of 100

Exemple

9

10 of 100

Spécifications fonctionnelles

Mapper une ligne de base de données vers un objet Java

Une ligne a :� un libellé� un intervalle de validité dans le temps

Une ligne peut :� être supprimée (historisée) : grisée� être active : en surbrillance

10

11 of 100

11

12 of 100

12

13 of 100

13

14 of 100

14

15 of 100

15

16 of 100

16

17 of 100

17

18 of 100

18

19 of 100

19

20 of 100

Principes

&

méthode

20

21 of 100

Principes

KISS : Keep It Simple Stupid
DRY : Don’t Repeat Yourself
YAGNI : You Aren’t Gonna Need It
La règle du boy scout

21

22 of 100

Nous sommes des traducteurs Français ↔ Informatique

Réduction de 50 % si le produit périme dans les 4 jours�

discount = daysUntilExpiration <= 4 ? percent(50) : NO_DISCOUNT;

↕

22

https://programmation.developpez.com/actu/305505/Des-scanners-cerebraux-revelent-que-le-codage-use-des-memes-regions-que-celles-liees-au-traitement-du-langage-naturel-suggerant-que-la-programmation-requiert-plus-d-aptitudes-en-langues-qu-en-maths/

Désolé de vous l’apprendre : nous sommes des littéraires !

On raconte une histoire, juste dans une langue un peu plus exotique.

Notre métier est de nommer des concepts.�On implémente les spécifications fonctionnelles au moyen de : variables, fonctions, classes, packages, écrans, composants

On doit tout nommer pour pouvoir s’y retrouver.

C’est une étape importante pour comprendre le code.

Mais aussi pour chercher où / quoi modifier pour rajouter une fonction ou corriger un bug, et évaluer l’impact sur tout le projet.

Ici, percent() peut retourner un float/double ou construire un BigDecimal : c’est du détail technique qu’on cache. Idem : NO_DISCOUNT peut valoir 0, BigDecimal.ZERO, ou null… le sens métier est gardé dans le code, et les détails techniques sont abstrait / encapsulés.

23 of 100

Méthode

Les règles métier doivent être limpide dans le code

Via le nommage�
Puis via le découpage en petites fonctions :�Chaque fonction fait une seule chose et bien�Chaque fonction a un seul niveau d’abstraction�
Puis via l’organisation des fonctions en classes�Chaque classe a sa propre responsabilité�Chaque classe encapsule ses détails techniques

23

24 of 100

Nommage

24

25 of 100

Pas d’abréviations ni de noms imprononçables

⛔ config + conf + cnf + cfg 🔎�✅ configuration

⛔ pdt ❓❗�✅ pediatry ? pedometer ?� periodicity ? ponderation ?� postdate ?� product ? production ?� pendant ? pommeDeTerre ?

⛔ generationYmdhms 📣�✅ generationTimestamp�🥇 generationDateTime

25

NE JAMAIS ABRÉVIER

�CLEAN

C’est la toute première règle du Clean Code.

Ne JAMAIS, AU GRAND JAMAIS abrévier !

Toujours utiliser des mots entiers.

Pourquoi ?

Tout le monde abrévie à sa façon.

On doit souvent faire une étude d’impact quand on va modifier un concept.

Il faut alors rechercher toutes les abréviations possibles dans le projet.

Et on n’est jamais sûr d’avoir cherché toutes les combinaisons.

En se tenant à ne jamais abréger, on peut être confiant de rechercher juste “configuration” dans tout le projet.

On est assez confiant de maîtriser tous les impacts d’un refactoring de ce concept.

Une abréviation peut dire énormément de choses différentes.

C’est rapide à écrire.

Mais le code est lu bien plus de fois qu’il n’est écrit.

Prenez une seconde de plus pour écrire les mots entiers.

Et personne ne perdra un temps fou à se demander ce que le code veut dire.

Si vous voulez gagner du temps à l’écriture, utilisez l’autocomplétion.

Même en connaissant la signification de PDT dans un ancien projet, je n’arrêtais pas de penser à “pomme de terre” en le voyant.

Restez prononçable.

Ici, on a Year, Month, Day, etc.

C’est descriptif, mais imprononçable.

On lit beaucoup plus le code qu’on ne l’écrit.

Mais on en parle aussi beaucoup entre collègues, techniques ou métier.

Essayer de prononcer ce champ de manière fluide dans une conversation…

Mieux vaut dire timestamp, qui est un concept technique bien compris.

Ou encore mieux : date-time : comme ça, même le métier le comprendra en discutant de l’implémentation de leur spécification.

Supprimé :

Seule exception : on travaille avec une bibliothèque qui nous force à utiliser une abréviation : on va rester cohérent avec leur nommage (axios.config).

⛔ dt�✅ date / detentionTheorique

Ancien :

⛔ pro / prd / prod / pdt�✅ product / professional /� production / pommeDeTerre

26 of 100

Pas d’abréviations : dans l’exemple

26

27 of 100

Est-ce que PriceDetails�est un nom assez descriptif ?

27

Au fait...

28 of 100

Sans parasites

⛔ Variable, Value, Data, Info, Details, Manager, Processor

⛔ Order orderObject; ✅ order

⛔ class PriceInfo {} ✅ Price

⛔ class PriceDetails {} ✅ PriceTimeline / PricingPlan

⛔ String eanString; ✅ String ean 🥇 Ean13 ean // Not EuropeanArticleNumbering13

⛔ String strName; ✅ name

⛔ List<Long> idList; ✅ ids

⛔ void fStart(int pSpeed) { _player.fRun(pSpeed); }�✅ void start(speed) { player.run(speed); }

⛔ interface ICar {} ✅ interface Car {}� ICar iCar = new Car(); Car car = new CitroenCar() // PeugeotCar... or CarImpl

List<String> names = new LinkedList<String>()

28

Ensuite, on va voir qu’on veut nommer pour expliquer ce que le code fait.

Donc on va déjà commencer par bannir tous les parasites qu’on pourrait retrouver dans les noms :

Data, Info, Value, Variable, Manager, Processor�On est en informatique : notre but est de gérer de la données / des informations, et les variables contiennent des valeurs / les classes gèrent ou traitent des données.�Donc pas de mots fourre-tout, mais pas de préfix/suffixe qui va dupliquer le typage :

Order orderObject; // En POO, tout est Object order

class PriceInfo {} // En informatique, tout est information Price

class PriceDetails {} // Quoi en plus d’un Price ? Et si deux classes de détails différentes ? PriceTimeline

String nameString; // Redondant et inutile name�String strName; // Pire name�List<Long> idList; // Et si on change le type en Set<Long> ? ids suffira et sera concis

interface IBidule {} // Une interface est vouée à être utilisée à la place de l’implémentation. Suffixer Impl, plutôt, pour rendre évident qu’on doit manipuler directement ces objets le moins possible

class Order { List<OrderData> orderData; } // List<OrderItem> items;�// order.getItems() et pas order.getOrderItems() : “order” est redondant dans le contexte de la classe Order

void fStart(int pSpeed) { mPlayer.fRun(pSpeed); } // La notation hongroise n’a pas été inventée pour ça

De même, pas de préfix / suffix “p” pour les paramètres, “m” pour les variables membres, “c” pour les constantes… On verra qu’un paramètre de fonction peut être extrait en variable membre, etc.

Pas de “I” pour interface : et si la classe devient une classe abstraite pour rajouter du code commun ? Ou une enum car son nombre d’implémentations est fixe ?

Par contre, on *peut* rajouter le suffixe “Impl” pour les implémentations : le code client utilisera l’interface sans fioriture.

Supprimé pour ne pas trop rallonger la présentation :

⛔ class Order { List<OrderData> orderData; }�✅ class Order { List<OrderItem> items; }

29 of 100

Sans parasites : dans l’exemple

29

30 of 100

Révéler l'intention

À quoi sert la variable / méthodes / classe ?�⛔ List<Integer> list = …�✅ List<Integer> flags = …�🥇 EnumSet<Flag> flags = …

Comment peut-on l’utiliser ?�⛔ overridePrice(Product productA, Product productB)�✅ overridePrice(Product source, Product destination)

Expliquer “pourquoi” au lieu de “comment”�⛔ String getBarcodeReplacingNumbersUsingSmurfAlgorythm()�✅ String getBarcodeTextForFont()

30

Il est important de prendre tout son temps pour nommer les choses.

Un nom doit :

Expliquer clairement le “pourquoi” (de la variable, de la fonction)
Et pas le “comment” (pas de détail d'implémentation)
Utiliser un glossaire commun
Utiliser des mots communs pour ce qui se ressemble
Utiliser des mots différents pour ce qui ne doit pas être confondu

Exemple :

String getBarcodeString() : on sait déjà que la méthode retourne une String. Mais que contiendra-t’elle ? Comment renommer ça ?
1) énoncer en une phrase bien construite ce que la méthode doit faire, et de façon détaillée pour éviter toute ambiguïté :�"encoder un code-barres dans un texte qui sera bien interprété par une police de caractères"
2) mettre en évidence les concepts importants et réduire autant que possible, mais pas plus�encodeEanToTextThatCanBeInterpretedByTheSpecialFont()
3) tester plusieurs formulations, puis en sélectionner une
4) raffiner si nécessaire
String getBarcodeEncodedValue() : déjà, on sait que la méthode ne retourne pas le code-barre tel qu’imprimé, mais il encode comment ? Et pourquoi ?
String getBarcodeTextForFont() : mieux : on retourne une représentation textuelle du code-barres pour une police de caractères particulière.

Voici des noms qu’on a évalué avant de retenir le nom final :

encodeEanToFontText
encodeEanForSpecialFont
encodeEanForFont
getCodeForBarcodeFont
encodeEanForFont, pour éviter deux "code"s (même si ce sont deux codes différents) ? Mais on pige pas tout de suite que c'est pour un code-barres
encodeEanForBarcodeFont
getEncodedEanForBarcodeFont

31 of 100

Révéler l'intention : dans l’exemple

31

32 of 100

Expliquer les concepts : cohérent & cherchable

Mots communs pour ce qui se ressemble�✅ Product (pas Article)�✅ Cart (pas Shopping Cart, ni Shopping Basket)�✅ Voucher (pas Coupon, ni Token)

Mots différents pour ce qui ne doit pas être confondu�✅ Site = Magasin (“site d’implantation” dans tout le SI)�✅ Store = Le store Vue.js (ne pas utiliser pour décrire un magasin)

Glossaire commun au projet et au métier

32

Retenir un seul mot par concept : garder une cohérence pour montrer qu’on parle de la même chose.

Établir un glossaire pour l’application, partagé avec le métier.

Le métier va souvent utiliser plusieurs synonymes, voir mélanger les concepts : bien expliquer que dans le projet, tel mot aura telle signification.

Avec ça, on pourra faire une recherche sur tout le code pour comprendre toutes les manifestations du concept.

Petit bonus : quand deux concepts ont le même nom, essayer de leur donner un nom différent. Exemple, si le métier parle indifféremment de magasin ou de site, on a le choix entre “store” et “site”. “store” est plus correct, mais correspond à un concept Vue.js qu’on retrouve partout dans le projet. On va suivre l’autre nom qu’utilise le métier : “site” pour pouvoir rechercher le concept de magasin dans trouver des résultats relatifs au store.

Détails additionnels mais sans grande importance pour ce talk light :

Noms de classes : des noms :�✅ Order�✅ AddressParser

Noms de méthodes : commencer par un verbe :�✅ postPayment�✅ deletePage�✅ set* / get* / is* / has* / are*

33 of 100

Cohérent & cherchable : dans l’exemple

33

34 of 100

Que mettez-vous�dans les commentaires ?

34

Au fait...

35 of 100

Déplacer les commentaires dans les noms et / ou le typage

⛔�int DD = 3; // Default duration (in minutes)

⛔�int DD = 3; // Default duration (in minutes)��⚠️�int DURATION = 3; // Default (in minutes)

🚸�int DEFAULT_DURATION = 3; // In minutes

✅�int DEFAULT_DURATION_IN_MINUTES = 3;

🥇�Duration DEFAULT = Duration.ofMinutes(3);

35

A common fallacy is to assume authors of incomprehensible code will somehow be able to express themselves lucidly and clearly in comments.

Kevlin Henney

On sait tous que les commentaires ne sont que rarement mis à jour quand le code change. Ils finissent par ne plus être en phase avec le code, ou le code a été supprimé / déplacé, le commentaire a été copié en trop avec un autre code copié…

La plupart du temps, si vous avez envie d’ajouter un commentaire, réfléchissez-y à deux fois : le code n’est peut-être pas compréhensible : il est possible de le rendre plus explicite en nommant juste bien les concepts manipulés :

int v = 3; // Default duration (in minutes)

Ou même :

int defaultDuration = 3; // In minutes

Ce n’est visible qu’à la déclaration, et pas quand on l’utilise, donc on préférera :

int defaultDurationInMinutes = 3;

Ou mieux :

Duration defaultDuration = ofMinutes(3);

Notez l’import static pour que le code reste concis et concentré sur le but métier.

Dans une minorité de cas, il est bien sûr primordial de garder un commentaire. S’il aide à clarifier / informer le pourquoi d'un code complexe, ou mettre en garde contre une modification qui pourrait paraître anodine !

Un commentaire peut montrer la nécessité d’une variable intermédiaire explicative.

Mais bien sûr, il ne faut pas être redondant avec du code trivial :

// If we roll a 6 with the die�if (die.roll() == 6) {

36 of 100

Paradigmes

36

37 of 100

Les paradigmes de programmation

POO

Procédurale

Evénementielle

AOP

Réactive

Composant

Prototype

Contrat

?

37

38 of 100

Java == JavaScript ?�

38

Au fait...

39 of 100

Structure de données == Objet ?�

39

Au fait...

40 of 100

Les structures hybrides ?

40

Types ou Fonctions ?

Types

Fonctions

Création d’une structure de données

Création d’objets

Représentent une conception confuse

Assemblent le pire des deux mondes

?

41 of 100

Ce qu’il faut retenir ?

41

Structure de donnée

Objet

Facilite l’ajout de nouvelles fonctions

sans modifier les structures de données existantes

Facilite l’ajout de nouveaux types�(Classes, Interfaces) sans modifier les fonctions existantes

42 of 100

Exemple : les formes Géométriques

42

Structure de donnée

Objet

Interface Shape
Functions périmètre aire

Class Circle Square Triangle
Attributes List<Points> ...

Class Circle Square Triangle
Attribute Point longueur largeur ...

Class Géométrie
Functions aire périmètre ...

43 of 100

Classes

43

44 of 100

Principe de responsabilité unique

44

Une classe ne doit changer que pour une seule raison

45 of 100

Principe de responsabilité unique

45

Une classe ne doit changer que pour une seule raison

Faire de petites classes

Maintenir la cohésion

Peu de variables

46 of 100

Fonctions

46

47 of 100

Heuristique des fonctions

47

Une fonction ne doit faire qu’une seule chose, n’avoir qu’un seul but

Nommage de fonction avec un seul verbe

Faire des fonctions courtes

searchProfileAndRefund()

private Profil searchProfil(int id){� …

}

private void refund(Profil profil){

...�}

48 of 100

Heuristique des fonctions

48

Une fonction ne doit faire qu’une seule chose, avoir qu’un seul but

Faire des fonctions courtes

Nommage de fonction avec un seul verbe

Avoir le moins d’arguments de fonction possible

Éviter les arguments boolean

private Profil searchProfil(int id, String username){� …

}

private void refund(Profil profil, boolean isConnected){

...�}

49 of 100

Heuristique des fonctions

49

Une fonction ne doit faire qu’une seule chose, avoir qu’un seul but

Faire des fonctions courtes

Nommage de fonction avec un seul verbe

Avoir le moins d’arguments de fonction possible

Éviter les arguments boolean

Avoir un seul niveau d’abstraction par fonction

Écrire les fonctions appelées sous la fonction appelante

refund(Profil profil){

String url = “http://myAccount”;

String port=”8080”;

profil.getCardNumber();

}

refund(Profil profil){

getConnection();

profil.getCardNumber();

}

50 of 100

Refactoring

50

51 of 100

51

52 of 100

52

53 of 100

53

54 of 100

54

55 of 100

55

56 of 100

56

57 of 100

57

58 of 100

58

59 of 100

59

60 of 100

60

61 of 100

Suivons les principes du Clean Code pour refactorer

Le nommage est déjà bon

Extraire chaque responsabilité dans une méthode courte

Réorganiser toutes ces méthodes dans des classes cohérentes

61

62 of 100

La métaphore de l’article de presse

Avoir une vue globale

Plonger dans les détails uniquement si besoin

Hiérarchiser pour faciliter la décision

62

Titre 1�Sous-titre 1�Paragraphe d'accroche 1�Corps de texte�en pyramide inversée

Titre 2�Sous-titre 2�Paragraphe d'accroche 2�Corps de texte�en pyramide inversée

Titre 3�Sous-titre 3�Paragraphe d'accroche 3�Corps de texte�en pyramide inversée

63 of 100

La métaphore de l’article de presse

Avoir une vue globale�Plonger dans les détails uniquement si besoin�Hiérarchiser pour faciliter la décision

63

entryPoint() {

stage1();

stage2();

}

stage1() {

actionA();

actionB();

}

stage2() {

actionC()

actionD()

}

actionA() {

// Fonction courte

}

actionB() {

// Fonction courte

}

actionC() {

// Fonction courte

}

actionD() {

// Fonction courte

}

64 of 100

64

65 of 100

65

66 of 100

66

67 of 100

67

68 of 100

68

69 of 100

69

70 of 100

70

71 of 100

71

72 of 100

72

73 of 100

73

74 of 100

74

75 of 100

75

76 of 100

76

77 of 100

Liens

77

78 of 100

Vidéos

Clean Code - Uncle Bob�(leçons 1 à 6 résumant le livre de manière vivante)�https://www.youtube.com/watch?v=7EmboKQH8lM&list=PLmmYSbUCWJ4x1GO839azG_BBw8rkh-zOj

Exercices de nettoyage de codes de Victor Rentea�(excellent pédagogue)�https://www.youtube.com/playlist?list=PLggcOULvfLL_MfFS_O0MKQ5W_6oWWbIw5

78

79 of 100

Les Code Smells du livre

https://moderatemisbehaviour.github.io/clean-code-smells-and-heuristics/

79

80 of 100

Aides mémoire de refactoring

https://drive.google.com/drive/folders/1hvLAWeAgT753Mkb8zaHxNyBYwCewuWbb (par Victor Rentea)

80

81 of 100

Questions ?

81

82 of 100

Crédits des images

Titre :�Plan :�Exemple :�Objectifs :�Principes & méthode :�Nommage :�Révéler l'intention :�Cherchable :�Au fait... :�Fonctions :�Classes :�Refactoring :�Liens :��Questions ? :

82

83 of 100

WARNING

OPINIONS MAY VARY

Voici nos interprétations subjectives�suite à la lecture du livre

83

84 of 100

Spécifications fonctionnelles

Étant donné� Un utilisateur sportif� Il / elle reçoit des recommandations sur ses sports favoris

Quand� Il / elle veut se désinscrire d’un sport donné

Alors� On supprime ce sport dans les favoris de l’utilisateur� On garde un historique de la suppression

84

85 of 100

85

86 of 100

Pas d’abréviations : dans l’exemple

idx => index / indices

nb => count

86

87 of 100

Révéler l'intention : dans l’exemple

ref => sharedId / personId

constantes uniques => dans le code

:v_id => :share_id et :person_id

87

88 of 100

Cohérent & cherchable : dans l’exemple

register => historize

88

89 of 100

Humainement & fonctionnellement compréhensible : dans l’exemple

Avant : une soupe technique de 175 lignes

Après : ces 11 lignes métier :

89

90 of 100

Nommer les nombres magiques

⛔�if (player.getHealthPercentage() < 10) {� game.slowDown();�}

✅�static final int MINIMUM_GOOD_HEALTH_PERCENTAGE = 10;�if (player.getHealthPercentage() < MINIMUM_GOOD_HEALTH_PERCENTAGE) {� game.slowDown();�}

🥇�if (player.hasBadHealth()) {� game.slowDown();�}

90

Exemple 2 : ???

Magique = sémantique inconnue (signification / but)

if (player.getHealthPercentage() < 10) {

game.slowDown();

}

Qu'est-ce que ce 10 ?

Et si == 10 ? La condition à la limite n'est pas claire

=>

static final int MINIMUM_GOOD_HEALTH_PERCENTAGE = 10;

if (player.getHealthPercentage() < MINIMUM_GOOD_HEALTH_PERCENTAGE) {

game.slowDown();

}

On sait qu'un pourcentage de santé à plus de 10 est une bonne santé.

On sait aussi que 10 étant le minimum de bonne santé, il n'y a pas de bug où "<" aurait dû être "<=".

Notez qu’on parle de magic number, mais ça peut être des chaînes, ou tout autre objet…

=> constantes ou enum !

Il y a des exceptions :

// Un pourcentage est par définition x/100, donc pas besoin de constante HUNDRED_PERCENT ici

return percentage > 100 : 100 : percentage;

<< Plus tard, on verra que : >>

if (!player.hasGoodHealth()) {

game.slowDown();

}

if (player.hasBadHealth()) {

game.slowDown();

}

// On a le même niveau d’abstraction sur les deux lignes : le concept “BadHealth” :

if (player.hasBadHealth()) {

game.startBadHealthMode();

}

Game::startBadHealthMode() {

slowDown();

screen.displayBadHealth(); // Tint with redish screen (NOT screen.setRed())

}

91 of 100

Que mettez-vous (ou pas)�dans des constantes ?

91

Au fait...

92 of 100

Utiliser des variables intermédiaires

⛔�if (captain.getAge() >= 18) { captain.drink(alcohol); }

✅�boolean hasMajority = captain.getAge() >= 18;�if (hasMajority) { captain.drink(alcohol); }

🥈�boolean canDrinkAlcohol = captain.getAge() >= 18;�if (canDrinkAlcohol) { captain.drink(alcohol); }

🥇�if (captain.canDrinkAlcohol()) { captain.drink(alcohol); }

92

Pour clarifier des calculs pas maniant différents concepts et / niveaux d’abstraction, ou calculs un peu longs.�=> On verra qu’on pourra extraire des méthodes pour faciliter la réutilisabilité et la séparation des abstractions.��if (captain.getAge() >= 18) { ... }

Quel rapport entre l’âge du capitaine et le corps du if ?

Vous allez me dire qu’ici, pas besoin de constante pour 18, ni même de variable intermédiaire, car on sait tous ce qu’un âge au moins égal à 18 veut dire : on est majeur. Mais il vaut mieux l’expliciter :

boolean hasMajority = captain.getAge() >= 18;

if (hasMajority) { ... }

Ici, on découple le traitement dépendant de la majorité, de l’implémentation de ce que veut dire “avoir la majorité”.

Et quand on regarde le code du if, on se rend compte que ça parle de boire de l’alcool. Ce n’est pas forcément lié à la majorité, comme aux États-Unis, donc on va mieux nommer les concepts, et on utilisera plutôt :

�boolean canDrinkAlcohol = captain.getAge() >= 18;

if (canDrinkAlcohol) { captain.drink(alcohol); }

On a ainsi le même niveau d’abstraction entre la condition du if et le code exécuté dans le if : c’est en rapport avec l’alcool.

TODO : à déplacer dans les méthodes ? :�Plus tard, on verra que cette logique DOIT être déplacée dans la classe Captain/Person : en explicitant cette variable, on peut la chercher dans le projet et se rendre compte que la connaissance de cette “toute petite règle métier” est dupliquée à plusieurs endroits :

if (captain.canDrinkAlcohol()) { captain.drink(alcohol); }

Mais aussi pour simplifier du code complexe :

public boolean isEditable() {

return !(getTarget() == System.A

? isSentToSystemA()

: getSystemBSendDate() != null &&

!getSystemBSendDate().isBefore(now())) ||

!(getFailureMessage() == null);

}

public boolean isEditable() {

boolean sentToSystemA = isSentToSystemA();

boolean sentToSystemB = getSystemBSendDate() != null &&

!getSystemBSendDate().isBefore(now());

boolean sendingRequested = getTarget() == System.A

? sentToSystemA

: sentToSystemB;

boolean sendingDidNotFail = getFailureMessage() == null;

boolean wasSentSuccessfully = sendingRequested && sendingDidNotFail;

return !wasSentSuccessfully;

}

93 of 100

Humainement & fonctionnellement compréhensible

Le code EST la spécification ultime : il doit transpirer le fonctionnel, et pas la technique

⛔ boolean canChangePrice(Product product) {� List<Error> productErrors = form.getErrors().get(product.getId());� return (errors == null || error.size() == 0) &&� (product.getStatus() == NEW || product.getStatus() == ACTIVE) &&� product.getSupplier().getStartDate().isBefore(LocalDateTime.now());�}

✅ boolean canChangePrice(Product product) {� return hasNoError(product) &&� product.isEditable() &&� product.hasActiveSupplier();�}

93

On doit pouvoir le montrer au métier. Les spécifications (quand elles sont écrites), changent régulièrement… ou leur implémentation a dû les améliorer… Ou une correction de bug a nécessité une modification de règle. Bref, la seule source de vérité, c’est le code : c’est lui que les utilisateurs voient en production. Le métier va souvent demander ce qui est actuellement en production : vous devriez pouvoir lui montrer le code. S’il est enrobé ne serait-ce qu’un peu de technique, c’est que le code n’est pas assez clair.

Loi de Demeter (petites fonctions qui forcent à découpler, et à rendre le code plus réutilisable : DRY) :

product.getSupplier().getStartDate().isBefore(LocalDateTime.now());

=>

Product.hasActiveSupplier() { return supplier.isActive() }

Supplier.isActive() { return startDate.isBefore(LocalDateTime.now()); } }

94 of 100

Humainement & fonctionnellement compréhensible : dans l’exemple

94

95 of 100

Fonctions

Petites�Ne faire qu'une seule chose�Un seul niveau d'abstraction�Ordonnées�Switch�Arguments : peu, et pas de booléen�Pas d'effet secondaire�Command/Query Separation�Ne pas retourner de codes d'erreurs�La gestion d’erreurs est une chose à part

95

96 of 100

96

97 of 100

Objectifs → Avantages

Compréhensible par tous
Facilement maintenable
Réduit la complexité
Indépendant du développeur initial

97

98 of 100

Retours d’expériences

98

99 of 100

Retour d’expérience

99

Sébastien

Des petites fonctions / classes, ça paraît extrémiste�On s’y essaye, pour voir�Et on découvre tous les avantages : simplicité, organisation, réutilisation

Clément

TODO

Redouane

TODO

Retour d'expérience de Sébastien :

J'essaye toujours de trouver la tournure de code qui va rendre la logique métier évidente en quelques lignes simples.

Et cacher les détails techniques : bien hiérarchiser les niveaux d'abstractions.

De temps en temps, je me dis qu'ils vont trop loin : des méthodes de 3 lignes, c'est peu.

Je pense que c'est plus un idéal à atteindre : pas forcément un but.

En ne serait-ce qu'en découpant un peu les fonctions, on gagne énormément.

Par exemple, j'ai une condition d'un if qui prend 2 ou 3 lignes à exprimer : j'extraie le calcul de la condition dans une fonction.

Déjà, ça lui donne un nom qui explique pourquoi on fait ces 2 ou 3 lignes de calculs.

Mais surtout, peu de temps après, je me rends compte qu'il faut tenir compte de plusieurs cas à la marge pour l'initialiser différemment : donc rajouter des ifs pour initialiser la condition.

Avoir ça dans une méthode à part laisse libre possibilité de s'exprimer, faire plusieurs returns en fonction de conditions, etc.

Là où si ça avait été dans la fonction principale, on se serait restreint à faire des choses plus courtes pour ne pas exploser le nombre de lignes de cette méthode principale : ça aurait été moins expressifs, on aurait des if dans des if, la complexité aurait grimpé pour rien.

Là, le calcul de la condition est bien isolé dans sa méthode : on peut se concentrer juste sur CE calcul à l'intérieur, et rien d'autre.

Bref : on est plus zen avec le Clean Code :-)

100 of 100

Liens

Projet GitHub d’exemple :�https://github.com/clementdefauxubik/clean-code-example�Demander l’accès à Clément :�c.defaux@ubik-ingenierie.com

100