Le parcours du Clean Code Developer commence avec le niveau rouge. À partir de là, il s'agit d'intégrer une première partie des éléments de Clean Code Developer dans le travail quotidien et de s'exercer encore et encore. Le niveau rouge est conçu de manière à ce que chaque développeur puisse s'y initier avec un minimum d'efforts. Il ne devrait guère être nécessaire de modifier les conditions du projet. Chacun peut donc commencer son parcours de développeur Clean Code "en toute discrétion".
Table des matières
Principes
Ne vous répétez pas (DRY)
Toute duplication de code ou de manipulations favorise les incohérences et les erreurs.
| Mutabilité | |
|---|---|
| Correction | |
| Efficacité de la production | |
| Amélioration continue | |
| Développeur unique |
Le principe DRY est le suivant Ne vous répétez pas - Ne vous répétez pas. Il s'applique depuis les débuts du développement de logiciels - sinon, il n'y aurait pas de sous-programmes ni de normalisation des données. Pourtant, c'est probablement le principe le plus méconnu. Car rien n'est plus simple que de répéter du code par copier-coller. C'est justement ce qui arrive trop souvent lorsqu'il faut aller vite.
Les développeurs de code propre s'entraînent donc, dans le degré rouge, à toujours respecter ce principe. Ils sont conscients du moment où ils répètent du code ou d'autres artefacts. Ils reconnaissent les répétitions qu'eux-mêmes ou d'autres ont créées. Ils nettoient les répétitions en les refactorisant - si aucun autre principe ou restriction ne s'y oppose.
Keep it simple, stupid (KISS)
En faire plus que le plus simple, c'est faire attendre le client et compliquer inutilement la solution.
| Mutabilité | |
|---|---|
| Correction | |
| Efficacité de la production | |
| Amélioration continue | |
| Développeur unique |
Ou pour reprendre les mots d'Albert Einstein : "Tout devrait être rendu aussi simple que possible, mais pas plus simple". Pour que le code soit modifiable, il faut impérativement qu'il soit compréhensible. Il faut donc toujours privilégier une solution simple, claire et facile à comprendre. Si l'on ne comprend plus son propre code après peu de temps, il faut tirer la sonnette d'alarme. Mais il est encore plus important que les autres développeurs puissent comprendre rapidement le code. Les revues régulières et la programmation en binôme y contribuent. Elles permettent de vérifier si la solution la plus simple a effectivement été utilisée.
C'est justement dans les détails techniques que se cache la tentation de rechercher une solution compliquée. Ce qui est connu et évident est parfois trop "ennuyeux" - et voilà qu'une solution compliquée s'est glissée. Si la solution simple fonctionne également, il faut lui donner la priorité. Il en va de même pour les structures de données. Si une IEnumérable suffit, il ne faut pas ICollection ou même IList peuvent être utilisés.
Attention à l'optimisation prématurée
Les optimisations coûtent toujours beaucoup d'efforts. En faisant preuve de prudence, on économise souvent de précieuses ressources pour les consacrer à ce qui est vraiment utile au client.
| Mutabilité | |
|---|---|
| Correction | |
| Efficacité de la production | |
| Amélioration continue | |
| Développeur unique |
Règle 1 : Ne le faites pas.
Règle 2 (pour les experts uniquement) : Ne le faites pas encore.
La lisibilité du code est toujours au premier plan. Or, le code optimisé est souvent tout sauf lisible. En étant réduit au strict nécessaire dans une forme très courte, il peut certes répondre aux exigences fonctionnelles et non fonctionnelles du client - mais il ne les reflète généralement plus de manière compréhensible. Cela est contre-productif dans le sens de la longévité généralement souhaitée d'un logiciel. Donald Knuth écrivait déjà en 1974 : "...We should forget about small efficiencies, say about 97% of the time : premature optimization is the root of all evil." (Knuth, Donald. Programmation structurée avec go to statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268).
La règle du boy-scout ne signifie donc pas qu'il faut toujours chercher à optimiser le code. Elle se réfère plutôt à son contraire : la compréhensibilité et la mutabilité.
Si le développeur de code propre a envie de gagner un peu de performance en optimisant son code, il devrait y réfléchir à deux fois. D'une part, il détériorerait ainsi la compréhensibilité, mais d'autre part, il est probable qu'une telle optimisation ne soit pas nécessaire pour plusieurs raisons. Si la faiblesse de performance n'est pas seulement ponctuelle et constitue un cas particulier, la prochaine grande refactorisation s'en chargera probablement de toute façon, car elle repose alors sur un problème structurel fondamental. Ou alors, la prochaine génération de matériel informatique corrigera le problème de performance. Ou alors, le client ne se sent pas du tout gêné par ce problème. De toute façon, c'est le client qui doit avoir demandé l'optimisation. Pas de modification de code sans bénéfice attendu par le client. Car ce n'est que pour cela qu'il est prêt à payer.
La règle qui consiste à décider de ne pas optimiser en cas de doute en sous-tend donc une autre, plus fondamentale encore : YAGNI - You ain't gonna need it. Elle ne fait toutefois partie intégrante, dans sa pleine expression, que du bleu.
PS : Si, en dépit de tous les avertissements et de toutes les réserves, une optimisation des performances s'avère inévitable, elle ne devrait être entreprise que sur la base d'une analyse détaillée avec un profileur. En effet, seul celui qui a localisé de manière compréhensible les goulets d'étranglement en matière de performance avec un profileur peut vérifier pendant et après l'optimisation si et dans quelle mesure il les a élargis.
Favour Composition over Inheritance (FCoI)
La composition favorise le couplage lâche et la testabilité d'un système et est souvent plus flexible.
| Mutabilité | |
|---|---|
| Correction | |
| Efficacité de la production | |
| Amélioration continue | |
| Développeur unique |
Pour la réutilisation de fonctionnalités, la programmation orientée objet (POO) connaît deux candidats très connus : L'héritage (whitebox - reuse) et la composition (blackbox - reuse). Si l'on utilise à nouveau des fonctionnalités en les dérivant d'une classe, la sous-classe dépend de la classe parente. Dans de nombreux cas, cela rend le système inutilement complexe, moins facile à tester et plus difficile à échanger en cours d'exécution. CCD a mis au point le principe de substitution de Liskov (LSP) pour une dérivation correcte, qu'il convient de respecter.
Lors de la composition, une classe en utilise une autre. Si l'on utilise pour cela une interface clairement définie, cela favorise le découplage. Il est également possible d'échanger facilement différentes implémentations. Avant de se confronter à la substitution de Liskov, Favour Composition over Inheritance demande donc de se demander si l'on ne peut pas donner la priorité à la composition.
„Comme l'héritage expose une sous-classe aux détails de son implémentation parentale, on dit souvent que 'l'héritage rompt l'encapsulation'.". (Gang of Four 1995:19)
Principe d'intégration des opérations de ségrégation (IOSP)
Les profondes hiérarchies de dépendance fonctionnelle sont un symptôme évident d'un code mal transformable. Elles réduisent la compréhension et compliquent les tests automatisés comme le refactoring.
| Mutabilité | |
|---|---|
| Correction | |
| Efficacité de la production | |
| Amélioration continue | |
| Développeur unique |
Lorsque des instructions générant un comportement (logique) sont mélangées dans des méthodes avec des appels à d'autres méthodes de la même base de code, il n'est plus possible de voir clairement comment le comportement global est généré ; les instructions sont en effet réparties sur une hiérarchie qui peut être très profonde. De plus, les méthodes avec un tel mélange ont tendance à croître indéfiniment.
L'IOSP s'y oppose par une séparation claire :
- Soit une méthode ne contient que de la logique, c'est-à-dire des transformations, des structures de contrôle ou des appels d'E/S ou plus généralement d'API. Dans ce cas, elle est Opération est appelé
- Ou bien une méthode ne contient aucune logique, mais uniquement des appels à d'autres méthodes de la même base de code. Dans ce cas, elle est Intégration est appelé
Cette distinction stricte a plusieurs effets positifs :
- Les méthodes ont tendance à rester très courtes. En effet, plus de 10, 20 ou 30 lignes de logique pure ou exclusivement d'appels de méthodes "ne font pas bon effet". Le mélange n'étant pas autorisé, d'autres petites méthodes sont extraites.
- Les méthodes courtes qui ne contiennent que de la logique sont faciles à tester, car elles n'ont pas de dépendances.
- Les méthodes courtes qui ne contiennent que de la logique sont comparativement faciles à comprendre. Le nom de la méthode peut vraiment être porteur de sens.
- Les méthodes courtes, qui intègrent exclusivement, sont très faciles à comprendre et décrivent "en un coup d'œil" ce qui se passe.
- Il est très facile de vérifier l'exactitude des intégrations en les observant de visu. Il suffit de constater si les étapes de traitement sont en principe disposées dans le bon ordre. Le compilateur se charge du reste - ou de la couverture de test des opérations.
- Les intégrations peuvent être facilement étendues en "intercalant" d'autres méthodes afin de répondre à de nouvelles exigences. La compréhension reste intacte.
L'IOSP peut être appliqué "au pied levé" par tout développeur de bonne volonté. Son respect est facile à vérifier par tout un chacun. Les intégrations et les opérations se distinguent nettement par leur forme. D'autres détails, notamment sur la délimitation avec le Principe d'inversion de dépendance (DIP), tu trouveras par exemple ici.
Pratiques
Règle du Boy Scout
Chaque fois que l'on s'occupe d'un objet, on le rend au moins un peu meilleur. Sans aucune planification bureaucratique. Une base et une racine pour une meilleure qualité.
| Mutabilité | |
|---|---|
| Correction | |
| Efficacité de la production | |
| Amélioration continue | |
| Développeur unique |
Le système de valeurs des développeurs Clean Code ne s'établit pas en une seule fois. Il faut du temps pour cela. D'autant plus qu'un Clean Code Developer travaille rarement sur un terrain vierge et de surcroît seul, il est difficile d'appliquer les principes à l'ensemble d'une base de code. Nous pensons donc qu'il est important de ne pas se fixer des objectifs trop élevés. Il est bien plus réaliste et motivant de ne viser que de petits progrès - mais continus.
Pour nous, la règle scoute fait donc partie du fondement du Clean Code Development. Elle se trouve également dans Code propre et est le suivant : Laisse toujours un lieu dans un meilleur état que celui dans lequel tu l'as trouvé.
Appliqué au développement de logiciels, cela signifie que les développeurs de code propre laissent toujours le code dans un "meilleur état" que celui dans lequel ils l'ont trouvé. Une fois le travail terminé, le code est donc plus conforme au système de valeurs de Clean Code Development qu'avant.
Ce qu'un Clean Code Developer a fait pour cela dépend de la situation/du code - et est naturellement aussi déterminé par le niveau auquel il travaille. Au niveau rouge, un Clean Code Developer veille par exemple à ce que le code qui n'était pas encore dans le Repository de la gestion des versions y soit désormais déposé. Et il veille à ce que les répétitions de toutes sortes - c'est-à-dire les violations du principe DRY - soient "corrigées".
Là où un développeur Clean Code constate des sous-optimalités au sens du système de valeurs CCD, il s'efforce donc en permanence de les améliorer. Par petites étapes. Et bien sûr, il s'efforce d'éviter les sous-optimalités dès le départ. Comme nous l'avons dit : toujours au niveau de son développement.
Cette maxime se trouve au début du développement du Clean Code Developer en pensant aux Théorie des fenêtres brisées. Selon elle, la dégradation de la qualité au sens général du terme commence par des détails qui ne sont ignorés que suffisamment longtemps.
Mais si les développeurs de code propre travaillent selon la règle du scout, il n'y a pas de "fenêtres cassées" - celles qui existent sont réparées une par une. La règle du scout comble systématiquement les "fissures et irrégularités" dans le code sur la base du système de valeurs CCD, de sorte qu'aucun autre "dépôt" ne puisse s'accumuler. Elle lutte ainsi de manière proactive contre l'érosion du code. Nous considérons que c'est tellement fondamental que nous l'avons incluse dans le degré rouge.
Analyse des causes profondes
Traiter les symptômes peut apporter un soulagement rapide, mais à long terme, cela demande plus d'efforts. En regardant plutôt sous la surface des problèmes, on finit par travailler plus efficacement.
| Mutabilité | |
|---|---|
| Correction | |
| Efficacité de la production | |
| Amélioration continue | |
| Développeur unique |
Dès le premier jour en tant que développeur Clean Code, la règle devrait être de toujours rechercher intensivement la véritable racine du mal en cas de problème. Les développeurs Clean Code ne se contentent pas d'un traitement des symptômes. Exemple : le tri des données en mémoire est trop lent. Une cure superficielle s'attaquerait maintenant à l'accélération de certaines instructions ou de certains blocs d'instructions. On essaiera peut-être d'utiliser du code non sécurisé, voire de le paralléliser. Une analyse plus approfondie du problème aurait toutefois révélé qu'un algorithme sous-optimal est à la racine du mal. Les optimisations difficiles à comprendre à un niveau d'abstraction inférieur peuvent donc être évitées. Un meilleur algorithme est la solution propre.
L'analyse du problème racine est donc un service rendu à la compréhension et à l'effort. En effet, si le problème racine est connu, le nettoyage est généralement moins coûteux qu'un traitement des symptômes. Si le développeur de code propre rencontre un problème, la première chose qu'il fait est donc de s'arrêter pour se donner une chance de regarder au-delà des symptômes.
La Root Cause Analysis est également connue sous le terme de Five Why's (cinq raisons). Ce terme est issu de la terminologie du Toyota Production System (TPS). L'idée de base est de demander au moins cinq fois "pourquoi".
Système de contrôle de version
La peur d'endommager un "running system" paralyse le développement de logiciels. Avec une gestion des versions, une telle crainte n'est pas fondée. Le développement peut progresser rapidement et avec audace.
| Mutabilité | |
|---|---|
| Correction | |
| Efficacité de la production | |
| Amélioration continue | |
| Équipe |
La condition sine qua non pour tout développeur de code propre est de placer son code sous la protection d'un système de contrôle de version. Qu'il s'agisse de Mercurial, Git, Subversion, VSS, TFS ou Vault, cela n'a aucune importance. Nous pensons simplement qu'aujourd'hui, aucun travail ne devrait être effectué sur du code sans le maintenir dans un système de contrôle de version. La raison en est très simple : un système de contrôle de version libère de la peur. Et l'absence de peur est nécessaire pour mettre en œuvre avec courage les principes et les pratiques du système de valeurs CCD.
Un système de contrôle de version élimine la peur de faire quelque chose de mal et donc de le casser. Si le code est conservé en son sein, chaque CCD peut le modifier à sa guise sans craindre de détruire un état atteint. Rien ne se perd. Le système de contrôle de version est comme une machine à remonter le temps pour le code.
Un système de contrôle de version est donc la meilleure base pour tout apprentissage. Car apprendre, c'est faire des erreurs. Avec un système de contrôle de version comme filet de sécurité, nous pouvons nous permettre toutes les erreurs. C'est pourquoi : la première condition pour se lancer dans le Clean Code Development est l'utilisation permanente d'un système de contrôle de version.
Lorsque cela n'est pas possible dans le projet, nous considérons que les bases du Clean Code Development sont absentes. Nous ne comprendrions pas non plus pourquoi l'utilisation d'un outil de contrôle de version ne serait pas possible. Il n'y a pas de coûts à prévoir et l'apprentissage des fonctions les plus simples est minime. CCD n'impose pas l'utilisation d'un système de contrôle de version, mais seulement l'obligation d'en utiliser un.
Voir aussi sous Outils.
Refactorings simples
Il est plus facile d'améliorer le code quand on connaît les gestes typiques d'amélioration. Leurs scénarios d'application rendent sensible aux points faibles de son propre code. En tant que modèles reconnus, ils renforcent le courage de les appliquer.
| Mutabilité | |
|---|---|
| Correction | |
| Efficacité de la production | |
| Amélioration continue | |
| Développeur unique |
Pour laisser un code toujours un peu meilleur que celui que l'on a trouvé, des interventions plus ou moins importantes sont nécessaires. Grâce au système de contrôle de version, un développeur de Clean Code peut le faire sans crainte. Mais comment se simplifier la tâche ?
Le mot clé est "refactorisation". Martin Fowler a fait le Refactoring/Refactoring dans son livre du même nom comme technique de base pour améliorer la qualité du code. Il y définit un certain nombre de schémas de modification du code afin de nettoyer les "code smells", c'est-à-dire les structures sous-optimales ou, plus généralement, le non-respect des principes.
Pour le degré rouge, il s'agit avant tout de la refactorisation Extraire la méthode pertinents pour satisfaire au principe DRY. Les Clean Code Developers les appliquent pour extraire le code apparaissant plusieurs fois dans une méthode qui sera appelée à sa place aux endroits de répétition.
Comme deuxième refactorisation, lors du travail sur le degré rouge, le Renommer être utilisés là où c'est nécessaire. Elle s'inscrit dans la règle scoute, car une "impureté" souvent rencontrée dans le code source sont les noms cryptés.
Les refactorisations peuvent être appliquées à la main, mais il existe également des outils de support. Les IDE modernes tels que Visual Studio proposent quelques modèles de refactoring, d'autres outils sont listés dans notre Liste d'outils.
Le "refactoring" comme le "clean code" font partie de la Lecture obligatoire de chaque développeur Clean Code à partir du niveau rouge.
Pour plus d'informations, voir aussi refactoring-legacy-code.net.
Réflexion quotidienne
Pas d'amélioration, pas de progrès, pas d'apprentissage sans réflexion. Mais ce n'est que si la réflexion est également planifiée qu'elle aura lieu sous la pression des affaires courantes.
| Mutabilité | |
|---|---|
| Correction | |
| Efficacité de la production | |
| Amélioration continue | |
| Développeur unique |
Le développement personnel est au cœur de CCD. Il s'agit donc de changement : chaque jour, le système de valeurs CCD doit se manifester un tout petit peu plus dans le quotidien du projet du Clean Code Developer. C'est la règle du scout du Clean Code Developer appliquée à lui-même.
Un tel chemin de changement n'est toutefois pas facile à parcourir seul. Comment maintenir le cap ? Comment mesurer les progrès ?
Sans vouloir établir un "système de contrôle", nous pensons que cela implique deux choses :
- Planification par petites étapes
- Réflexion après chaque étape
Indépendamment des directives d'une direction de projet, les développeurs Clean Code devraient répartir leur travail de manière à ce qu'il se compose de tâches à accomplir en une journée de travail. C'est la seule façon de faire un bilan le soir de chaque journée. Nous estimons que c'est important pour ne pas emporter chaque jour le travail avec soi à la fin de la journée. Il n'a rien à faire là ; celui-ci sert à se détendre.
Ces petites étapes de planification ne rendent pas seulement le travail quotidien plus satisfaisant, car elles permettent de décider chaque jour du succès ou de l'échec. La simple possibilité de prendre une décision le soir - Est-ce que j'ai terminé toutes mes tâches ? Comment ai-je accompli mes tâches ? - permet également de réfléchir au respect du système de valeurs Clean Code Developer.
Pour devenir de manière conséquente un développeur de code propre, le développeur doit, à chaque degré, se rendre compte après chaque journée de travail s'il a pris en compte tous les aspects du système de valeurs qui sont pertinents pour lui selon le degré. Pour le degré rouge, cela signifie par exemple des questions telles que : Est-ce que je gère vraiment tous les fragments de code dans le système de contrôle de version ? Est-ce que j'ai appliqué le principe DRY de manière conséquente ? Est-ce que, de manière générale, j'ai laissé le code dans un meilleur état que celui dans lequel je l'ai trouvé ?
S'il doit répondre à l'une de ces questions par un oui hésitant ou même par un non, ce n'est évidemment pas grave. Malgré tous les efforts, il n'est pas toujours possible de traduire sa bonne volonté en actes.
Néanmoins, ou justement pour cette raison, il convient de faire ce qui suit :
- Soit le développeur de code propre fait des améliorations jusqu'à ce qu'il ne perçoive plus de violation de principe dans son travail quotidien.
- Ou alors, il inscrit les violations de principes reconnues sur sa liste de tâches pour le lendemain.
Une aide à la réflexion peut être le Clean Code Developer Bracelet être. Nous sommes conscients que le port d'un bracelet en silicone coloré n'est pas du goût de tout le monde. Ceux qui n'y voient aucun problème peuvent utiliser le bracelet dans le cadre de leur réflexion personnelle. Si le développeur Clean Code ne peut ou ne veut pas corriger la violation du principe ou l'inscrire sur sa liste de travail, il devrait changer le bracelet qu'il porte d'un bras à l'autre. Il montre ainsi clairement qu'il reconnaît une différence entre ce qu'il doit faire et ce qu'il a fait. Cela ne doit pas être mal interprété comme une défaite ou même comme une "pénitence". Il s'agit plutôt d'un soutien haptique au processus d'apprentissage.
Si un développeur de code propre n'a pas eu à changer de bracelet pendant 21 jours après avoir terminé son travail, il peut passer au travail du degré suivant. Pour le grade rouge, il s'agit du degré orange.
Français 
Deutsch 
English 
Español