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

El code review (revisión de código) no es solo una formalidad, sino una herramienta poderosa para mejorar la calidad del proyecto y el crecimiento del equipo. Para los desarrolladores principiantes en Kotlin, el proceso de revisión a menudo causa miedo: "¿Y si paso por alto un error?", "¿Cómo le digo a un colega que su código es malo?". En este artículo, analizaremos en qué fijarse al revisar código Kotlin y cómo formular observaciones para que sean útiles, no hirientes.

No le enseñaremos los conceptos básicos de sintaxis: se asume que ya escribe en Kotlin. En su lugar, nos centraremos en los problemas típicos que se encuentran en el código de los principiantes y en cómo dar retroalimentación sin dañar la armonía.

1. Null safety y trabajo con tipos nullable

Kotlin se enorgullece de su sistema de tipos, que elimina la mayoría de los NullPointerException en tiempo de compilación. Sin embargo, los principiantes a menudo abusan del operador !! (not-null assertion) o manejan incorrectamente los valores nullable.

Qué revisar:

\n
• ¿Se usa !! sin una razón justificada? Si ve something!!, pregunte al autor: "¿Por qué estás seguro de que aquí no habrá null? ¿Quizás es mejor usar ?.let o ?:?".
\n
• ¿Se manejan correctamente las cadenas de llamadas con ?.? Por ejemplo, user?.address?.city es seguro, pero si se necesita city, es mejor usar ?: para un valor por defecto.
\n
• ¿Se olvidó inicializar lateinit var antes de usarlo? Verifique que todos los campos lateinit estén realmente inicializados antes de la primera lectura.
\n

// Malo\nfun getUserCity(user: User?): String {\n    return user!!.address!!.city // Riesgo de NPE\n}\n\n// Bueno\nfun getUserCitySafe(user: User?): String {\n    return user?.address?.city ?: "Unknown"\n}\n

Cómo dar retroalimentación: En lugar de "Escribiste código malo", diga: "Aquí puede haber null, reemplacemos !! por una llamada segura para evitar una caída en tiempo de ejecución". Proponga una alternativa: esto enseña, no critica.

2. Idiomaticidad en Kotlin: colecciones, scope-functions y sealed class

Kotlin no es solo "Java con otra sintaxis". Muchos principiantes escriben en Kotlin como si todavía estuvieran trabajando en Java: usan bucles for en lugar de funciones de colecciones, olvidan apply, let, run y no aplican sealed class para representar estados.

Qué revisar:

\n
• ¿Se usan funciones de colecciones (map, filter, firstOrNull) en lugar de bucles manuales? Esto hace que el código sea más conciso y legible.
\n
• ¿Hay variables temporales redundantes? Por ejemplo, val result = list.filter { ... }.map { ... } es mejor que dividir en tres pasos con listas mutables.
\n
• ¿Se usan sealed class para jerarquías donde se deben manejar todas las variantes (por ejemplo, Result, UiState)? Este es un requisito obligatorio en proyectos Kotlin modernos.
\n

// Malo (estilo Java)\nfun getEvenSquares(list: List<Int>): List<Int> {\n    val result = mutableListOf<Int>()\n    for (i in list.indices) {\n        if (list[i] % 2 == 0) {\n            result.add(list[i] * list[i])\n        }\n    }\n    return result\n}\n\n// Bueno (idiomático Kotlin)\nfun getEvenSquaresIdiomatic(list: List<Int>): List<Int> {\n    return list.filter { it % 2 == 0 }.map { it * it }\n}\n

Cómo dar retroalimentación: Señale el modismo específico: "En lugar del bucle for, puedes usar filter + map, es más corto y claro. ¿Quieres que te muestre un ejemplo?". No imponga, proponga discutirlo.

3. Arquitectura y testabilidad

Incluso si el proyecto es pequeño, el code review es un momento excelente para verificar