В Академическом университете постоянно внедряются новые подходы к преподаванию.
Программы, задания и сам процесс изменены таким образом, чтобы предоставить ученику наиболее полные и актуальные знания, а преподавателю возможность попробовать более эффективные методы.
Вот и в прошлом семестре вместо того, чтобы сдавать задания по Java «на А4 и по ГОСТу», мы и мусорное ведро Мы решили делать всё «как большие парни»: использовать Git, CI и код-ревью.
В этом посте я поделюсь с вами возникшими проблемами, их решением, плюсами и минусами такого подхода, а также некоторыми мыслями на будущее.
Проблемы со стандартными подходами
Вопрос подготовки и проверки домашних заданий и тестов встал перед нами, как только мы узнали, что будем преподавать Java. К тому времени мы, будучи студентами, побывали в разных университетах и испробовали на себе множество подходов к проверке дистанционного управления, например, «принеси на флешке» или «распечатай на бумажке» (даже не буду заморачиваться перечисление недостатков этих двух).К тому моменту нам показался наиболее удобным подход, практикуемый в AU: студент отправляет решение по электронной почте и вступает в переписку с преподавателем.
Однако нам не все понравилось в этом подходе:
- У преподавателя много рутины: решение нужно перенести на свой компьютер, запустить, протестировать, просмотреть и написать все комментарии в письме.
- Дополнительное ожидание для ученика и нагрузка для преподавателя, т.к.
полностью убедиться в правильности своего решения студент может только отправив его преподавателю и дождавшись от него ответа.
Такой подход частично исключает рутину, но поскольку преподаватель по-прежнему проверяет решение вручную и пишет комментарии по почте, студенту все равно приходится ждать ответа, чтобы понять, что с решением что-то не так.
Немного подумав, мы решили, что комбинация «VCS + публичный CI-сервер + инструмент проверки кода» избавит нас от всех вышеперечисленных проблем, а использование сторонних сервисов также избавит нас от необходимости всё это настраивать.
Организация работы
Репозиторий было решено организовать следующим образом: для каждой задачи создать отдельную ветку, содержащую README с описанием того, что нужно сделать, а также Maven-проект со скелетом решения и тестами к нему.В начале семестра студент разветвляет репозиторий, а затем просто переключается на нужную ветку, вносит изменения, фиксирует и отправляет запрос на включение.
PR автоматически собирается и тестируется; если контрольные работы не сданы, то студенту необходимо выполнить работу; если все хорошо, то преподаватель проверяет код и оставляет комментарии или закрывает ПР и ставит оценку.
В отличие от подхода с одним репозиторием и директорией для каждого студента, такая организация исключает возможные проблемы при слиянии изменений, позволяет поддерживать репозиторий в чистоте, а также защищает от вандализма, хотя прецедентов этому в АС, к счастью, не было.
.
Выбор услуг
С сервисом VCS все было просто и понятно: Github. Исторически сложилось так, что у нас и у большинства студентов были там аккаунты; это стало ключевым плюсом.Кроме того, было решено просмотреть там код и оставить комментарии.
С сервисом CI дела обстояли немного сложнее.
Изначально мы решили использовать Travis CI и какое-то время нас всех это устраивало.
Однако со временем наши требования изменились: помимо открытых тестов, доступных непосредственно из хранилища заданий, мы хотели сделать еще несколько закрытых — чтобы студенты могли самостоятельно подумать о различных тонкостях и крайних случаях.
Мы создали приватный репозиторий, изменили сборку так, чтобы этот репозиторий добавлялся как подмодуль к основному, и добавили зашифрованные переменные с логином и паролем, чтобы Трэвис мог клонировать приватный репозиторий.
Все было хорошо, пока один из студентов не попытался сделать запрос на включение.
Оказалось, что зашифрованные переменные недоступны из PR-сборок и мы это не проверяли.
Быстрый поиск по остальным CI-сервисам привел нас к Semaphore CI. В отличие от Travis, он поддерживает загрузку секретных SSH-ключей, которые можно использовать в сборке для доступа к приватным репозиториям, а это именно то, что нам нужно.
Подводные камни и минусы
Первой проблемой, с которой мы столкнулись, был, как ни странно, сам Git. Ребятам не всегда удавалось выложить свои решения на Github. Причиной этого было то, что после обновления моего форка и перехода в новую ветку, в нем удаленным стал основной репозиторий, а не форк.Об этой тонкости стоит упомянуть отдельно.
Вторая проблема заключалась в отсутствии правил именования коммитов и PR. В результате после первого домашнего задания мы получили кучу ПР с названиями типа «исправить», «1-е хв», «мое домашнее задание» и т. д. Все это осложнялось еще и тем, что идентифицировать ученика было практически невозможно.
по имени пользователя, потому что не у всех был заполненный профиль.
Для последующих задач мы, конечно, ввели строгие правила, но первое время пришлось потрудиться.
Главный недостаток этого подхода в том, что не для всех задач можно написать содержательные тесты.
Например, одна из задач по дженерикам заключалась в написании собственного функционального Java. Объем кода в этой задаче был минимальным, а главная прелесть заключалась в том, чтобы придумать правильные сигнатуры для функций.
Чтобы протестировать его должным образом, пришлось бы придумать сложные иерархии и протестировать различные сложные случаи; Это заняло бы больше времени, чем проверка работы вручную.
Также к задачам, для которых писать тесты сложно и дорого, относятся многопоточные задачи.
Довольно многие также считают недостатком наличие чужих решений — кто захочет писать ДД самостоятельно, если у соседа все готово и даже сдано.
Лично я не считаю это недостатком, потому что желающие схитрить все равно найдут способ это сделать.
Выводы и планы на будущее
Опыт использования данного подхода можно считать положительным.Несмотря на некоторые проблемы и неровности в начале, к середине и концу семестра все наладилось и заработало как надо.
Нам было удобно проверять решения, и я надеюсь, что ребятам было удобно их отправлять.
Во всяком случае, по итогам семестра только один человек из моей группы из десяти человек выразил недовольство таким способом сдачи задания.
Логичным развитием такого подхода было бы добавление других полезных сервисов, например, автоматической проверки стиля или статического анализа кода.
Еще было бы очень удобно научить Github автоматически назначать рецензента для пиара.
И вообще нет предела совершенству.
Теги: #github #проверка кода #процесс обучения #travis ci #semaphore-ci #проверка домашнего задания
-
Олимпиада На Iphone
19 Oct, 24 -
Структурирование Аспектов 2
19 Oct, 24 -
Заработная Плата Php-Программистов
19 Oct, 24 -
Научная Фантастика Не Успевает За Прогрессом
19 Oct, 24 -
Google Опубликовал Отчет О Надежности Дисков
19 Oct, 24 -
Пульс Блогосферы.
19 Oct, 24
