Как был организован процесс валидации кода и code review, включая кросс-командное ревью?

Мы использовали совместную разработку с помощью системы контроля версий Git и платформы для управления репозиториями (например, Bitbucket или GitLab). Процесс код-ревью был организован следующим образом:

1. Создание ветки: Разработчик создает отдельную ветку для новой фичи или исправления ошибки (git checkout -b feature/my-new-feature).

2. Разработка и коммиты: В ветке выполняются изменения, которые фиксируются коммитами (git add ., git commit -m "Initial feature implementation").

3. Push в удаленный репозиторий: Ветка отправляется в удаленный репозиторий (git push origin feature/my-new-feature).

4. Создание Pull/Merge Request: Разработчик создает Pull Request (в Bitbucket) или Merge Request (в GitLab), указывая целевую ветку (например, develop или main). В описании указывается краткое описание изменений, ссылки на задачи в трекере (Jira, Trello и т.п.) и приложенные файлы (скриншоты, видео, диаграммы).

5. Назначение ревьюеров: Назначаются один или два разработчика из команды для проведения ревью.

6. Процесс ревью: Ревьюеры просматривают изменения в Pull/Merge Request. Они могут оставлять комментарии, предлагать улучшения, задавать вопросы.

   // Пример комментария во время ревью
   function fetchData() {
     // Возможно, здесь стоит добавить обработку ошибок при запросе данных
     return fetch('/api/data');
   }
   

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

8. Обновление Pull/Merge Request: Изменения автоматически отображаются в Pull/Merge Request после push в удаленный репозиторий.

9. Повторное ревью: Ревьюеры повторно просматривают изменения и дают одобрение.

10. Мердж ветки: После получения одобрения, ветка мержится в целевую ветку (обычно автоматизированно средствами платформы после прохождения CI/CD пайплайна).

Мы также использовали CI/CD пайплайн для автоматического запуска юнит-тестов, статического анализа кода (ESLint, Prettier) и сборки проекта перед мержем, что помогало выявлять ошибки на ранних этапах.

Критерии для успешного прохождения ревью включали:

• Соответствие требованиям задачи.
• Следование код-стайлу команды.
• НаличиеUnit-тестов для критически важной логики.
• Отсутствие очевидных ошибок и "костылей".
• Понятность кода для других членов команды.