Формат чемпионата: спринты, критерии и вопросы
Зачем это нужно
Две прошлые главы были про то, как сдать модуль и как его показать. Эта — про то, что происходит между началом работы и сдачей: как устроено само задание.
Тут есть неожиданное. Часть критериев оценивает не код, а порядок работы: откуда отведена ветка, слит ли запрос на слияние, лежит ли проект в репозитории файлами. Эти баллы не требуют ни знаний, ни времени — их теряют просто потому, что не прочитали критерий.
Всё в этой главе взято с настоящей рабочей доски подготовки: формулировки критериев, устройство рабочего дня и вопросы, которые участники в самом деле задавали экспертам.
Спринт — это рабочий день
Первое, что сбивает: слово «спринт». В обычной разработке спринт — это две недели. Здесь критерий формулируется так:
Создана ветка для спринта. Проект корректно сохранён в ветку Спринт X и не требует дополнительного разархивирования. Выполнен pull request ветки Спринта X в ветку main и закрыт.
X — номер дня работы. В конце дня делаешь Pull Request из ветки
sprint-Xв веткуmain. В начале работы создаёшь веткуsprint-Xот веткиmain, весь день работаешь в ней, в конце дня делаешь pull request в веткуmain, и так каждый рабочий день.
Три отдельных требования в одном абзаце, и каждое оценивается само по себе:
- Ветка за день есть и названа по номеру дня.
- Запрос на слияние сделан и закрыт — не «создан и висит», а именно слит.
- Проект лежит файлами, а не архивом: «не требует дополнительного разархивирования».
Третье требование выглядит странно, пока не увидишь, как его нарушают. Участник в конце дня жмёт «экспортировать проект», получает proekt.zip и коммитит его — «так надёжнее, точно ничего не потеряется». Критерий при этом не выполнен: проверяющий должен открыть репозиторий и увидеть код, а не распаковывать архив.
Откуда отводить ветку
Вот место, где теряют баллы чаще всего, и заметить это можно только в запросе на слияние.
День первый. Ветка от main, коммит, и запрос вечером не слили — забыли или не успели.
День второй. Утром человек просто создаёт новую ветку там, где стоит, — то есть от вчерашней:
git switch -c sprint-2
echo b > f2.txt && git add -A && git commit -m "спринт 2: экраны"
git log --oneline main..sprint-2
b5e563a спринт 2: экраны
f94c346 спринт 1: каркас
В запрос за второй день уехала вчерашняя работа. Формально спринт 2 теперь содержит то, что должно было быть засчитано за спринт 1, и приёмка превращается в спор.
Как надо: вчерашний запрос слить, а ветку дня отвести явно от main:
git switch -c sprint-2 main
a4d9619 спринт 2: экраны
Команда git log --oneline main..sprint-X — единственная проверка, которая нужна перед отправкой запроса. Одна строка — один день работы. Две строки вместо одной значат, что ветку отвели не оттуда.
Критерии — это список задач
Второе, что стоит понять про формат: критерии написаны проверяемыми пунктами, и каждый пункт — это готовая задача. Вот как выглядят настоящие формулировки с доски подготовки по мобильной разработке:
Создайте цвета
Создайте тему с типографикой
Создайте шрифт
Создайте компоненты кнопок
Создайте инпут
Создайте компонент селект
Создайте компонент Поиск
Создайте компонент BottomSheet
Создайте компонент TabBar
Создайте компонент карточки
Создайте компонент «Хэдер»
Все компоненты библиотеки адаптивны
И отдельно — по работе с сетью:
Сделан запрос Создание пользователя
Сделан запрос Получение каталога
Сделан запрос Поиск
Сделан запрос Получение описания товара
Сделан запрос Добавление в корзину
Сделан запрос Изменение корзины
Сделан запрос Оформление заказа
В случае отсутствия соединения с сетью Интернет необходимо вернуть ошибку
В случае получения ошибки от сервера необходимо вернуть ошибку
Обратите внимание на две последние строки. Обработка отсутствия сети и ошибки сервера — отдельные оцениваемые пункты, а не «хорошо бы ещё». Приложение, которое показывает каталог, но молча зависает без интернета, теряет здесь баллы независимо от того, как красиво нарисован каталог.
Практический вывод: критерии переносят в трекер дословно, по пункту на задачу, и закрывают по одной. Не «сделать UI-kit», а двенадцать отдельных строк. Иначе в конце дня непонятно, что именно готово.
Вопросы экспертам
Третья часть формата, про которую обычно не думают заранее. Задание пишут люди, макет рисуют люди, и расхождения в них — норма. Вот настоящие вопросы, заданные экспертам в ходе подготовки:
В фигме кривая типография
Хедер из ui-kita не соответствует используемому
Не соответствие дизайна модального окна
Пароль должен содержать пробел в задании
Требования к паролю
Вход по паролю или биометрии
Какой тип кэширования
Уточнение по сохранении состояния
Каталог поменять на поиск
неправильное название кнопки
В критериях оценки 2 спринта указано "Выполнен merge для спринта 1 с веткой main"
Это не придирки и не жалобы. Каждая строка — место, где задание можно понять двумя способами, и выбор наугад стоит баллов.
Посмотрите на «Пароль должен содержать пробел в задании». Выглядит как опечатка в требованиях — и ровно поэтому об этом надо спросить. Если эксперт скажет «да, так и есть», проверка пароля пишется иначе; если «опечатка» — тоже иначе. Гадать — это подбрасывать монетку на оцениваемом пункте.
Как с этим работать. На доске подготовки под вопросы заведены отдельные колонки: «Вопросы», «Вопросы (чекпоинт)», «Донести до экспертов». Смысл в накоплении: вопросы копятся по ходу работы и задаются пачкой, когда появляется возможность. Дёргать эксперта по одному вопросу и дорого по времени, и не всегда возможно.
И последнее: ответ записывают. Через два дня «нам вроде разрешили» — не аргумент при приёмке.
Типичные потери баллов
Потеря 1. Ветка дня отведена от вчерашней.
Проверяется одной командой до отправки запроса.
Потеря 2. Запрос создан, но не слит.
В критерии сказано «и закрыт». Вечером остаётся тридцать секунд работы.
Потеря 3. Проект залит архивом.
git add -f proekt.zip && git commit -m "залил архив проекта"
git ls-files
proekt.zip
Критерий требует, чтобы проект не нуждался в разархивировании.
Потеря 4. Расхождение макета и задания решено молча.
Решили сами — получили несоответствие при приёмке. Спросили — получили критерий.
Потеря 5. Обработка отказов оставлена «на потом».
«Нет сети» и «ошибка сервера» — отдельные пункты, и они обычно не успеваются именно потому, что их считают не основной работой.
Потеря 6. Критерии прочитаны один раз в начале.
Их читают перед сдачей ещё раз, по списку. Это пять минут, которые возвращают больше, чем последняя правка кода.
Шпаргалка по главе
| Что нужно | Как |
|---|---|
| Ветка дня | git switch -c sprint-X main — обязательно с main |
| Что уедет в запрос | git log --oneline main..sprint-X |
| Слить вечером | запрос на слияние в main, и закрыть его |
| Проверить, что нет архива | git ls-files | grep -iE "\.(zip|rar|7z)$" |
| Критерии | перенести дословно, по пункту на задачу |
| Вопросы | копить и задавать пачкой на чекпоинте |
| Ответ эксперта | записать письменно |
| Перед сдачей | пройти критерии по списку ещё раз |
Словарь главы
| Термин | Что это |
|---|---|
| Спринт | Один рабочий день; ему соответствует ветка sprint-X |
| Критерий | Проверяемый пункт оценки; фактически готовая задача |
| Чекпоинт | Момент, когда можно задать накопленные вопросы экспертам |
main..sprint-X | Коммиты, которых нет в main — ровно содержимое запроса |
| Запрос на слияние | Pull request; засчитывается только закрытый |
| Разархивирование | То, чего проверяющий делать не должен: проект лежит файлами |
Цель: скорость ≥ 95 зн/мин, точность ≥ 90%
git switch -c sprint-2 main
Что должен уметь после главы
- объяснить, что спринт здесь — рабочий день, и назвать три требования критерия;
- отвести ветку дня от
mainи проверить, что уедет в запрос; - узнать по выводу
git log main..sprint-X, что ветку отвели не оттуда; - перенести критерии в трекер дословно, по пункту на задачу;
- накапливать вопросы экспертам и записывать ответы;
- назвать шесть мест, где баллы теряются без всякой связи с кодом.
Проверка по главе
Сводная проверка по всей главе: 10 вопросов, 5:00 на всё, без подсказок по ходу. Вопросы показываются по одному, ответ изменить нельзя. Если время выйдет — экзамен завершится с тем, что успел ответить. Пересдавать можно сколько угодно раз.
Куда дальше: проверенные ресурсы
- Официальный сайт «Профессионалов» — правила, компетенции и документы чемпионата.
- git switch — почему основу ветки указывают явно.
- Сравнение веток:
git log A..B— что именно означает две точки. - About pull requests — GitHub Docs — жизненный цикл запроса и что значит «закрыт».
Комментарии
Обсуждение живёт в GitHub Discussions и грузится с чужого домена — поэтому только по нажатию.