Дизайн приложения для инбокса код-ревью

Структура инбокса код-ревью

Этот дизайн десктопного приложения представляет инбокс запросов на ревью и упоминаний GitHub как вертикально упорядоченное рабочее пространство. Левая панель начинается с «All 5», затем идут «Participating», «Mentions» и «Review requests 2». Основная колонка группирует работу на запросы на ревью, проверки CI, назначенные задачи и активность. Такая последовательность превращает несколько инженерных сигналов в один маршрут просмотра, а отдельные категории сохраняют достаточно контекста, чтобы решить, что требует внимания в первую очередь.

Запрос на ревью как доказательство

Первый элемент ревью указывает open-design/web PR #2371, называется «feat: orbit briefing card» и показывает «3 of 5 reviewers approved · waiting on you + cody». Ниже путь к файлу «src/components/OrbitBriefingCard.tsx» открывает компактный дифф с удалёнными и добавленными строками. Такое сочетание позволяет ревьюеру связать состояние одобрения с конкретным изменением. Компромисс — вертикальная плотность: фрагмент кода добавляет полезный контекст, но делает первый элемент заметно выше второго запроса.

Сценарии инженерной сортировки

Дизайн поддерживает несколько разных задач и не делает вид, что это один и тот же вид работы. Запросы на ревью требуют ответа или одобрения, проверки CI сигнализируют о неудачной верификации, назначенные задачи — это закреплённая за вами работа из бэклога, а активность фиксирует завершённое изменение. Раздельные панели делают границы задач видимыми. Компромисс в том, что связанные сигналы остаются распределёнными по странице и не сводятся в одну общую оценку.

Поток чтения рабочего пространства

Рабочее пространство использует широкую основную колонку и компактную панель навигации вместо одинаковых плиток дашборда. В поставляемом CSS задана максимальная ширина страницы 1280px, а видимая раскладка отдаёт панелям событий большую часть горизонтального места. Такая пропорция вмещает длинные названия репозиториев, заголовки pull request, временные метки и строки кода, не заставляя помещать каждый элемент в отдельную колонку карточек. Цена — длинный вертикальный просмотр, особенно когда запрос на ревью включает встроенный дифф.

От фильтра к деталям

Поле поиска сверху содержит подсказку Type / to search, но обработчика поиска у него нет. Фильтры боковой панели работают на предоставленных локальных группах: Participating показывает запросы на ревью и назначенные задачи, Review requests — группу ревью, а Mentions — только группу с маркером упоминания из исходных данных. Этот маркер привязан к назначенным задачам, а не к строке ревью, где нужен ответ. Фильтрация — локальное поведение представления, а не подключённый поиск GitHub или сервис инбокса.

Смена состояний через цвет

Цвет передаёт состояние в иначе похожих строках. Зелёный отмечает открытые или выглядящие здоровыми состояния репозитория, жёлтый — работу, ожидающую ответа, красный — упавший тест, фиолетовый — слитый элемент активности. Метки задач используют отдельные синюю и розовую плашки для «backend» и «p1». Так просматривать быстрее, чем читать каждое предложение, но цвет остаётся дополнительным: каждое состояние записано и текстом, поэтому смысл сохраняется, когда одного цвета недостаточно.

Границы возможностей

В исходном коде реализованы локальная фильтрация по категориям и построение исходящих ссылок GitHub для строк и заголовков. Эти ссылки ведут на фиксированный репозиторий с использованием показанных демонстрационных идентификаторов; их наличие не подтверждает показанные pull request, задачи или результаты CI. Поиск, получение инбокса с аутентификацией, сохраняемое состояние ревью и реальный запуск тестов не реализованы. Имена, счётчики, временные метки, состояния одобрения и фрагменты кода остаются иллюстративным содержимым для сценария дизайна.