Code review en Java: qué revisar y cómo dar retroalimentación
Code review (revisión de código) es una de las herramientas más efectivas para mejorar la calidad del producto de software y el crecimiento profesional del equipo. Sin embargo, cuando se trata de Java, muchos desarrolladores (especialmente los juniors) tienen miedo de enviar su código a revisión o no saben en qué deben fijarse al revisar el código de otros. En este artículo, analizaremos qué exactamente se debe revisar en el código Java y cómo formular observaciones para no ofender a un colega, sino ayudarlo a mejorar.
1. Qué revisar en el código Java: lista de verificación técnica
Lo primero que viene a la mente es la sintaxis y la lógica. Pero una revisión profesional va mucho más allá de estos límites. Estos son los aspectos clave que vale la pena revisar en cada pull request.
1.1. Arquitectura y diseño
Observe qué tan bien encaja el nuevo cambio en la arquitectura existente. ¿Viola los principios SOLID? Por ejemplo, si ve una clase que hace demasiado (God Object), es motivo para sugerir dividirla.
- Principio de responsabilidad única (SRP): Cada clase debe tener una única razón para cambiar.
- Inversión de dependencias (DIP): Dependa de abstracciones, no de implementaciones concretas.
- Patrones: El uso de singletons, fábricas o estrategias debe estar justificado, no aplicado "por si acaso".
// Mal: la clase sabe tanto de la lógica como del guardadopublic class UserService { public void registerUser(String name) { // validación // guardado en BD // envío de email }}
// Bien: separación de responsabilidadespublic class UserService { private final UserRepository repository; private final EmailService emailService;
public void registerUser(String name) { User user = new User(name); repository.save(user); emailService.sendWelcome(user); }}1.2. Rendimiento y gestión de memoria
Java es un lenguaje con gestión automática de memoria, pero eso no significa que se pueda olvidar la optimización. Verifique:
- Concatenación de cadenas en un bucle: Use
StringBuilderoStringBuffer. - Objetos innecesarios: Creación de objetos temporales en bucles críticos.
- Colecciones: Elección de la implementación correcta (por ejemplo,
ArrayListvsLinkedList). - NullPointerException: Use
Optionalo verificaciones de null.
// Mal: millones de cadenas en memoriaString result = "";for (String s : list) { result += s;}
// Bien: StringBuilderStringBuilder sb = new StringBuilder();for (String s : list) { sb.append(s);}String result = sb.toString();1.3. Manejo de errores y excepciones
Un error en Java no siempre es un bug. A veces es un uso incorrecto de las excepciones. Preste atención:
- Bloques catch vacíos:
catch (Exception e) {}es malo. El error debe al menos registrarse. - Excepciones demasiado generales: Capturar
ExceptionoThrowablees una mala práctica. - Flujos de recursos: Use try-with-resources para el cierre automático.
// Mal: tragamos la excepcióntry { // algún código} catch (Exception e) { // no hacemos nada}
// Bien: registramos y relanzamostry { // algún código} catch (SQLException e) { log.error("Error al trabajar con la BD", e); throw new ServiceException("No se pudo realizar la operación", e);}1.4. Pruebas y cobertura
Una revisión de código sin verificar las pruebas es una revisión "a medias". Asegúrese de que: