Blog Arolla

What Is Clean Code?

(Résumé du début du livre Clean Code de Robert C. Martin)

Rappelons-nous que le code est vraiment la langue dans laquelle nous exprimons en fin de compte les exigences.

N’importe quel logiciel est constitué de code, nous pouvons créer des langages qui sont au plus près des besoins business, nous pouvons créer des outils qui nous aident à analyser et traduire ces exigences, mais il y aura toujours du code, et plus ce code est clean plus le logiciel est maintenable et évolutif.

Mais comment doit être un code clean? C’est le but de cet article.

Bad Code

Vous avez déjà été considérablement gêné par le mauvais code, vous avez sûrement senti cet obstacle plusieurs fois, mais pourquoi l’avez-vous écrit ? Si vous êtes développeurs, vous avez forcément écrit un jour du mauvais code, c’est inévitable, et les raisons sont multiples, et certainement bien claires dans vos têtes:

  • Essayer d'aller vite.
  • Pas de temps à perdre sur cette feature.
  • Vous n'avez pas eu le temps de faire un bon travail.
  • Votre patron serait en colère contre vous si vous preniez le temps de nettoyer votre code.
  • Peut-être que vous étiez fatigué de travailler sur ce programme et vous vouliez que ce soit fini.

Peu importent les raisons, le point commun à cette session de mauvais code est toujours une promesse malheureusement vite dite et vite oubliée, “je nettoierai plus tard”.

Une fois que notre code marche, on se dit : un mauvais code qui marche, c'est mieux que rien, puis on passe à autre chose avec l’idée de nettoyer plus tard, sauf que Plus tard est égal à jamais.

Seulement voilà, plus les features s’accumulent, plus le mauvais code est présent, et moins votre logiciel est maintenable, ce qui se traduit par une productivité de l'équipe qui ne cesse de diminuer, et qui tend finalement vers zéro. Ce qui nous mène à la nécessité de réécrire le code, proprement cette fois ci, afin d’y voir plus clair

Graph Clean Code

Clean code ?

Vous êtes  bien conscient qu’un mauvais code est un obstacle important, et la seule façon d’aller vite est de garder le code propre.

La question qui se pose est "Comment pouvez-vous écrire du code propre", il n'est pas possible d'essayer d'écrire du code propre si vous ne savez pas ce que cela signifie!

  • Un code propre est avant tout un code qui doit être agréable à lire.
  • Un mauvais code permet au désordre de grandir! Plus on a des bouts de code mauvais, plus la qualité de notre logiciel tend vers la décadence.
  • Un code propre doit prêter attention aux détails et doit être est focalisé, chaque fonction, chaque classe, chaque objet expose une attitude simple qui reste entièrement indépendante, et non polluée par les détails non nécessaires.
  • Un code propre doit clairement exposer le problème à résoudre et ne doit contenir que ce qui est nécessaire.
  • Il y a  une différence entre le code qui est facile à lire et le code qui est facile à changer, un code propre doit être facile à améliorer par d'autres personnes.
  • Un code non testé n’est pas un code propre, peu importe s'il est lisible et accessible.
  • Un code propre est un code qui a été pris en charge par quelqu'un qui a pris le temps de rester simple et ordonné.
  • Ne contient pas de duplication.
  • Un code propre est aussi un code qui réduit au maximum le nombre d'entités telles que les classes, méthodes, etc.
  • Évident, simple et convaincant: quand on lit un code propre, on ne doit dépenser trop d’effort pour le comprendre,

Savoir si le code est propre ou mauvais n’est pas suffisant, comment peut-on écrire un code propre ?

Plusieurs techniques et bonnes pratiques faciles à adopter existent pour aider à écrire un code propre : nommage explicite de vos fonctions et variables – se passer de commentaires le plus possible, fractionnement de votre code en de multiples petites fonctions et bien d’autres … ce sera le sujet de mes prochains articles.

En attendant n’oubliez jamais, ce sont les programmeurs qui font que le langage paraît simple!

Plus de publications

7 comments for “What Is Clean Code?

  1. Issam
    15 novembre 2013 at 15 h 15 min

    Très bon article et très bon livre, incontournable des “clean” développeurs 🙂
    J’attends la suite…

  2. Agbani
    15 novembre 2013 at 15 h 41 min

    Description de la problématique très claire et détaillé, Merci pour vos efforts.

  3. NOUALI
    15 novembre 2013 at 16 h 01 min

    Bel article intéressant et bien expliqué.

  4. griffon db
    30 juillet 2014 at 8 h 36 min

    Je trouve que c’est un article pour les gens qui ne sont pas de vrais développeurs.

    Un vrai développeur n’écrit jamais du mauvais code et, je fais remarquer que :

    Un développeur fait ses tests quand il a la possibilité de les faire, c’est-à-dire quand il peut compiler et tester l’ensemble du logiciel ce qui n’est pas toujours le cas dans une équipe de développement. Pour pouvoir compiler et tester, les meilleures pratiques sont de faire des bouchons ou des applications à côté pour pouvoir tester les fonctions une à une, sans nécessairement avoir besoin de l’ensemble complet du logiciel.
    Si les tests sont réalisés par d’autres personnes, le développeur a tout intérêt a écrire du code excellent pour ne pas freiner le travail des testeurs. Ecrire du code excellent d’un coup, c’est être un excellent développeur.
    Un mauvais code est aussi un code qui est succède les gaffes sur les appels de méthodes : par exemple, un objet que l’on traduit en string puis que l’on stocke dans un fichier et à chaque fois, on relit le fichier pour recréer l’objet. Bah, ça c’est juste que c’est mal conçu et souvent c’est parce que le développeur était stressé pour toute sorte de raison. La chose à faire : réfléchir et se concentrer très profondément.

    Pour conclure, suite à un bogue, les développeurs ne sont pas égaux dans la résolution : il y a ceux qui ne cherchent pas à savoir et qui contournent le bogue et il y a ceux qui essaient de comprendre ce qui ne va pas en déroulant dans sa tête le processus du logiciel développé afin de trouver exactement ce qui doit être corrigé. Le bon développeur, c’est la deuxième solution. Cette réflexion assure aussi que ce qui a été mis en oeuvre correspond à ce qui a été demandé et, pas à côté.

  5. 3 décembre 2014 at 22 h 18 min

    It’s not just about how you write the code but how you organize it. The design is actually the one boosting the stability and ease (or speed) of maitenance later on.

    Using specific frameworks or even languages makes it easyer for you to write quality code.

    All in all, it’s about the business owner paying the money. If they pay for bad code, it’s their fault and they should accept the consequences (extra costs).