Разработчик клиента
Команда и роли. Назначения и участие определяются работами периода; постоянное присутствие на всех встречах не требуется.
Результат роли — технически рассмотренные изменения в согласованном объёме и понятные решения по замечаниям. Участие включает ревью работы агента, помощь с кодовой базой и ручные изменения, если они отдельно поручены.
Регулярные действия
| Когда | Что делает | Результат и получатель | Различие по фазам и режимам |
|---|---|---|---|
| MR поступил на рассмотрение | Проверяет классификацию риска, выбирает объём ревью по регламенту; рассматривает код, соответствие постановке, влияние и проверки | Решение по MR для руководителя выполнения и уполномоченного на интеграцию | На PoC — после разбора инженером либо по иной выбранной на Подготовке схеме; на Пилоте получает MR напрямую от агента и выполняет ревью |
| Найдена проблема | Описывает конкретное отклонение, его последствия и ожидаемую доработку; различает обязательное исправление и рекомендацию | Выполнимое замечание в MR | На PoC цикл исправлений организует ИИ-инженер. На Пилоте разработчик даёт замечания непосредственно в MR и проверяет исправления; ИИ-инженер помогает при техническом сбое |
| MR обновлён | Проверяет устранение замечаний и затронутые изменения; при существенном расширении повторно оценивает риск | Актуальное решение по новой ревизии | Обе фазы |
| Тестировщик рассматривает автотесты | Помогает с техническим устройством тестов, зависимостями, поддерживаемостью и интеграцией | Техническое заключение по тестовой части | По потребности; смысл сценариев и достаточность покрытия оценивает тестировщик |
| Нужна экспертиза или ручная доработка | Отвечает по кодовой базе; при необходимости выполняет явно назначенную доработку и отражает затраты | Ответ или изменение с понятным авторством работы | Обе фазы |
По стратегии тестирования разработчик отвечает в своей области за техническое ревью unit- и интеграционных тестов, воспроизводимость запуска и зависимости. Вместе с тестировщиком определяет, какие проверки временными скриптами закрепить в репозитории, и проверяет, что утверждения действительно обнаруживают нужные ошибки.
Как меняется глубина ревью
На новой области стартовый вариант — подробное ревью всех MR. Затем для освоенных типов изменений можно перейти к подробному ревью сложных и рискованных MR и согласованной выборки типовых. Основания, классификация, выборка и возврат описаны в общем регламенте.
Для типовых MR вне подробной проверки сохраняются обязательные правила клиента и явная процедура интеграции. Разработчик не заявляет, что проверил код, который не рассматривал. Переход на Пилот меняет маршрут получения MR, но сам по себе не меняет глубину ревью.
Шаги внедрения
- Подготовка: предоставить правила репозитория и ревью, значимые примеры кода, определить проверяющего и владельца merge.
- PoC — неделя 1: подтвердить проектные правила кода и Git при адаптации литературы, проверить качество изменения и MR минимального прохода; цикл замечаний не является условием завершения онбординга.
- PoC — неделя 2 и недели 3–4: рассмотреть простые, затем целевые задачи, проверить цикл замечаний, выявить повторные ошибки и передать их ИИ-инженеру сопровождения для улучшения процесса.
- Пилот, при начале работы команды: принимать MR напрямую, соблюдать согласованный срок реакции, проверить работу обратной связи.
- Пилот, при расширении охвата: оценить риски новой области; начать её с подробной проверки.
- Пилот, при улучшении процесса: вместе с архитектором предложить обоснованное изменение режима и контролировать его последствия.
В личном прогрессе фиксируются ожидавшиеся и выполненные ревью, соблюдение сроков, конкретные заключения и вклад в устранение повторных ошибок. Количество замечаний не является целью: отсутствие замечаний допустимо при содержательной проверке.