Revisión de código en Kotlin: lo que enfurece a los desarrolladores senior

Cómo ven los seniors su código Kotlin: análisis con ejemplos reales

Escribió código, lo subió al repositorio y espera con el corazón en un puño la aprobación. Pero en lugar de una marca verde, llegan una docena de comentarios del desarrollador senior. ¿Le suena familiar? Si escribe en Kotlin, seguramente se ha encontrado con la situación en la que su código, aparentemente perfecto, se convierte en una calabaza después del code review.

En este artículo, analizaremos cuáles son las observaciones típicas de los seniors que más a menudo aparecen en la revisión de código en Kotlin. No le enseñaremos sintaxis, le mostraremos cómo escribir para que su código pase la revisión a la primera. ¡Allá vamos!

1. Null Safety: «¿Por qué no usas el operador Elvis?»

Una de las principales características de Kotlin es la null safety. Pero muchos desarrolladores, especialmente los que vienen de Java, siguen escribiendo código al estilo «verifica-si-es-null-y-ejecuta». Los seniors lo ven de inmediato.

Ejemplo malo (estilo Java)

fun getUserName(user: User?): String {\n    return if (user != null) {\n        user.name\n    } else {\n        "Unknown"\n    }\n}

Ejemplo bueno (estilo Kotlin)

fun getUserName(user: User?): String {\n    return user?.name ?: "Unknown"\n}

El uso del operador Elvis (?:) y la llamada segura (?.) hace que el código sea conciso y legible. A los seniors les encanta que ahorre líneas sin perder claridad. Recuerde: if (x != null) { ... } else { ... } es de mal gusto.

2. Extension Functions: «¿Dónde están tus utilidades?»

Cuando ve una clase de utilidad estática como StringUtils.capitalize(str), un desarrollador experimentado en Kotlin fruncirá el ceño. Las extension functions son lo que hace que Kotlin sea tan elegante.

Ejemplo malo

object StringUtils {\n    fun capitalize(text: String): String {\n        return text.replaceFirstChar { it.uppercase() }\n    }\n}\n\n// Uso\nval result = StringUtils.capitalize("hello")

Ejemplo bueno

fun String.capitalizeFirst(): String {\n    return this.replaceFirstChar { it.uppercase() }\n}\n\n// Uso\nval result = "hello".capitalizeFirst()

Los seniors dirán: «¿Por qué creas un objeto basura? ¡Simplemente extiende la clase!» Use extension functions — esto mejora la legibilidad y sigue el principio de Kotlin best practices.

3. Sealed Classes en lugar de Enum: «Tu enum está obsoleto»

Los enum en Kotlin están bien, pero las sealed classes ofrecen mucha más flexibilidad. Especialmente cuando necesita almacenar diferentes tipos de datos en una misma jerarquía.

Ejemplo malo (enum)

enum class Result {\n    SUCCESS,\n    ERROR,\n    LOADING\n}\n\nfun handleResult(result: Result) {\n    when (result) {\n        Result.SUCCESS -> // ...\n        Result.ERROR -> // ...\n        Result.LOADING -> // ...\n    }\n}

Ejemplo bueno (sealed class)

sealed class Result {\n    data class Success(val data: List<Item>) : Result()\n    data class Error(val message: String, val code: Int) : Result()\n    object Loading : Result()\n}\n\nfun handleResult(result: Result) {\n    when (result) {\n        is Result.Success -> println("Data: ${result.data}")\n        is Result.Error -> println("Error: ${result.message}")\n        Result.Loading -> println("Loading...")\n    }\n}

Los desarrolladores senior apreciarán que use sealed classes para representar estados. Este es uno de los principales consejos senior kotlin — haga explícitas las jerarquías de tipos.

4. Scope Functions: «Olvidaste let, apply y run»

Las scope functions (let, apply, run, with, also) son poderosas