Chacun de ces points est à mettre en oeuvre le plus tôt possible, plus le temps passe et plus le coût est élevé pour revenir dans une démarche de qualité.
Bonne pratiques de développement
Structuration des projets
Un projet devrait contenir un minimum de dépendances entre les modules. La seule raison motivant un découpage de garantir l'indépendance des cycles de vie. Un projet IHM possédants des script de traitement par lot devrait être structuré de la manière suivante :
- Un projet-parent
- Un projet dao + business + service
- Un projet IHM (war)
- Un projet batch
- Un projet factorisant le code de test (Constitution de jeu de test)
- Un jeu de test de référence
- Un jeu de test restreint
- Un jeu de test à volumétrie normale
Recommandations
Utiliser des interfaces uniquement si nécessaire, quand il existe une probabilité réelle qu'une interfaces ait plusieurs réalisations.
Ne pas se servir des exceptions pour remonter des codes d'erreurs.
Bonnes pratiques de codage de tests unitaires
Un test unitaire doit pouvoir partir d'une base vierge
Dans les tests junits dérivés de spring, vérifier que les méthodes d'extraction communes sont dans la méthode onSetUp().
Penser à valider le programme par des jeux de test importants. Si certains tests génèrent des erreurs en occupant trop de mémoire, il vaut mieux ne pas masquer le problème en augmentant la taille mémoire sur la machine de développement. Sur le long terme, il vaut mieux résoudre résoudre le problème par la conception sans utiliser la puissance du matériel.
Bonnes pratiques d'écriture
La manière de coder peut améliorer la reprise du code dans le cas de maintenance. Il est possible d'utiliser des outils de type checkstyle ou PMD. Toutefois, ces outils ne sont pas toujours pertinents parce que trop verbeux.
Formater le code de manière homogène en utilisant un outils de formatage automatique
Mettre des commentaires quand c'est nécessaire
Sur la couche DAO : vérifier que les noms de méthode sont cohérents entre eux
Vérifier que les noms de variables permettent de deviner leur contenu
Vérifier que les tests unitaires donne des messages explicite en cas de plantage (pas de fail sans argument)
Ne pas utiliser les séquences : « ? : » pour les tests if. Toujours mettre des crochets
