Code review в Kotlin: что проверять и как давать обратную связь

Code review в Kotlin: что проверять и как давать обратную связь

Code review — это не просто формальность или способ найти баги. Это важнейший процесс обмена знаниями и повышения качества кода. В Kotlin, с его выразительным синтаксисом и мощными фичами, ревью требует особого внимания к деталям. В этой статье мы разберем, на что обращать внимание при проверке кода на Kotlin и как давать обратную связь так, чтобы она была полезной, а не обидной.

1. Что проверять: чек-лист для Kotlin-разработчика

Приступая к ревью, не пытайтесь охватить всё сразу. Лучше пройтись по ключевым категориям. Вот структурированный чек-лист для Kotlin.

1.1. Null Safety и работа с nullable типами

Kotlin решает проблему NPE, но только если разработчик не злоупотребляет !! (not-null assertion). Это главный красный флаг.

• Что ищем: Использование !! в production-коде. Почти всегда можно заменить на ?.let, ?: (elvis) или безопасный каст as?.
• Пример плохого кода:

fun processUser(user: User?) {
    val name = user!!.name // Потенциальный NPE!
    println(name)
}

• Пример хорошего кода:

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

1.2. Использование коллекций и Stream API

Kotlin предлагает богатый набор функций для работы с коллекциями. Проверяйте, насколько эффективно и читаемо они используются.

• Что ищем: Излишние циклы for там, где можно использовать map, filter, groupBy. А также мутабельные коллекции (MutableList), если можно обойтись иммутабельными (List).
• Пример плохого кода:

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

• Пример хорошего кода:

val names = items
    .filter { it.isActive }
    .map { it.name } // Иммутабельный список

1.3. Extension-функции и область видимости

Extension-функции — мощный инструмент, но их легко "размазать" по проекту. Проверяйте, уместно ли их использование.

• Что ищем: Extension-функции, которые меняют состояние объекта (особенно если это неочевидно). Функции, которые должны быть методами класса, но вынесены в extension для "красоты".
• Вопрос к автору: "Почему это extension, а не метод класса User?"

1.4. Использование when вместо if-else

Kotlin поощряет использование when как более читаемой альтернативы длинным цепочкам if-else.

• Что ищем: Лесенки из if-else на 3+ условий. Их стоит заменить на when.

// Вместо этого:
if (status == Status.ACTIVE) { ... } else if (status == Status.PENDING) { ... } else { ... }

// Лучше так:
when (status) {
    Status.ACTIVE -> { ... }
    Status.PENDING -> { ... }
    else -> { ... }
}

2. Как давать обратную связь: от критики к сотрудничеству

Техническая часть — это только половина дела. Вторая половина — это коммуникация. Плохая обратная связь может демотивировать команду. Хорошая — укрепить доверие.

2.1. Правило "Почему, а не Что"

Вместо того чтобы просто сказать "Это плохо", объясните почему это плохо и как это исправить.

• Плохо: "Тут !! — переделывай."
• Хорошо: "Использование !! здесь может привести к NPE, если user окажется null. Давай заменим на безопасный вызов ?.let — это сделает код более устойчивым к ошибкам."

2.2. Фокус на код, а не на автора

Обсуждайте код, а не человека. Избегайте личных нападок.

• Плохо: "Ты написал ужасный код."
• Хорошо: "В этом участке кода есть потенциальная проблема с производительностью. Давай обсудим, как её оптимизировать."

2.3. Задавайте вопросы

Иногда лучше спросить, чем утверждать. Это помогает автору самому прийти к правильному решению и снижает защитную реакцию.

• Пример: "Я вижу, что здесь используется MutableList. Не будет ли безопаснее использовать иммутабельный список, чтобы избежать случайных изменений из других частей кода?"

2.4. Используйте "сэндвич похвалы"

Начните с положительного комментария, затем укажите на проблему, и закончите на позитивной ноте. Это работает, но не злоупотребляйте — похвала должна быть искренней.

• Пример: "Отлично, что ты использовал sealed class для обработки состояний — это очень чистое решение! Единственный момент: давай переименуем переменную x в userAge для ясности. В остальном код отличный, готов к мержу после правки."

3. Практические советы для эффективного ревью

Чтобы ревью не превращалос