🚀 2 недели в проекте: стал тимлидом фронтенда
Проджект принял моё предложение: следующий спринт целиком посвящаем эпику «Управление пользователями и авторизация». Задача — чтобы к концу недели работал сценарий "регистрация → логин → выход" без интеграционных ошибок.
И да, меня официально назначили ответственным за фронтенд (в GitLab теперь мейнтейнер — смогу мержить). Цель не изменилась — техническая координация разработки, теперь для этого больше возможностей. В фокусе: код-ревью, решение стыков с бэком, порядок в процессах.
Что сделаю за неделю: · Проведу ревью готовых задач (это новая обязанность) · Сам сделаю одну задачу из спринта · Пофикшу пару проблем интеграции в базовом сценарии · Зафиксирую в документации правила работы с Git (ветки, PR, ревью)
По правилам стажировки, общего тестового стенда у нас пока не будет. Но на ближайшем демо покажем свежие фичи команде так, чтобы можно было покликать и увидеть. Через удобство демки подведу к мысли, что нужен инструмент для локального подъёма полного окружения. Если сразу предложить готовое — не приживётся. А когда сами почувствуют боль и облегчение от решения, возьмут с радостью.
Обещал рассказать, что изменилось с ветками за неделю: · Есть стабильные ветки (main, конечно, была и раньше, но не актуальная) · Рабочие ветки создаём от стабильных · После создания merge request в стабильную ветку — отдаём на тестирование
Тривиально? Да. Но до этого было не понятно, где искать фичу, которая отправлена на тестирование.
(для тех, кто впервые читает мои заметки: это история о прокачке навыков управления разработкой на стажировке. Проект учебный, а команда из 7 человек, проблемы и процессы — самые настоящие)
Конструктивная критика приветствуется 👇
· 13.05
за пару недель взять координацию фронтенда и выстроить процессы с ветками и ревью - уже ощутимый прогресс. стоит фиксировать конкретные цифры: сколько pr прошло без возвратов, как изменилось время на интеграцию после новых правил. такие кейсы потом сильно работают на собеседованиях при переходе на middle или lead. ещё полезно вести короткий лог, какие боли команды закрылись документацией, это помогает показать влияние без воды.
ответить
коммент удалён