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 no es solo una formalidad o una forma de encontrar errores. Es un proceso fundamental para compartir conocimientos y mejorar la calidad del código. En Kotlin, con su sintaxis expresiva y potentes características, la revisión requiere una atención especial a los detalles. En este artículo, analizaremos qué aspectos tener en cuenta al revisar código en Kotlin y cómo dar retroalimentación para que sea útil, no ofensiva.

1. Qué revisar: lista de verificación para desarrolladores Kotlin

Al comenzar una revisión, no intentes abarcarlo todo de una vez. Es mejor repasar las categorías clave. Aquí tienes una lista de verificación estructurada para Kotlin.

1.1. Null Safety y trabajo con tipos nullable

Kotlin resuelve el problema de NPE, pero solo si el desarrollador no abusa de !! (not-null assertion). Esta es la principal bandera roja.

\n
• Qué buscar: Uso de !! en código de producción. Casi siempre se puede reemplazar con ?.let, ?: (elvis) o un casteo seguro as?.
\n
• Ejemplo de código malo:
\n

fun processUser(user: User?) {\n    val name = user!!.name // ¡NPE potencial!\n    println(name)\n}

\n
• Ejemplo de código bueno:
\n

fun processUser(user: User?) {\n    user?.let { safeUser ->\n        println(safeUser.name)\n    } ?: run {\n        println("User is null")\n    }\n}

1.2. Uso de colecciones y Stream API

Kotlin ofrece un rico conjunto de funciones para trabajar con colecciones. Verifica qué tan eficiente y legiblemente se utilizan.

\n
• Qué buscar: Bucles for innecesarios donde se podría usar map, filter, groupBy. También colecciones mutables (MutableList) si se pueden usar inmutables (List).
\n
• Ejemplo de código malo:
\n

val names = mutableListOf<String>()\nfor (item in items) {\n    if (item.isActive) {\n        names.add(item.name)\n    }\n}

\n
• Ejemplo de código bueno:
\n

val names = items\n    .filter { it.isActive }\n    .map { it.name } // Lista inmutable

1.3. Funciones de extensión y ámbito de visibilidad

Las funciones de extensión son una herramienta poderosa, pero es fácil "dispersarlas" por el proyecto. Verifica si su uso es adecuado.

\n
• Qué buscar: Funciones de extensión que modifican el estado del objeto (especialmente si no es obvio). Funciones que deberían ser métodos de clase pero se han sacado como extensión por "estética".
\n
• Pregunta al autor: "¿Por qué esto es una extensión y no un método de la clase User?"
\n

1.4. Uso de when en lugar de if-else

Kotlin fomenta el uso de when como una alternativa más legible a largas cadenas de if-else.

\n
• Qué buscar: Escaleras de if-else con 3 o más condiciones. Deben reemplazarse por when.
\n

// En lugar de esto:\nif (status == Status.ACTIVE) { ... } else if (status == Status.PENDING) { ... } else { ... }\n\n// Mejor así:\nwhen (status) {\n    Status.ACTIVE -> { ... }\n    Status.PENDING -> { ... }\n    else -> { ... }\n}

2. Cómo dar retroalimentación: de la crítica a la colaboración

La parte técnica es solo la mitad del trabajo. La otra mitad es la comunicación. Una mala retroalimentación puede desmotivar al equipo. Una buena puede fortalecer la confianza.

2.1. Regla del "Por qué, no el Qué"

En lugar de simplemente decir "Esto está mal", explica por qué está mal y cómo solucionarlo.

\n
• Mal: "Aquí hay !! — hazlo de nuevo