• Services informatiques
  • Centre d’expertises
    • Département Data
    • Département Développement
    • Département DevOps
    • Département Microsoft
  • Recrutement
  • Agences
    • Genève
    • Grenoble
    • Lausanne
    • Zürich
  • Actualités
  • Contact
  • Offres d’emploi
  • Facebook
  • Instagram
  • LinkedIn
  • Twitterqiminfo-twitter
  • EN

Le Clean Code par Benoît

Qim info > Tech > Le Clean Code par Benoît
01 Déc

Le Clean Code par Benoît

Clean Code : du code pour les humains

Le travail du développeur consiste à écrire du code compréhensible par des machines.
Mais dans le monde de l’industrie être compris par les machines ne suffit pas : dans l’immense majorité des projets sur lesquels nous intervenons, un même code source est manipulé par plusieurs personnes. C’est là que tout se complique car se faire comprendre par des humains n’est pas aussi facile que de se faire comprendre par des machines.

Pour qu’une application puisse évoluer correctement il faut que le code de celle-ci puisse être adapté par n’importe quel développeur. Si ce n’est pas le cas, le coût pour faire évoluer l’application va augmenter exponentiellement avec le temps. C’est là qu’on peut faire une distinction entre le code efficace et le code propre (clean).

 

Mesurer la lisibilité du code

Comment déterminer si un code est clean ? Ou plutôt à quel point un code est clean ?
Instinctivement on pense à Sonar (en tout cas dans le monde Java) qui donne des mesures sur la complexité, la vulnérabilité, la couverture de test du code. Mais un outil informatisé ne peut pas déterminer à quel point le code sera compréhensible par un autre développeur.
Le meilleur indicateur pour cela, c’est le WTF/M :

The only valid measurement of code quality: WTFs/minutes (source: osnews.com)

Au-delà du mème, l’illustration montre le but recherché par le clean coder : faire diminuer le taux de WTFs/Minutes c’est-à-dire augmenter la lisibilité de son code.

 

Clean code : le livre
Comment établir des normes pour le clean code ?

Certaines pointures du développement logiciel ont essayé de répondre à cette question.
Une des plus célèbres, Robert C. Martin (alias Uncle Bob), s’est penché sur les principes qui définissent un code source de qualité dans son livre « Clean Code: A Handbook of Agile Software Craftsmanship ».


ISBN : 9780136083238

Les principes de programmation énoncés dans ce livre ne sont pas des règles à appliquer strictement, il faut les considérer plutôt comme des aides ou des inspirations.

 

Clean code: les principes

Les principes développés dans ce livre sont des principes généraux, agnostiques du langage de programmation utilisé.

  • Le code doit être simple : C’est la première caractéristique du clean code. Il faut éviter autant que possible de complexifier le code en se demandant si la solution implémentée est la plus simple pour répondre au besoin. Plus le code est simple plus il est lisible, plus il sera maintenable dans le futur ; il y a un acronyme qui nous aide à nous rappeler ce principe : KISS (Keep It Simple Stupid).
    Pour cela il convient d’éviter la sur-configurabilité et de proscrire tout ce qui est écrit « au cas où ».

 

  • Le code doit être ciblé (focused) : Un bout de code doit être écrit pour résoudre une et une seule problématique. C’est valable à tous les niveaux d’abstraction du code : méthode, classe, package ou module. Le travail de réflexion autour du découpage du code doit permettre de déterminer les bonnes abstractions*, ainsi les responsabilités de chaque bout de code seront correctement réparties. On retrouve ici les principes SOLID notamment le “ Single Responsibility Principle”.

 

  • Le code doit être testable : Si le code est simple et n’a qu’une seule responsabilité il devrait être facile à tester. Les tests constituent une sécurité contre les régressions qui peuvent intervenir lors de l’évolution du code. Ils sont également la documentation qui permet aux autres développeurs de comprendre le fonctionnement du code testé. Ils doivent être écrits de préférence avant le code productif (TDD) et être dans la mesure du possible automatisés.
    Encore un acronyme qui caractérise les “clean” tests : FIRST (Fast, Independent, Repeatable, Self-Validating, Timely).

 

