By

Les 10 Commandements du Développeur

Cela fait maintenant quelques années que je développe, et j’ai toujours l’espoir qu’un jour cette activité (le développement) soit reconnu comme une fin en soi (tout le monde n’a pas envie de devenir chef de projet!!!).

Dans ma recherche d’amélioration continue de cette activité, j’ai compilé ici plusieurs bonnes pratiques que je considère comme indispendables pour bien faire mon travail.

Amis développeurs, n’ayez plus peur de dire que vous aimez ce que vous faites, et que vous avez envie de bien le faire !

Les plus avertis auront remarqué que j’ai repris les différents points énoncés par cet article de l’excellent blog making good software et que j’ai librement interprétés.

1. DRY : Don’t Repeat Yourself! (Ne vous répétez pas!)

DRY est le principe le plus simple à comprendre, mais le plus complexe à appliquer. Il implique que si vous trouvez du code similaire à plusieurs endroits, vous devez l’abstraire en une unique méthode et modifier les fragments impliqués.

DRY est surement le principe de développement le plus universel qui soit. Personne n’a jamais osé proner que répéter du code est la meilleure des façon de développer. Cependant, il existe beaucoup de développeurs qui l’oublient bien vite, par exemple lors du codage des tests unitaires; par exemple si vous changez l’interface d’une classe possédant beaucoup de tests unitaires, si vous n’avez pas appliquer DRY, vous aurez à manuellement modifier tous les appels de tous les tests qui sont impactés par ce changement.

2. Ecrire des méthodes courtes

Il y a trois très bonnes raisons d’écrire des méthodes courtes :

  • Votre code sera plus facile à lire

  • Votre code sera plus facile à réutiliser (les méthodes courtes sont susceptibles de produire un couplage lâche).

  • Votre code sera plus facile à tester

3. Utiliser des noms explicites pour vos classes, méthodes & variables

Il n’ya rien de plus agréable que d’utiliser le code d’un autre développeur et de ne pas avoir à lire la documentation car les noms des classes et des méthodes sont suffisamment claires et explicites quand à leur comportement. Cela simplifie la vie de tout le monde.

4. Attribuer la bonne responsabilité à chaque classe

Une classe, une responsabilité. Cela peut sembler évident, mais au delà de ce principe simple, encore faut il donner la bonne responsabilité. Par exemple, considérons une classe ClientEjb, il est évident qu’elle ne devra pas permettre de réaliser une opération de vente. Le périmètre de sa responsabilité correspond aux données et actions inhérentes au Client

5. Garder votre code organisé

Une organisation à deux niveau :

  • L’organisation physique : Quelle que soit la structure que vous utilisez, concernant les paquets, les espaces de noms, des dossiers, etc… organisez vos classes de telle sorte qu’il soit facile et intuitif de trouver l’endroit où le code est stocké.

  • L’organisation logique : Tout ce qui appartient logiquement aux uns devraient être accessible aux autres membres, mais ce qui appartient à une structure logique différente devrait être accessible par une interface. Ces groupes logiques sont généralement mis en oeuvre sous forme de couches, services …

6. Créer une multitude de Tests Unitaires

Plus vous en aurez (de pertinent), mieux ce sera. Ils sont votre assurance face aux changments que vous aurez à faire dans le futur.

7. Refactorer le plus vite possible et le plus souvent possible

Le développement logiciel est un processus continu de découverte. Tenir à jour un bon code source en adéquation avec les nouvelles exigences / évolutions est essentiel. Comme il s’agit d’une tâche risquée, il y a 2 principales conditions préalables pour éviter d’entrer de nouveaux bugs dans le système :

  • Avoir beaucoup de (bons) tests unitaires

  • Faire le refactoring par petites touches. Rien n’est plus deplaisant et inutile que de s’apercevoir que votre refactoring de 2000 lignes de codes (qui vous aura pris 3 bonnes heures) ne sert finalement à rien et que vous devez revenir à la version originale

8. Les commentaires c’est le mal!

Celui-ci en particulier est un peu controversée. La plupart d’entre nous ont appris que les commentaires sont bons, et en fait c’est mieux d’avoir un commentaire dans une pièce obscure de code que d’avoir juste le code lui-même. Ce que ce point signifie est que plutot que d’avoir à écrire un commentaire pour éclairer une partie obscure de code source, il serait surement plus interessant de refactorer ce code obscure pour qu’il devienne à son tour lisible et clair (voir §7).

9. Coder par Interface, pas par Implementation

Il s’agit là d’un classique. Le codage par Interface va vous libérer des détails d’implémentation. Vous n’aurez plus qu’a définir le contrat, et de vous appuyer sur l’appel à ce contrat.

10. Faire des revues de code

Nous faisons tous des erreurs, et il n’y a rien de mieux que de demander à une autre personne un examen rapide et informel de notre code pour les trouver, et il est préférable de ne pas attendre trop longtemps. Il vaut mieux demander des commentaires quand une partie importante du code a été effectuée ou lorsque quelques jours se sont écoulés depuis l’examen précédent.

[print_link]