Тестовое задание для стажёра Backend (осенняя волна 2025)

Сервис назначения ревьюеров для Pull Request’ов

Как запустить?

docker-compose up --build -d db migrator pr-reviewer-service

Эндпоинт статистики

При обращении на http://localhost:8080/stats/assignments статистика по количеству ревью у юзеров и количество ревью на PR'ах выводится в следующем формате:

{
  "by_user": [
    {
      "user_id": "u9",
      "assignments": 1
    },
    {
      "user_id": "u57",
      "assignments": 1
    },
		...
		],
  "by_pr": [
    {
      "pull_request_id": "pr-26",
      "reviewers": 2
    },
    {
      "pull_request_id": "pr-11",
      "reviewers": 2
    },
		...
	]
}

Нагрузочное тестирование и его результаты

Подготовка и запуск нагрузочных тестов

• Запустить сервис:

docker-compose up --build -d db migrator pr-reviewer-service

• Запустить сидер:

go run ./cmd/seed

• Запустить k6 тестер через docker:

docker-compose run --rm k6

Краткие результаты теста:

  █ THRESHOLDS

    http_req_duration
    ✓ 'p(95)<300' p(95)=1.45ms

    technical_failures
    ✓ 'rate<0.001' rate=0.00%


  █ TOTAL RESULTS

    checks_total.......: 327     5.493937/s
    checks_succeeded...: 100.00% 327 out of 327
    checks_failed......: 0.00%   0 out of 327

    ✓ status is 200
    ✓ reassign technical success

Конфигурация линтера

:

run:
  timeout: 3m

linters:
  enable:
    - govet # стандартный анализатор Go
    - staticcheck # статический анализ
    - gosimple # упрощение кода
    - revive # стиль, потенциальные баги
    - errcheck # проверка, что ошибки не игнорируются
    - ineffassign  # неиспользуемые присваивания
    - gofumpt # форматирование (над gofmt)
    - goconst # вынос магических констант
    - gosec #  базовая проверка на безопасность

  disable:
    - depguard
    - funlen
    - unused

version: "2"

Описание задачи

Внутри команды требуется единый микросервис, который автоматически назначает ревьюеров на Pull Request’ы (PR), а также позволяет управлять командами и участниками. Взаимодействие происходит исключительно через HTTP API. Необходимо реализовать сервис, который назначает ревьюеров на PR из команды автора, позволяет выполнять переназначение ревьюверов и получать список PR’ов, назначенных конкретному пользователю, а также управлять командами и активностью пользователей. После merge PR изменение состава ревьюверов запрещено.

Общие вводные

Пользователь (User) — участник команды с уникальным идентификатором, именем и флагом активности isActive.

Команда (Team) — группа пользователей с уникальным именем.

Pull Request (PR) — сущность с идентификатором, названием, автором, статусом OPEN|MERGEDи списком назначенных ревьюверов (до 2).

1. При создании PR автоматически назначаются до двух активных ревьюверов из команды автора, исключая самого автора.
2. Переназначение заменяет одного ревьювера на случайного активного участника из команды заменяемого ревьювера.
3. После MERGED менять список ревьюверов нельзя.
4. Если доступных кандидатов меньше двух, назначается доступное количество (0/1).

Условия

• Используйте этот API (OpenAPI-спецификация будет предоставлена отдельным файлом — openapi.yaml).
• Объём данных умеренный (до 20 команд и до 200 пользователей), RPS — 5, SLI времени ответа — 300 мс, SLI успешности — 99.9%.
• Пользователь с isActive = false не должен назначаться на ревью.
• Операция merge должна быть идемпотентной — повторный вызов не приводит к ошибке и возвращает актуальное состояние PR.
• Сервис и его зависимости должны подниматься командой docker-compose up. Если решение предусматривает миграции, они также должны применяться при выполнении этой команды. Сервис должен быть доступен на порту 8080.

Дополнительные задания

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

• Добавить простой эндпоинт статистики (например, количество назначений по пользователям и/или по PR).
• Провести нагрузочное тестирование полученного решения и приложить краткие результаты тестирования к решению.
• Добавить метод массовой деактивации пользователей команды и безопасную переназначаемость открытых PR (стремиться уложиться в 100 мс для средних объёмов данных).
• Реализовать интеграционное или E2E-тестирование.
• Описать конфигурацию линтера.

Требования по стеку

Язык сервиса: предпочтительным будет Go, при этом вы можете выбрать любой, удобный вам.

База данных: предпочтительной будет PostgreSQL, при этом вы можете выбрать любую, удобную вам (допускается in-memory реализация).

Ход решения

Если у вас возникнут вопросы по заданию, ответы на которые вы не найдёте в описанных «Условиях», вы вольны принимать решения самостоятельно.
В таком случае приложите к проекту README-файл, в котором будет список вопросов и пояснения о том, какие допущения вы сделали и почему именно выбранным вами способом.

Оформление решения

Необходимо предоставить публичный git-репозиторий на любом публичном хосте (GitHub / GitLab / etc), содержащий в master/main ветке:

1. Код сервиса
2. Makefile c командами сборки проекта / Описанная в README.md инструкция по запуску
3. Описанные в README.md вопросы/проблемы, с которыми столкнулись, и ваша логика их решений (если требуется)