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

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

Code review (revisão de código) não é apenas uma formalidade, mas uma ferramenta poderosa para melhorar a qualidade do projeto e o crescimento da equipe. Para desenvolvedores iniciantes em Kotlin, o processo de revisão muitas vezes causa medo: "E se eu deixar passar um bug?", "Como dizer ao colega que o código dele está ruim?". Neste artigo, vamos abordar o que observar ao revisar código Kotlin e como formular observações para que sejam úteis, e não ofensivas.

Não vamos ensinar os fundamentos da sintaxe — presume-se que você já escreve em Kotlin. Em vez disso, focaremos em problemas típicos encontrados no código de iniciantes e em como dar feedback sem quebrar o clima.

1. Null safety e trabalho com tipos anuláveis

Kotlin se orgulha de seu sistema de tipos, que elimina a maior parte dos NullPointerException em tempo de compilação. No entanto, iniciantes frequentemente abusam do operador !! (not-null assertion) ou tratam incorretamente valores anuláveis.

O que verificar:

\n
• O !! está sendo usado sem um motivo válido? Se você vir something!!, pergunte ao autor: "Por que você tem certeza de que não será null aqui? Talvez seja melhor usar ?.let ou ?:?".
\n
• As cadeias de chamadas com ?. estão sendo tratadas corretamente? Por exemplo, user?.address?.city é seguro, mas se a cidade for necessária, é melhor usar ?: para um valor padrão.
\n
• O lateinit var foi inicializado antes do uso? Verifique se todos os campos lateinit serão realmente inicializados antes da primeira leitura.
\n

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

Como dar feedback: Em vez de "Você escreveu um código ruim", diga: "Aqui pode haver null, vamos substituir !! por uma chamada segura para evitar uma falha em tempo de execução". Sugira uma alternativa — isso ensina, não critica.

2. Idiomaticidade do Kotlin: coleções, scope-functions e sealed class

Kotlin não é apenas "Java com sintaxe diferente". Muitos iniciantes escrevem em Kotlin como se ainda estivessem trabalhando em Java: usam loops for em vez de funções de coleção, esquecem de apply, let, run e não aplicam sealed class para representar estados.

O que verificar:

\n
• Funções de coleção (map, filter, firstOrNull) estão sendo usadas em vez de loops manuais? Isso torna o código mais conciso e legível.
\n
• Há variáveis temporárias redundantes? Por exemplo, val result = list.filter { ... }.map { ... } é melhor do que dividir em três etapas com listas mutáveis.
\n
• sealed class está sendo usado para hierarquias onde todos os casos precisam ser tratados (por exemplo, Result, UiState)? Isso é um requisito obrigatório em projetos Kotlin modernos.
\n

// Ruim (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// Bom (idiomático Kotlin)\nfun getEvenSquaresIdiomatic(list: List<Int>): List<Int> {\n    return list.filter { it % 2 == 0 }.map { it * it }\n}\n

Como dar feedback: Aponte para a expressão idiomática específica: "Em vez do loop for, você pode usar filter + map, é mais curto e mais claro. Quer que eu mostre um exemplo?". Não imponha — sugira uma discussão.

3. Arquitetura e testabilidade

Mesmo que o projeto seja pequeno, o code review é um ótimo momento para verificar