Code review en Kotlin: qué revisar y cómo dar retroalimentación a principiantes

Code review en Kotlin: qué revisar y cómo dar retroalimentación para principiantes

Code review (revisión de código) es uno de los procesos clave en el desarrollo moderno. Para los principiantes en Kotlin, a menudo parece intimidante: ¿cómo encontrar errores? ¿Qué mirar exactamente? ¿Cómo no ofender al autor del código? En este artículo, analizaremos en qué prestar atención durante el code review de proyectos en Kotlin y cómo dar retroalimentación para que sea útil, no ofensiva. El material es adecuado tanto para quienes recién aprenden a revisar como para quienes desean mejorar sus habilidades.

¿Por qué es necesario el code review en Kotlin?

Kotlin es un lenguaje moderno, conciso y seguro, pero le da al desarrollador mucha libertad. Sin code review, es fácil cometer errores relacionados con la seguridad de null, el uso incorrecto de corrutinas o la complejidad excesiva. La revisión ayuda a:

• Encontrar errores en etapas tempranas.
• Mejorar la legibilidad y mantenibilidad del código.
• Difundir el conocimiento dentro del equipo.
• Mantener un estilo de código uniforme.

Para los principiantes, también es una excelente manera de aprender de ejemplos ajenos. Pasemos a los detalles.

Qué revisar durante el code review de código en Kotlin

Aquí hay una lista de verificación de puntos clave que debe revisar en cada pull request. Los dividiremos en bloques lógicos.

1. Seguridad de null y tipos

Kotlin se enorgullece de su seguridad de null, pero se puede violar. Verifique:

• ¿Se usan tipos nullable (por ejemplo, String?) solo donde realmente es necesario?
• ¿No hay !! (non-null assertion) innecesarios? Idealmente, no deberían estar en absoluto en el código de producción.
• ¿Se usan llamadas seguras (?.let { ... }) y el operador Elvis (?:) en lugar de if (x != null)?

Mal ejemplo:

val name: String? = getName()val length = name!!.length // Peligroso: provocará NPE si name == null

Buen ejemplo:

val name: String? = getName()val length = name?.length ?: 0 // Seguro: si es null, entonces 0

2. Funciones y sus firmas

Kotlin admite argumentos con nombre y valores predeterminados. Verifique:

• ¿La función es demasiado larga (más de 20–30 líneas)? Quizás debería dividirse.
• ¿Se usan parámetros predeterminados para simplificar la llamada?
• ¿No hay funciones con más de 3–4 parámetros? Esto dificulta la lectura.
• ¿Es apropiado el uso de funciones de extensión? No deben cambiar el estado del objeto.

Ejemplo:

// En lugar de esto:fun processUserData(name: String, age: Int, email: String, city: String, phone: String) { ... }

// Mejor así:data class UserData(val name: String, val age: Int, val email: String, val city: String, val phone: String)fun processUserData(user: UserData) { ... }

3. Trabajo con corrutinas (Coroutines)

Las corrutinas son una herramienta poderosa de Kotlin, pero es fácil usarlas incorrectamente. Preste atención:

• ¿Se ha bloqueado el hilo dentro de una corrutina (llamada a Thread.sleep() o E/S bloqueante)?
• ¿Se usa el dispatcher correcto (Dispatchers.IO para solicitudes de red, Dispatchers.Main para UI)?
• ¿No hay fugas de corrutinas (por ejemplo, iniciadas en una Activity sin cancelación)?
• ¿Se usa withContext para cambiar de dispatcher, en lugar de launch dentro de launch?

Mal ejemplo:

fun fetchData() {    GlobalScope.launch { // Fuga: no se cancela al destruir el componente        Thread.sleep(1000) // ¡Bloquea el hilo!    }}

Buen ejemplo:

fun fetchData(scope: CoroutineScope) {    scope.launch {        withContext(Dispatchers