Code review en Java : quoi vérifier et comment donner un retour
Code review (revue de code) est l'un des outils les plus efficaces pour améliorer la qualité d'un produit logiciel et la croissance professionnelle de l'équipe. Cependant, lorsqu'il s'agit de Java, de nombreux développeurs (surtout les juniors) ont soit peur d'envoyer leur code en revue, soit ne savent pas sur quoi se concentrer lors de la vérification du code des autres. Dans cet article, nous allons voir exactement ce qu'il faut vérifier dans le code Java et comment formuler des remarques pour ne pas offenser un collègue, mais l'aider à s'améliorer.
1. Que vérifier dans le code Java : checklist technique
La première chose qui vient à l'esprit est la syntaxe et la logique. Mais une revue professionnelle va bien au-delà de ces limites. Voici les aspects clés à vérifier dans chaque pull request.
1.1. Architecture et conception
Regardez à quel point le nouveau changement s'intègre dans l'architecture existante. Enfreint-il les principes SOLID ? Par exemple, si vous voyez une classe qui fait trop de choses (God Object), c'est une raison de suggérer de la diviser.
- Principe de responsabilité unique (SRP) : Chaque classe doit avoir une seule raison de changer.
- Inversion des dépendances (DIP) : Dépendre des abstractions, pas des implémentations concrètes.
- Design patterns : L'utilisation de singletons, fabriques ou stratégies doit être justifiée, et non appliquée "au cas où".
// Mauvais : la classe connaît à la fois la logique et la persistance
public class UserService {
public void registerUser(String name) {
// validation
// sauvegarde en BDD
// envoi d'email
}
}
// Bon : séparation des responsabilités
public class UserService {
private final UserRepository repository;
private final EmailService emailService;
public void registerUser(String name) {
User user = new User(name);
repository.save(user);
emailService.sendWelcome(user);
}
}
1.2. Performance et gestion de la mémoire
Java est un langage avec gestion automatique de la mémoire, mais cela ne signifie pas qu'on peut oublier l'optimisation. Vérifiez :
- Concaténation de chaînes dans une boucle : Utilisez
StringBuilderouStringBuffer. - Objets superflus : Création d'objets temporaires dans des boucles chaudes.
- Collections : Choix de l'implémentation correcte (par exemple,
ArrayListvsLinkedList). - NullPointerException : Utilisez
Optionalou des vérifications de null.
// Mauvais : un million de chaînes en mémoire
String result = "";
for (String s : list) {
result += s;
}
// Bon : StringBuilder
StringBuilder sb = new StringBuilder();
for (String s : list) {
sb.append(s);
}
String result = sb.toString();
1.3. Gestion des erreurs et exceptions
Une erreur en Java n'est pas toujours un bug. Parfois, c'est une mauvaise utilisation des exceptions. Faites attention :
- Blocs catch vides :
catch (Exception e) {}est un mal. L'erreur doit au moins être journalisée. - Exceptions trop générales : Attraper
ExceptionouThrowableest une mauvaise pratique. - Flux de ressources : Utilisez try-with-resources pour la fermeture automatique.
// Mauvais : on avale l'exception
try {
// du code
} catch (Exception e) {
// on ne fait rien
}
// Bon : on journalise et on propage
try {
// du code
} catch (SQLException e) {
log.error("Erreur lors de l'accès à la BDD", e);
throw new ServiceException("Impossible d'effectuer l'opération", e);
}
1.4. Tests et couverture
Une revue de code sans vérification des tests est une revue "à moitié". Assurez-vous que :