Personnellement, ce que je reproche le plus à un développeur, ce n'est pas de faire des boulettes, ça arrive (j'aurais tendance à davantage reprocher à leurs responsables de ne pas les avoir assez encadrés). C'est de ne pas tester ce qu'il fait, parce que là c'est carrément un manque de conscience professionnelle.
Un petit exemple de code PL/SQL, réalisé par un gars qui bossait depuis un an sur la même application (J2EE et énormément de PL/SQL)... Syntaxe peut-être approximative, PL/SQL n'est pas ma tasse de thé. Etonnamment, ça n'a jamais marché. Plus étonnant encore, ça n'a été découvert qu'à la mise en production, après que la maintenance soit passée chez nous.
Quelques petits bouts que j'ai pu voir aussi :SELECT COUNT(*) INTO v_count FROM table WHERE /* des conditions */;
IF count != -1 THEN
RETURN code_erreur;
END IF;
if (machin.equals(null)) { ...J'ai également eu droit à un superbe bloc d'une centaine de lignes, dont je n'ai jamais été complètement sûr de ce qu'il faisait. Après tests et étude algorithmique, il me semblait bien que la réponse était "absolument rien" (parcours de listes et de maps en tous sens avec ajouts et suppressions pour revenir au final à l'état initial). Faute de temps pour vraiment vérifier, j'ai mis un commentaire pour signaler le fait. Je suis sûr qu'il y est encore aujourd'hui.List result = new ArrayList();
for(int i = 0; i<myList.size(); i++) {
result.add(myList.get(i));
if (/* je sais plus quels critères */) {
result.remove(myList.get(i));
}
}
En vrac, dans la catégorie style pourri, je demande la JSP d'environ 9000 lignes avec davantage de code Java que de balises. Dans la catégorie "incompétent roi du monde", je connais un "expert technique" (c'est son titre officiel) qui explique que la mutualisation de code c'est mal : si il y a un bug dans une fonction réutilisée, on va le retrouver partout...
Partager