Revisión de código en Java: qué buscan los seniors y cómo no fracasar en la code review

Revisión de código en Java: qué buscan los seniors y cómo no fracasar en la code review

Escribiste el código, lo probaste localmente, ejecutaste las pruebas — todo en verde. Abres un Pull Request y un par de horas después ves una decena de comentarios de un colega senior. ¿Te suena? La revisión de código en Java no es un procedimiento burocrático, sino un verdadero examen de madurez del desarrollador. Los seniors ven el código de otra manera: no solo verifican si funciona, sino que observan cuánto tiempo funcionará y qué tan difícil será modificarlo.

En este artículo analizaremos las observaciones más frecuentes que los desarrolladores Java experimentados dejan en las code reviews. Aprenderás a escribir código limpio y mantenible, y a pasar la revisión a la primera.

1. Ignorar los principios SOLID y la arquitectura limpia

Esta es, quizás, la observación más común de los seniors. Cuando escribes un método de 200 líneas o una clase que lo hace todo, salta a la vista de inmediato. Un senior no perderá tiempo analizando ese código, simplemente te pedirá que lo dividas.

Ejemplo de mal código:

public class OrderService {    public void processOrder(Order order) {        // 1. Validación        if (order.getItems().isEmpty()) {            throw new IllegalArgumentException("Order must have items");        }        // 2. Verificación del usuario        User user = userRepository.findById(order.getUserId());        if (user == null || user.isBlocked()) {            throw new SecurityException("User not valid");        }        // 3. Cálculo del descuento        double discount = 0;        if (order.getTotal() > 1000) {            discount = 0.1;        }        // 4. Guardado        order.setDiscount(discount);        orderRepository.save(order);        // 5. Envío de email        emailService.sendOrderConfirmation(order);    }}

Qué dirá el senior: «Este método viola el Principio de Responsabilidad Única. Se encarga de la validación, el cálculo, el guardado y el envío de notificaciones. Divídelo en métodos separados o extráelo a diferentes servicios.»

Cómo corregirlo:

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 el desarrollo Java, el principio de responsabilidad única es la base. Si ves en un método la palabra «y» (validar y guardar y enviar), es hora de refactorizar.

2. Trabajar con null y NPE (NullPointerException)

NullPointerException es el azote de los desarrolladores Java. Los seniors odian los NPE inesperados y siempre prestan atención a cómo manejas el null. Una observación típica: «¿Y qué pasa si el método devuelve null?»

Ejemplo:

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

Observación del senior: «Si el usuario no se encuentra, user será null — obtendremos un NPE. Usa Optional o al menos una verificación.»

Versión corregida:

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

El uso de Optional es un estándar en Java moderno.