Ecrire du code propre - Les piliers

Le "Clean Code" regroupe plusieurs règles et principes pour vous aider à construire mais surtout refactorer votre code. En effet, comme le disait Michel dans son article sur les artisans du code, le respect de ces différentes règles énoncées par Bob Martin a pour but d'offrir à votre code, entres autres, simplicité, lisibilité et structuration pour qu'il soit le plus évolutif et maintenable possible sur le long terme.

Ce premier article traite des piliers qui vous soutiendront dans votre pratique de l'amélioration de la qualité de votre code.

Préambule : Savoir détecter que notre code à un problème

En plus de l'utilisation d'outils d'analyse de code, il existe quelques indices simples pour nous aider à déterminer si notre code doit être refactoré :

• Des méthodes trop longues (au delà de ~20 lignes)
• Des classes trop longues (au delà de ~200 lignes)
• Une incapacité à lire le code "en diagonale" (il faut se plonger dans chacune des méthodes, des classes pour comprendre ce qu'elles font)
• L'abus de méthodes statiques (qui dénote souvent une violation du principe de la programmation orientée objet)
• Plus de 2 niveaux d'indentation dans une méthode
• Des objets sans méthodes (en dehors des getters/setters) (dans un contexte de POO)

Plus généralement, faites confiance à votre intuition: si vous trouvez que du code est trop compliqué à lire ou à comprendre, qu'il y a quelque chose de "bizarre", de "pas propre", c'est qu'il peut nécessairement être simplifié, amélioré, refactoré !

Les piliers de la pratique du Clean Code

L'amélioration continue

Avant toute chose, pour avoir le code la meilleure qualité possible, il est nécessaire que l'ensemble de l'équipe soit convaincu de la mise en place d'une pratique d'amélioration continue. Sans ça, tout bon Lead Dev/Tech Lead que l'on soit, la plupart des pratiques que l'on poussera sera malheureusement vite abandonnée...

Tests automatisés

Afin de s'assurer que toute action de refactoring n'a aucune incidence sur le fonctionnement de l'applicatif, il est nécessaire de pouvoir s'appuyer sur un ensemble de tests automatisés suffisamment exhaustif pour remonter le moindre problème.

IDE "refactoring-friendly"

L'IDE a une importance non négligeable dans la pratique du Clean Code. En effet, un bon IDE doit nous permettre de faire des micro-refactorings sans douleur (renommage ou extraction d'une variable ou d'une méthode par exemple), voire même les faciliter fortement (répercussion automatique, aide à la décision, etc...).

A l'opposée, un IDE trop basique va avoir tendance à provoquer l'inverse. En effet, si le refactoring est douloureux ou laborieux, le développeur aura souvent tendance à abandonner la pratique.

Boy Scout Rule

"A chaque fois que je parcours du code, je dois essayer de l'améliorer." Cette amélioration peut être seulement une indentation, un saut de ligne ou le renommage d'une variable, du moment qu'il permet de rendre le code plus lisible, plus compréhensible.

Vous trouverez une définition plus complète à cette adresse et une illustration de sa mise en pratique dans ce précédent article.

Revue de code et/ou pair programming

En plus de la Boy Scout Rule, le meilleur moyen pour détecter un problème dans votre code, c'est d'avoir l'avis d'un autre. Que ce soit via du pair programming où vous aurez du feedback en direct ou via de la revue de code, par paire ou en en équipe, c'est vraiment la pratique qui fera la mieux apparaitre les axes d'améliorations de votre code. En effet, pour soi, quand on vient de finir une tâche, il est souvent difficile de prendre suffisamment de recul pour critiquer son travail parce qu'il est encore frais dans notre tête. A ce moment là de notre travail, notre code est souvent "simple" et "clair".

Analyse de code automatisée

La mise en place d'un outil d'analyse de code, type SonarQube, va vous permettre de remonter toutes les violations aux standards du langage/du framework que vous utilisez (amendé en général pour correspondre aux standards de l'équipe), ainsi que le taux de duplication de votre code. Ces indicateurs vont souvent ainsi être les pointeurs d'un endroit où vous pourrez appliquer les principes du Clean Code.

Ce genre d'outil fournit en général un premier bon indicateur sur la maintenabilité du code. Un standard non respecté, c'est déjà une difficulté pour  y rentrer et pour le modifier, le corriger. D'ailleurs, je ne saurai que trop vous conseiller de commencer votre analyse  en utilisant les standards définis par défaut. En effet, ceux-ci correspondent généralement aux standards attendus par la plupart des développeurs du langage/framework. Ça permet donc une meilleure entrée dans le code pour un nouvel arrivant.

Ces outils ne sont malheureusement pas suffisants. Les manques les plus flagrants concernent la pertinence des nommages (les variables/les méthodes/les classes sont-elles bien nommés ?), la structure des méthodes/ des classes(ma méthode/ma classe fait-elle trop de chose ?) et l'architecture du code (est-ce que j'utilise le bon design pattern ? Est-ce que j'hérite bien de la bonne interface ?). Pour combler ces manques, il est nécessaire de mettre en place des revues de code !

Teaser

Les prochaines semaines seront l'occasion pour moi de vous proposer les règles et les principes les plus importants du "Clean Code", illustrés et accompagnés d'astuces pour mieux détecter des violations. Pêle-mêle, j'y aborderai les règles de nommages, SOLID, la loi de Déméter... A la prochaine donc !