Revisão de código em Java: o que os seniors procuram e como não falhar na revisão de código

Revisão de código em Java: o que os seniors procuram e como não falhar na revisão de código

Você escreveu o código, testou localmente, executou os testes — tudo verde. Você abre um Pull Request e, algumas horas depois, vê uma dezena de comentários de um colega sênior. Familiar? A revisão de código em Java não é um procedimento burocrático, mas um verdadeiro exame de maturidade do desenvolvedor. Os seniors veem o código de outra forma: eles não apenas verificam se funciona, mas observam por quanto tempo funcionará e o quão difícil será modificá-lo.

Neste artigo, vamos analisar as observações mais comuns que desenvolvedores Java experientes fazem nas revisões de código. Você aprenderá a escrever código limpo e sustentável e a passar na revisão logo na primeira vez.

1. Ignorar os princípios SOLID e a arquitetura limpa

Esta é, talvez, a observação mais frequente dos seniors. Quando você escreve um método com 200 linhas ou uma classe que faz tudo — isso chama a atenção imediatamente. O sênior não perderá tempo analisando esse código, ele simplesmente pedirá para dividi-lo.

Exemplo de código ruim:

public class OrderService {    public void processOrder(Order order) {        // 1. Validação        if (order.getItems().isEmpty()) {            throw new IllegalArgumentException("Order must have items");        }        // 2. Verificação do usuário        User user = userRepository.findById(order.getUserId());        if (user == null || user.isBlocked()) {            throw new SecurityException("User not valid");        }        // 3. Cálculo do desconto        double discount = 0;        if (order.getTotal() > 1000) {            discount = 0.1;        }        // 4. Salvamento        order.setDiscount(discount);        orderRepository.save(order);        // 5. Envio de email        emailService.sendOrderConfirmation(order);    }}

O que o sênior dirá: "Este método viola o Princípio da Responsabilidade Única. Ele é responsável por validação, cálculo, salvamento e envio de notificações. Divida em métodos separados ou mova para serviços diferentes."

Como corrigir:

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

No desenvolvimento Java, o princípio da responsabilidade única é fundamental. Se você vir a palavra "e" no método (validar e salvar e enviar), é hora de refatorar.

2. Trabalhar com null e NPE (NullPointerException)

NullPointerException é o flagelo dos desenvolvedores Java. Os seniors odeiam NPE inesperados e sempre prestam atenção em como você lida com null. Uma observação típica: "E se o método retornar null?"

Exemplo:

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

Observação do sênior: "Se o usuário não for encontrado, user será null — teremos um NPE. Use Optional ou pelo menos uma verificação."

Versão corrigida:

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

O uso de Optional é o padrão no Java moderno.