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

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

El code review es una de las herramientas más efectivas para mantener la calidad del código, compartir conocimientos en el equipo y prevenir errores. Sin embargo, simplemente "echar un vistazo" al pull request no es suficiente. En el lenguaje Kotlin, con su rico sistema de tipos, corrutinas y capacidades funcionales, es importante prestar atención a aspectos específicos. En este artículo, analizaremos qué observar exactamente al revisar código en Kotlin y cómo formular observaciones para que sean útiles y no ofensivas.

1. Principios básicos de la retroalimentación constructiva

Antes de pasar a los detalles técnicos, recordemos algunas reglas que hacen que el code review sea útil para todos los participantes.

Enfocarse en el código, no en el autor

En lugar de "Escribiste mal código", diga "Este método se puede simplificar usando let". La especificidad y un tono neutral reducen la tensión.

Dividir en categorías

Marque las observaciones como:

• Blocking — debe corregirse obligatoriamente (error lógico, fuga de recursos).
• Nitpick — pequeñas objeciones (estilo, formato).
• Question — aclaración (la intención no está clara).

Explicar el "por qué"

No es suficiente decir "usa filterNotNull()". Añada: "Esto eliminará un bucle innecesario y hará que el código sea autodocumentado". Así el autor aprende, no solo corrige.

2. Null safety y tipos: los principales aliados de Kotlin

Kotlin está diseñado para evitar NullPointerException en tiempo de compilación. Verifique que esta protección no se haya visto comprometida.

Evitar los !! (not-null assertion) innecesarios

El operador !! es un grito de auxilio. Su uso debe ser la excepción, no la regla.

// Mal: riesgo de NPEfun process(user: User?) {    val name = user!!.name}

// Bien: llamada segurafun process(user: User?) {    val name = user?.name ?: "Invitado"}

Qué revisar: si ve !!, pregunte al autor si se puede reemplazar por ?.let, ?: (elvis) o requireNotNull().

Uso correcto de tipos nullable

No todos los parámetros deben ser nullable. Si una función siempre espera un valor, declare el tipo sin el signo de interrogación.

// Discutible: null no significa nadafun log(message: String?) {    println(message ?: "null")}

// Mejor: requisito explícitofun log(message: String) {    println(message)}

3. Corrutinas y flujos: asincronía sin dolor

Kotlin Coroutines es una herramienta poderosa, pero es fácil usarla incorrectamente. Al revisar, preste atención a los siguientes puntos.

El dispatcher correcto para las tareas

No ejecute operaciones largas (red, disco) en Dispatchers.Main.

// Mal: bloquea la UIGlobalScope.launch(Dispatchers.Main) {    val data = fetchFromNetwork() // se cuelga}

// Bien: cambio de contextoviewModelScope.launch {    val data = withContext(Dispatchers.IO) {        fetchFromNetwork()    }    updateUI(data)}

Fuga de corrutinas y structured concurrency

Use viewModelScope, lifecycleScope o coroutineScope en lugar de GlobalScope. Este último vive mientras vive la aplicación y fácilmente provoca fugas.

// Peligroso: fugaGlobalScope.launch { /* ... */ }

// Seguro: vinculado al ciclo de vidalifecycleScope.launch { /* ... */ }

4. Colecciones y estilo funcional: brevedad y legibilidad

Kotlin ofrece una rica biblioteca para trabajar con colecciones. Úsela en lugar de bucles explícitos.

Cadenas en lugar de mutaciones

Evite agregar manualmente a una lista si se puede recopilar el resultado