A destination des "petits jeunes développeurs"

Publié le 21 octobre 2008 par Lanto Randria

Quand je dis "petits jeunes développeurs", je parle de ceux qui viennent de sortir de l'école ou de la fac, et qui arrivent dans le monde merveilleux de l'informatique, en étant développeurs (ou consultants juniors comme ils aiment bien le dire en ce moment).
Cet article pourrait vous être utile, pour vos développements Java/J2EE. Ayant géré une équipe de développeurs, j'ai découvert toutes les petites bêtises (plus ou moins graves selon le cas) qu'un développeur débutant peut commettre. Je vais donc essayer de lister ici ce qui me passe par la tête.

Bien formater le code : sachez que le code que vous allez développer sera repris par quelqu'un d'autre, notamment dans le cadre d'une maintenance. Si le code est "mal écrit" (mal indenté, par exemple), celui qui va le reprendre prendra plus de temps à comprendre le code qu'à le corriger). Demandez si, sur votre projet, il n'existe pas un document sur les normes de codage à respecter. Sinon, un excellent document sur lequel vous pourrez vous baser est celui de Sun
Eviter d'utiliser "System.out.println" : cette méthode devrait être bannie par le compilateur, si ça ne tenait qu'à moi :
1. Quand vous devez développer une application Web, il faut savoir que votre application va tourner en permanence, peut-être même 24h/24. Prenons par exemple le fait que vous affichez l'entrée dans la méthode qui authentifie les utilisateurs : à chaque connexion (réussie ou échouée), vous allez écrire sur la sortie standard, qui est redirigée vers un fichier dans la plupart des cas. Ce fichier va exploser assez vite pour peu que vous avez quelques centaines d'utilisateurs à authentifier par jour
2. Les messages imprimés de cette façon le seront irrémédiablement : plus moyen de les enlever à moins de modifier le code et de recompiler l'application, mais sur un système en production, ce ne sera pas faisable en 15mn
3. Je conseille l'utilisation des frameworks de logging, le plus connu et utilisé étant LOG4J. Il y en a beaucoup d'autres mais celui-ci est le plus facile à mettre en oeuvre à mon avis
Modifier les templates par défaut d'Eclipse : je pars du principe que vous allez développer sous Eclipse. Dans ce cas, je conseille vivement d'aller directement modifier les templates par défaut d'Eclipe (Menu Windows -> Preferences -> Java -> Templates).
1. Changez le template de code pour le bloc "try...catch". Pourquoi ? Parce que celui qui est proposé ne fera qu'afficher la stack trace de votre exception et ne fera rien d'autre. Et comme d'habitude, le développeur est pressé, donc il ne prendra pas la peine de le modifier. Or c'est une des principales sources de bug : on a "catché" une exception, on a imprimé sa stack trace, mais on n'en fait rien.
2. Dans ce cas, mettez donc un nouveau template, en virant en premier l'immonde "e.printStackTrace();" par un autre message d'erreur du style "logger.error("Erreur", e);" (on utilise ici LOG4J, par exemple)
Faire gaffe aux exceptions "étouffées" : prenons un exemple simple
1. ```
 import java.io.*;
 
 class LireLigne 
 {
 public static void main(String[] argv) throws IOException
 {
 BufferedReader lecteurAvecBuffer = null;
 String ligne;
 
 try
 {
  lecteurAvecBuffer = new BufferedReader
 (new FileReader(argv[0]));
 }
 catch(FileNotFoundException exc)
 {
 System.out.println("Erreur d'ouverture");
 }
 while ((ligne = lecteurAvecBuffer.readLine()) != null)
 System.out.println(ligne);
 lecteurAvecBuffer.close();
 }
 } 
 
```
2. (c'est marrant, j'ai piqué le premier code que j'ai trouvé sur le net, et je vois déjà toute ce que je ne souhaite pas voir... )
3. Jettez un oeil au catch : il imprime l'erreur comme quoi il n'arrive pas à ouvrir le fichier (c'est bien !), mais... il n'en fait rien. Pire en core, avec ce code, même si le fichier ne peut pas être ouvert, il va quand même continuer à essayer de lire dedans. Et ça va encore planter sur la ligne suivante. C'est ce que j'appelle "étouffer" une exception : quand on catche une exception :
  1. soit on l'enchaine, en la levant une fois de plus
  2. soit on lève une nouvelle exception (peut-être plus compréhensible que l'exception originale)
  3. soit on ne fait rien, mais dans ce cas, on en assume les conséquences en assurant que ce qui se fait après ne va pas planter. Et dans ce cas, bien mettre dans le code un commentaire disant qu'il est normal que l'exception soit étouffée
Documenter votre code : comme dit plus haut, vous ne serez pas le seul à travailler sur votre code. Ayez donc une pensée amicale à celui qui va le reprendre : ajouter des commentaires utiles à votre code.
1. ne pas en mettre trop pour qu'on ne soit pas noyé dans des commentaires
2. ne pas en mettre peu pour que ce soit quand même compréghensible