10 commandements pour écrire un bon code

Auteur : Alberto Gutierrez
Source : 10 commandments for creating good coden
Date : 04/06/2009

---

Traducteur : Fabrice Aimetti
Date : 12/08/2009

---

Traduction :

1. DRY : ne vous répétez pas.

DRY est habituellement le principe le mieux compris, mais il reste très dur à appliquer.

Cela signifie que lorsque vous trouvez un code similaire à au moins deux endroits, il faut le factoriser dans une nouvelle méthode et transformer les fragments de code précédents pour appeler la nouvelle méthode avec les paramètres appropriés.

DRY est sans doute le principe de codage le plus universel, je n’ai jamais rencontré de développeurs argumentant que répéter du code est bon, j’ai trouvé des développeurs qui oublient ce principe lorsqu’il code des tests unitaires, par exemple : imaginez que vous avez changer l’interface d’une classe qui a beaucoup de tests unitaires, si vous n’avez pas utilisé DRY, vous devrez changer à la main l’appel à l’interface de cette classe pour chacun des cas de tests.

2. Ecrivez des méthodes courtes.

Il y a trois bonnes raisons d’écrire des méthodes courtes.

1) Votre code sera plus facile à lire.
2) Votre code sera plus facile à réutiliser (les méthodes courtes sont susceptibles d’offrir un couplage lâche).
3) Votre code sera plus facile à tester.

3. Utilisez de bons noms pour vos classes, méthodes et variables.

Il n’y a rien de plus agréable que d’utiliser le code développé par un autre et de ne pas avoir à lire sa documentation parce que les noms des classes veulent dire tout ou n’importe quoi, donc, rendez la vie facile à tout le monde et prenez cette approche, passez quelques secondes pour nommer un élément dans votre code.

4. Affecter la bonne responsabilité à chaque classe.

"Une classe, une responsabilité", cela semblera familier à ceux qui connaisse les principes SOLID, mais pas n’importe quelle responsabilité, la bonne responsabilité, donc si on a la classe Customer, nous ne lui assignerons pas la responsabilité de créer un acte de vente, nous lui assignerons juste la responsabilité de gérer toutes les données relatives à un client.

5. Maintenez votre code organisé.

Cette organisation se fait à 2 niveaux :

• Organisation physique : quelque soit la structure que vous employez, packages, espaces de noms, dossiers, … Organisez vos classes de telle façon qu’il soit facile et intuitif de trouver le code.
• Organisation logique : tout ce qui appartient à une même organisation logique doit pouvoir accéder aux autres membres, mais ce qui appartient à une structure logique différente doit être accédé par une interface. Ces groupes logiques sont communément implémentés sous forme de couches, services, ...
  

6. Créez des lots de tests unitaires.

Plus vous avez de tests, mieux c’est, c’est votre filet de sécurité pour tous les changements futurs que nous devrons accomplir dans le code.

7. Refactorez souvent et plus rapidement.

Le développement de logiciels est un processus de découverte continue, afin de maintenir à jour un bon code qui prenne en compte les exigences nouvelles ou modifiées il est essentiel de refactorer le code au fur et à mesure. Comme il s’agit d’une tâche risquée, il y a 2 principales conditions préalables pour éviter de créer de nouveaux bugs dans le système.

1) Avoir beaucoup de tests unitaires.
2) Refactorez par petites étapes. Dans le développement de logiciels, il n’y rien de plus ennuyeux que de démarrer la refactorisation de 2000 lignes de code et après 3 heures de travail de réaliser qu’il est nécessaire de revenir à la version d’origine parce que plus rien ne fonctionne et que la trace des changements en cause est perdue.

8. Commentez, c’est mal.

Ce sujet est un peu controversée, la plupart d’entre nous ont appris que les commentaires sont bons, et en fait il est mieux d’avoir un commentaire dans un morceau de code "obscur" que simplement le code par lui-même, ce que signifie : au lieu d’avoir un commentaire sur un morceau de code obscur il est préférable de ne pas avoir ce code du tout, contentez-vous de le refactorez jusqu’à ce qu’il soit convenable et lisible. Je vous invite à lire cet autre billet pour une meilleure explication de ce que veut dire "commentez c’est mal".

9. Codez une interface, pas une implémentation.

C’est un classique, coder une interface doit nous libérer des détails de la mise en œuvre, nous définissons juste un contrat et nous nous reposons sur l’appel des opérations définies dans le contrat, en comptant sur la fait que le mode d’implémentation réelle nous sera transmis ou décidé lors de l’exécution.

10. Déclenchez des revues de code.

Nous faisons tous des erreurs, et il n’y a rien de mieux que de demander à une autre personne d’examiner rapidement et informellement notre code pour les trouver, afin de faire des revues, il est préférable de ne pas attendre que le code soit terminé, il vaut mieux demander des revues à chaque fois qu’une part de code importante a été terminée ou lorsqu’un certain délai s’est écoulé depuis la revue précédente.