* Bad abstraction is worse than duplication : deux bouts de codes peuvent être identiques, s’ils représentent des concepts différents il vaut mieux conserver cette duplication « accidentelle ». Dans ce cas le principe DRY (Don’t Repeat Yourself) ne s’applique pas.

 

Les principes du Clean Code sont très nombreux et couvrent toutes les phases de la programmation :

  • Le nommage des fichiers, des classes, des méthodes et des variables
  • Le design des fonctions
  • Le traitement des erreurs
  • Les tests
  • Les commentaires (à limiter au maximum)
  • Le formatage du code
  • Les logs

 

Vous en trouverez un florilège ici.

Le but de cet article n’est pas de tous les lister et/ou les résumer mais plutôt de dire à ceux qui peuvent passer des heures à chercher le meilleur nom pour une classe qu’ils pourront trouver des guidelines dans ce livre.

Vous vous souvenez de la deuxième loi de la thermodynamique ? Lorsqu’un système évolue l’entropie augmente inévitablement. C’est pareil pour les systèmes d’information : lorsqu’on adapte le code source d’une application, il est toujours plus dur de ne pas complexifier le code que d’implémenter l’évolution elle-même. Autrement dit, plus le système évolue plus il difficile à maintenir.
« Clean Code » nous invite à combattre l’entropie en proposant des normes pour que le code soit compréhensible par les humains qui le feront évoluer après nous.

Benoît.

Catégorie : Tech
Retour à la liste
Catégories
  • Evénements (9)
  • News (48)
  • Non classé (3)
  • Projets (9)
  • Qimlife (24)
  • Retours d'expérience (10)
  • Tech (8)
Tags
accueil Agile ALMD Blockchain Carouge Collaborateurs Convivialité DataScience Equipe dynamique Genève grenoble Happy IA interview intégration Kempinski Lausanne Microsoft Qim info Qimtalks QimTeam Recrutement Retours d'expérience Soirée Suisse TruGeneva Welcome Workshop Zürich
Archives
  • décembre 2020 (4)
  • novembre 2020 (8)
  • octobre 2020 (5)
  • septembre 2020 (6)
  • juillet 2020 (2)
  • juin 2020 (2)
  • mai 2020 (1)
  • mars 2020 (1)
  • février 2020 (2)
  • janvier 2020 (1)
  • décembre 2019 (3)
  • octobre 2019 (5)
  • juillet 2019 (4)
  • juin 2019 (6)
  • mai 2019 (4)
  • avril 2019 (1)
  • mars 2019 (3)
  • février 2019 (1)
  • janvier 2019 (1)
  • juillet 2018 (1)
  • mai 2018 (1)
  • avril 2018 (3)
  • mars 2018 (2)
  • janvier 2018 (2)
  • novembre 2017 (2)
  • octobre 2017 (3)
  • septembre 2017 (2)
  • juin 2017 (1)
  • mai 2017 (1)
  • mars 2017 (3)
  • février 2017 (1)
  • janvier 2017 (1)
  • décembre 2016 (2)
  • novembre 2016 (2)
  • octobre 2016 (1)
  • septembre 2016 (1)
  • août 2016 (2)
  • juin 2016 (3)
  • mai 2016 (1)
  • avril 2016 (2)
  • mars 2016 (3)
  • février 2016 (1)
  • janvier 2016 (2)
  • décembre 2015 (4)
  • novembre 2015 (1)
  • octobre 2015 (2)
  • septembre 2015 (1)
Qim info
  • Accueil
  • Services informatiques
  • Centre d’expertises
  • Recrutement
  • Genève
  • Grenoble
  • Lausanne
  • Zürich
  • Actualités
  • Offres d’emploi
  • Contacter

Politique de protection des Données Personnelles

Dispositif d’alerte



Genève

Rue du Tunnel 15-17
1227 Carouge

+41 (0) 22 304 15 00

Lausanne

Place Bel-Air 1
1003 Lausanne

+41 (0) 21 341 15 00

Grenoble

47 chemin du Vieux Chêne
38240 Meylan

+33 (0)4 85 85 00 60

Zurich

Talstrasse 83
8001 Zurich

+41 (0) 44 201 01 34

Copyrights © 2020 All Rights Reserved