Clean Code, du bon sens et de l’empathie

De nos jours, la qualité du code est au centre des préoccupations de managers IT conscients des retombées pour l’entreprise et l’utilisateur final. 
Des nombreux articles sur internet traitent le sujet en donnant des définitions, principes et outils. Le but ici est de vous présenter un avis personnel et synthétique sur le Clean Code et démystifier ce qui peut sembler un sujet « Geek » 
 

Le WHY 
Le 1ere constat c’est qu’en moyenne l’équipe de développement passe env. 70% du temps à maintenir le code existant et 30% à créer du nouveau code. Autrement dit 70% du budget est dépensé en maintenance et 30% pour implémenter des nouvelles fonctionnalités. Ceci fait très mal au portefeuille ! Comment améliorer le ratio ? 
Le deuxième constat c’est qu’en moyenne les développeurs passent 80%-90% du temps à lire et comprendre du code existant et 10%-20% du temps à écrire du code. 
Voilà pourquoi il faut écrire du code « facilement compréhensible » (du Clean Code) par les autres développeurs.  Le Clean Code améliore visiblement la motivation et la productivité des équipes.  
 

Le HOW 
Dans la littérature on décrit de nombreux principes à suivre pour produire un code de qualité :   
• KISS: Keep it simple, stupid 
• DRY: Don’t repeat yourself 
• YAGNI: You ain’t gonna need it 
• The boy scout rule : Leave your code better than you found it 
• RASAP: Refactor as soon as possible 
• Consistent styling & naming 
• SOLID (OOD) 

A mon avis, ce qu’il faut retenir, c’est qu’il faut écrire du code compréhensible par les autres en mettant du bon sens et de l’empathie (il faut se mettre à la place des autres en lisant ton code).  
“Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.” 
 

Les tests  
Je teste mon code, car le test documente la fonctionnalité et rassure le développeur qui doit modifier mon code 
Le formatage et la convention de nommage 
Un formatage uniforme et une convention de nommage claire permet aux autres développeurs de comprendre la logique du code sans avoir à décrypter la forme.  
Le nommage clair documente également la fonctionnalité. 
 

Les commentaires 
Je ne suis pas fan de commentaires, car le « clean code » et suffisamment lisible pour ne pas nécessiter des commentaires. Toutefois, on peut utiliser un commentaire pour transmettre une information importante (qui n’est pas dans le code) aux autres. J’ai un ami qui laisse des blagues en commentaire pour amuser ses collègues développeurs ?  
 

La documentation 
Généralement les premiers jours d’un nouveau développeur dans l’équipe sont consacrés à la lecture de la documentation. Il est important de répondre à toutes ses questions et de lui demander de mettre à jour la documentation en conséquence. La prochaine fois la documentation sera meilleure et plus claire.     
 

La conclusion  
Le métier de développeur est avant tout un métier de communication : ).  A travers le code (langage) on transmet à l’ordinateur ce qu’il doit faire et à nos collègues ce que le code est censé faire.