Revue de code Java : ce que recherchent les seniors et comment ne pas échouer la revue de code

Revue de code Java : ce que recherchent les seniors et comment ne pas échouer la revue de code

Vous avez écrit du code, testé localement, lancé les tests — tout est vert. Vous ouvrez une Pull Request et quelques heures plus tard, vous voyez une dizaine de commentaires de votre collègue senior. Cela vous dit quelque chose ? La revue de code Java n'est pas une procédure bureaucratique, mais un véritable examen de la maturité du développeur. Les seniors voient le code différemment : ils ne vérifient pas seulement s'il fonctionne, ils regardent combien de temps il fonctionnera et à quel point il sera difficile à modifier.

Dans cet article, nous allons analyser les remarques les plus fréquentes que les développeurs Java expérimentés laissent lors des revues de code. Vous apprendrez à écrire un code propre et maintenable et à passer la revue du premier coup.

1. Ignorer les principes SOLID et l'architecture propre

C'est sans doute la remarque la plus fréquente des seniors. Lorsque vous écrivez une méthode de 200 lignes ou une classe qui fait tout et n'importe quoi — cela saute immédiatement aux yeux. Un senior ne perdra pas de temps à analyser un tel code, il vous demandera simplement de le diviser.

Exemple de mauvais code :

public class OrderService {    public void processOrder(Order order) {        // 1. Validation        if (order.getItems().isEmpty()) {            throw new IllegalArgumentException("Order must have items");        }        // 2. Vérification de l'utilisateur        User user = userRepository.findById(order.getUserId());        if (user == null || user.isBlocked()) {            throw new SecurityException("User not valid");        }        // 3. Calcul de la remise        double discount = 0;        if (order.getTotal() > 1000) {            discount = 0.1;        }        // 4. Sauvegarde        order.setDiscount(discount);        orderRepository.save(order);        // 5. Envoi d'email        emailService.sendOrderConfirmation(order);    }}

Ce que dira le senior : « Cette méthode viole le Single Responsibility Principle. Elle s'occupe de la validation, du calcul, de la sauvegarde et de l'envoi de notifications. Sépare-la en méthodes distinctes ou déplace-la dans différents services. »

Comment corriger :

public class OrderService {    private final OrderValidator validator;    private final DiscountCalculator discountCalculator;    private final OrderRepository orderRepository;    private final NotificationService notificationService;

    public void processOrder(Order order) {        validator.validate(order);        double discount = discountCalculator.calculate(order);        order.setDiscount(discount);        orderRepository.save(order);        notificationService.sendOrderConfirmation(order);    }}

En développement Java, le principe de responsabilité unique est fondamental. Si vous voyez le mot « et » dans une méthode (vérifier et sauvegarder et envoyer), c'est le moment de refactoriser.

2. Gestion de null et NPE (NullPointerException)

NullPointerException est le fléau des développeurs Java. Les seniors détestent les NPE inattendus et font toujours attention à la façon dont vous gérez null. Remarque typique : « Et que se passe-t-il si la méthode retourne null ? »

Exemple :

public String getUserEmail(Long userId) {    User user = userRepository.findById(userId);    return user.getEmail().toLowerCase();}

Remarque du senior : « Si l'utilisateur n'est pas trouvé, user sera null — nous aurons une NPE. Utilise Optional ou au moins une vérification. »

Version corrigée :

public String getUserEmail(Long userId) {    return userRepository.findById(userId)            .map(User::getEmail)            .map(String::toLowerCase)            .orElseThrow(() -> new UserNotFoundException("User not found: " + userId));}

L'utilisation de Optional est un standard en Java moderne.