Code Review en Java: qué buscar en el código ajeno

Por qué el code review no es sobre críticas, sino sobre calidad

Imagina: abres un pull request de un colega. Hay 500 líneas de código, huele a copia y pega, y en un lugar alguien olvidó cerrar un recurso. Tu tarea no es solo encontrar errores, sino mejorar el código. El code review en Java no es una supervisión policial, sino una creación conjunta. Un buen revisor salva al equipo de la deuda técnica; uno malo desmotiva o pasa por alto vulnerabilidades.

En este artículo te contaré qué verificar en un code review en Java para no perder tiempo en nimiedades, pero sin pasar por alto lo crítico. Obtendrás una lista de verificación lista para usar y ejemplos de la práctica.

Arquitectura y diseño: mirando la raíz

Antes de sumergirte en los detalles, evalúa el panorama general. Una mala arquitectura no se cura con formato.

Violación de SOLID

Verifica si la clase se ha convertido en un "objeto divino". Ejemplo de violación del Principio de Responsabilidad Única:

public class OrderService {\n    public void createOrder(Order order) {\n        // validación\n        // cálculo de descuento\n        // envío de email\n        // registro en log\n        // guardado en BD\n    }\n}\n

Aquí hay cinco razones para cambiar. Lo correcto es extraer el registro en log y el envío a servicios separados.

Complejidad excesiva

A veces el código resuelve un problema simple de manera compleja. Pregúntate: "¿Se puede hacer más simple?" Si es así, escríbelo en la revisión. Recuerda el principio KISS.

Seguridad: agujeros que no se deben pasar por alto

La revisión de código Java debe incluir verificación de seguridad. Incluso si el proyecto es interno.

Inyección SQL

La concatenación de cadenas es mala:

// MALO\nString query = "SELECT * FROM users WHERE name = '" + userName + "'";\nStatement stmt = connection.createStatement();\nResultSet rs = stmt.executeQuery(query);\n

Lo correcto es usar PreparedStatement:

// BUENO\nString query = "SELECT * FROM users WHERE name = ?";\nPreparedStatement pstmt = connection.prepareStatement(query);\npstmt.setString(1, userName);\nResultSet rs = pstmt.executeQuery();\n

Fuga de datos sensibles

Verifica que no se estén registrando contraseñas, tokens o números de tarjeta. Usa @ToString.Exclude en Lombok o una exclusión explícita.

Comparación insegura de objetos

// MALO (comparación de referencias)\nif (password == storedPassword) { ... }\n// BUENO\nif (password.equals(storedPassword)) { ... }\n

Rendimiento: cuellos de botella

No optimices prematuramente, pero tampoco pases por alto las ralentizaciones obvias.

Operaciones innecesarias en bucles

// MALO: se llama a length() cada vez\nfor (int i = 0; i < list.size(); i++) { ... }\n// BUENO\nint size = list.size();\nfor (int i = 0; i < size; i++) { ... }\n

Uso de Stream para tareas simples

A veces un bucle normal se lee mejor y funciona más rápido:

// Excesivo\nlist.stream().filter(x -> x > 5).collect(Collectors.toList());\n// Simple\nList<Integer> result = new ArrayList<>();\nfor (int x : list) {\n    if (x > 5) result.add(x);\n}\n

Fuga de memoria

Verifica si olvidaron cerrar un InputStream, Connection o Session. Usa try-with-resources:

try (Connection conn = getConnection();\n     PreparedStatement stmt = conn.prepareStatement(sql)) {\n    // trabajo\n} catch (SQLException e) {\n    log.error("Error de BD", e);\n}\n

Legibilidad y estilo: el código como un libro

La lista de verificación de code review incluye obligatoriamente la legibilidad. El código se escribe una vez, se lee decenas de veces.

Números y cadenas mágicas

// MALO\nif (status == 3) { ... }\n// BUENO\nprivate static final int STATUS_COMPLETED = 3;\nif (status == STATUS_COMPLETED) { ... }\n

Métodos lar