Как проходил code review на прошлой работе?

Мой подход к Code Review: процессы, принципы и практические примеры

На всех моих предыдущих позициях Unity Developer code review был не формальностью, а ключевым элементом процесса разработки, интегрированным в CI/CD pipeline. Я работал как в продуктовых командах, так и в аутсорсе, где требования к качеству кода были особенно высокими из-за необходимости передавать проекты заказчикам.

Организационный процесс и инструменты

Процесс всегда был итеративным и основанным на pull request (PR):

1. Создание PR с чек-листом — перед запросом ревью я обязательно:

   • Проверял работу на основных платформах (PC, Mobile)
   • Убеждался в отсутствии ошибок компиляции
   • Добавлял базовое описание изменений
   • Прикреплял скриншоты/гифки для визуальных изменений

2. Использование специализированных инструментов:

   • GitLab/GitHub для основного ревью
   • Unity Collaborate для небольших проектов
   • Plastic SCM в проектах с большими бинарными файлами

3. Обязательные ревьюверы:

   • Ведущий разработчик проекта
   • Специалист по затрагиваемой системе (например, UI-программист для изменений в интерфейсе)
   • Интегратор (если изменения затрагивают сборку проекта)

Ключевые аспекты, на которые обращалось внимание

Во время ревью мы фокусировались на нескольких критических направлениях:

Архитектурная корректность:

// ПЛОХО: жесткая связность
public class Player : MonoBehaviour
{
    public Enemy enemy;
    public void Attack() { enemy.TakeDamage(10); }
}

// ХОРОШО: использование интерфейсов
public interface IDamageable { void TakeDamage(int damage); }
public class Player : MonoBehaviour
{
    public void Attack(IDamageable target) { target.TakeDamage(10); }
}

Производительность в контексте Unity:

• Проверка отсутствия GetComponent() в Update-циклах
• Корректное использование Object Pooling для частого создания/уничтожения объектов
• Оптимизация вызовов физических методов (Rigidbody, Colliders)

Следование кодстайлу проекта:

• Единые правила именования (например, _privateField, PublicProperty)
• Использование пространств имен по модулям
• Комментарии только для нетривиальной логики

Пример реального ревью из практики

В одном из проектов мобильной игры я разрабатывал систему диалогов. Мой изначальный код:

public class DialogueSystem : MonoBehaviour
{
    public List<string> dialogues = new List<string>();
    private int currentIndex = 0;
    
    void Update()
    {
        if (Input.GetMouseButtonDown(0))
        {
            ShowNextDialogue();
        }
    }
    
    void ShowNextDialogue()
    {
        if (currentIndex < dialogues.Count)
        {
            Debug.Log(dialogues[currentIndex]);
            currentIndex++;
        }
    }
}

Замечания от ревьювера:

1. Hardcode Input — система не будет работать на мобильных устройствах
2. Логирование в прод — использование Debug.Log в продакшн-коде
3. Отсутствие событий — другие системы не могут реагировать на смену диалога
4. Прямое управление индексом — нет защиты от выхода за границы

Исправленная версия после ревью:

public class DialogueSystem : MonoBehaviour
{
    [SerializeField] private List<DialogueLine> dialogues;
    private int currentIndex = 0;
    public event Action<DialogueLine> OnDialogueChanged;
    
    public void Initialize()
    {
        // Инициализация через менеджер ввода
        InputManager.Instance.OnTap += HandleTap;
    }
    
    private void HandleTap(Vector2 position)
    {
        if (TryShowNextDialogue())
        {
            // Отправка события для UI и других систем
            OnDialogueChanged?.Invoke(dialogues[currentIndex]);
        }
    }
    
    private bool TryShowNextDialogue()
    {
        if (currentIndex >= dialogues.Count) return false;
        
        currentIndex++;
        return true;
    }
}

Культура общения и разрешение конфликтов

Важнейшим аспектом была конструктивная обратная связь. Мы придерживались принципа "критикуй код, а не человека". Все замечания формулировались как вопросы или предложения:

• ❌ "Это неправильно"
• ✅ "Как ты думаешь, будет ли это работать на Android с такой реализацией?"

Для спорных моментов проводились краткие sync-встречи (5-10 минут), где мы обсуждали архитектурные решения. Если разногласия сохранялись, обращались к техническому лиду или архитектору проекта.

Автоматизация и метрики

Часть проверок была автоматизирована:

• Static Code Analysis через Roslyn Analyzers
• Проверка стиля кода с помощью EditorConfig
• Юнит-тесты как обязательное требование для критических систем
• Проверка сборки на всех целевых платформах

Результаты и benefits

Такой системный подход давал tangible результаты:

• Снижение количества багов на 30-40% после внедрения
• Ускорение онбординга новых разработчиков
• Формирование единой кодовой базы даже в больших распределенных командах
• Передача знаний между разработчиками естественным образом

Code review был не просто формальностью, а инструментом непрерывного обучения и повышения качества продукта. Даже senior-разработчики получали ценную обратную связь, поскольку каждый специалист имел свою экспертизу в конкретных областях Unity (оптимизация графики, работа с анимациями, сетевое программирование и т.д.).