Опишите процесс код-ревью в вашей предыдущей команде.

Процесс был формализован через GitHub Pull Requests (PR) и включал четкие этапы.

1. Подготовка PR (Автор):

• Маленький размер: PR охватывал одну задачу, идеально до 300-500 строк.
• Четкое описание: Что сделано, как тестировалось, ссылка на задачу.
• Визуализация: При необходимости — скриншоты или видео изменений.
• Назначение ревьюверов: Использование @mention для 1-2 ключевых разработчиков.

2. Проведение ревью (Ревьювер):

• Срок: Старались проверить в течение 24 часов.
• Фокус на:
  • Архитектура: Соответствие паттернам (MVVM, VIPER), отсутствие сильных связей.
  • Качество кода: Следование SOLID, DRY, читаемость.
  • Гайдлайны: Соблюдение Swift Style Guide команды.
  • Безопасность: Возможные утечки памяти, race conditions, обработка ошибок.
  • Тестируемость: Удобно ли покрыть код unit-тестами.
• Формат обратной связи: Конструктивные комментарии прямо в коде.

3. Пример комментария:

// Вместо императивного подхода:
var validItems: [Item] = []
for item in array {
    if item.isValid {
        validItems.append(item)
    }
}

// Лучше использовать функциональный:
let validItems = array.filter { $0.isValid }
// Короче, выразительнее и избегает мутации переменной.

4. Культура общения:

• Критика кода, а не человека.
• Использование "мы" и вопросов ("Как думаешь, можно ли здесь применить...?").
• Обязательный апрув от минимум одного ревьювера перед мержем.

Такой процесс повышал качество кода, делился знаниями и поддерживал здоровую атмосферу.