Java-Code-Review: Was Senioren suchen und wie man das Code-Review nicht vermasselt

Java-Code-Review: Was Senioren suchen und wie man das Code-Review nicht vermasselt

Sie haben Code geschrieben, lokal getestet, die Tests laufen lassen – alles grün. Sie öffnen einen Pull Request und sehen ein paar Stunden später ein Dutzend Kommentare von einem erfahrenen Kollegen. Kommt Ihnen bekannt vor? Ein Java-Code-Review ist kein bürokratischer Vorgang, sondern eine echte Prüfung der Entwicklungsreife. Senioren sehen Code anders: Sie prüfen nicht nur, ob er funktioniert, sondern schauen, wie lange er funktionieren wird und wie schwierig es sein wird, ihn zu ändern.

In diesem Artikel analysieren wir die häufigsten Anmerkungen, die erfahrene Java-Entwickler bei Code-Reviews hinterlassen. Sie erfahren, wie Sie sauberen, wartbaren Code schreiben und das Review beim ersten Mal bestehen.

1. Ignorieren der SOLID-Prinzipien und sauberen Architektur

Dies ist wohl die häufigste Anmerkung von Senioren. Wenn Sie eine Methode mit 200 Zeilen oder eine Klasse schreiben, die alles Mögliche macht – das fällt sofort auf. Ein Senior wird keine Zeit damit verschwenden, solchen Code zu analysieren, sondern Sie bitten, ihn aufzuteilen.

Beispiel für schlechten Code:

public class OrderService {    public void processOrder(Order order) {        // 1. Validierung        if (order.getItems().isEmpty()) {            throw new IllegalArgumentException("Order must have items");        }        // 2. Benutzerprüfung        User user = userRepository.findById(order.getUserId());        if (user == null || user.isBlocked()) {            throw new SecurityException("User not valid");        }        // 3. Rabattberechnung        double discount = 0;        if (order.getTotal() > 1000) {            discount = 0.1;        }        // 4. Speichern        order.setDiscount(discount);        orderRepository.save(order);        // 5. E-Mail senden        emailService.sendOrderConfirmation(order);    }}

Was der Senior sagen wird: „Diese Methode verstößt gegen das Single Responsibility Principle. Sie ist verantwortlich für Validierung, Berechnung, Speicherung und das Senden von Benachrichtigungen. Teile sie in separate Methoden auf oder lagere sie in verschiedene Services aus.“

Wie man es korrigiert:

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);    }}

In der Java-Entwicklung ist das Prinzip der einzigen Verantwortung die Grundlage. Wenn Sie in einer Methode das Wort „und“ sehen (prüfen und speichern und senden), dann ist es Zeit für ein Refactoring.

2. Umgang mit null und NPE (NullPointerException)

NullPointerException – die Geißel der Java-Entwickler. Senioren hassen unerwartete NPEs und achten immer darauf, wie Sie mit null umgehen. Eine typische Anmerkung: „Was passiert, wenn die Methode null zurückgibt?“

Beispiel:

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

Anmerkung des Seniors: „Wenn der Benutzer nicht gefunden wird, ist user null – wir erhalten eine NPE. Verwende Optional oder zumindest eine Prüfung.“

Korrigierte Version:

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

Die Verwendung von Optional ist in modernem Java Standard.