Code review em Kotlin: o que verificar e como dar feedback

Code review em Kotlin: o que verificar e como dar feedback

Code review não é apenas uma formalidade ou uma forma de encontrar bugs. É um processo essencial de compartilhamento de conhecimento e melhoria da qualidade do código. Em Kotlin, com sua sintaxe expressiva e recursos poderosos, a revisão exige atenção especial aos detalhes. Neste artigo, vamos analisar o que observar ao revisar código em Kotlin e como dar feedback de forma útil, não ofensiva.

1. O que verificar: checklist para o desenvolvedor Kotlin

Ao iniciar uma revisão, não tente cobrir tudo de uma vez. É melhor percorrer as categorias principais. Aqui está um checklist estruturado para Kotlin.

1.1. Null Safety e trabalho com tipos anuláveis

Kotlin resolve o problema do NPE, mas apenas se o desenvolvedor não abusar do !! (not-null assertion). Esta é a principal bandeira vermelha.

\n
• O que procurar: Uso de !! em código de produção. Quase sempre pode ser substituído por ?.let, ?: (elvis) ou cast seguro as?.
\n
• Exemplo de código ruim:
\n

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

\n
• Exemplo de código bom:
\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 coleções e Stream API

Kotlin oferece um rico conjunto de funções para trabalhar com coleções. Verifique quão eficiente e legível elas são usadas.

\n
• O que procurar: Loops for desnecessários onde map, filter, groupBy poderiam ser usados. Além disso, coleções mutáveis (MutableList) quando imutáveis (List) seriam suficientes.
\n
• Exemplo de código ruim:
\n

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

\n
• Exemplo de código bom:
\n

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

1.3. Funções de extensão e escopo

Funções de extensão são uma ferramenta poderosa, mas podem ser facilmente "espalhadas" pelo projeto. Verifique se o uso é adequado.

\n
• O que procurar: Funções de extensão que alteram o estado do objeto (especialmente se não for óbvio). Funções que deveriam ser métodos de classe, mas foram colocadas como extensão por "estética".
\n
• Pergunta ao autor: "Por que isso é uma extensão e não um método da classe User?"
\n

1.4. Uso de when em vez de if-else

Kotlin incentiva o uso de when como uma alternativa mais legível a longas cadeias de if-else.

\n
• O que procurar: Escadas de if-else com 3 ou mais condições. Devem ser substituídas por when.
\n

// Em vez disso:\nif (status == Status.ACTIVE) { ... } else if (status == Status.PENDING) { ... } else { ... }\n\n// Melhor assim:\nwhen (status) {\n    Status.ACTIVE -> { ... }\n    Status.PENDING -> { ... }\n    else -> { ... }\n}

2. Como dar feedback: da crítica à colaboração

A parte técnica é apenas metade do trabalho. A outra metade é a comunicação. Um feedback ruim pode desmotivar a equipe. Um bom feedback pode fortalecer a confiança.

2.1. Regra do "Porquê, não o Quê"

Em vez de simplesmente dizer "Isso está ruim", explique por que está ruim e como corrigir.

\n
• Ruim: "Aqui tem !! — refaça