Статьи впервые опубликованы на портале Хабр:
- Использование GitHub в обучении студентов - https://habr.com/ru/post/533940/
- Вариант с форками - https://habr.com/ru/post/534198/
- Вариант командной работы - https://habr.com/ru/post/534292/
- Вариант командной работы с несколькими репозиториями - https://habr.com/ru/post/536590/
В своей преподавательской практике использую GitHub...
Но для начала давайте представлюсь. Зовут меня Старинин Андрей. И я преподаю программирование, хотя по первому образованию я биолог. А ещё - один из основателей и ведущих подкаста "IT за Edu".
Мой стек дисциплин:
- C++
- основы программирования
- основы ООП
- GUI-приложения (Qt)
- C#
- ООП
- сетевое программирование
- GUI-приложения (WPF)
- взаимодействие приложений и БД (ADO.Net)
- Базы данных
- проектирование БД
- SQLite
- MySQL
- Управление проектами
Кажется, что всего много. Но успеваем не сильно погрузиться в отдельные технологии. После какого-то времени (точно не помню уже какого) понял, что студентов можно, и даже нужно, "приучать" к системам управления версиями почти сразу - с начала обучения. Для обучения выбрал GitHub. Хотя Bitbucket тоже нравится. Да, я не учу студентов сразу по харду, они не сразу изучают git в CLI. Я их знакомлю сначала с web-интерфейсом GitHub'а. Потом рассказываю про GUI-клиенты. Из них мне нравится GitKraken. Но не заставляю их пользоваться тем, что нравится мне - они вольны выбирать сами чем пользоваться.
Постепенно - это примерно так:
- Просто показываю как выкладывать код
- Прошу их выкладывать свои решения и присылать мне ссылки на репозитории
- Выкладываю текст заданий и прошу ответы присылать через pull-request'ы
- Пробуем поработать в маленьких командах над одним репозиторием без веток
- Пробуем поработать небольшой командой над одним репозиторием с отдельными ветками
- Пробуем работать над большим проектом большой командой с несколькими репозиториями и ветками.
И вот такой постепенный подход стараюсь применять при изучении тем. Иногда темы заканчиваются быстрее, чем успеем перейти к большому или маленькому проекту. Но это несильно страшно. По изучении нескольких тем мы можем полученные знания объединить в один большой проект.
Не все студенты сразу всё понимают и принимают. Но тем интереснее и приятнее когда они "доходят". Ещё люблю подход: учимся на своих ошибках. Во время обучения есть возможность ошибаться и понять к чему это приводит.
Что мне нравится в GitHub при обучении?
- Поддержка аккаунтов для организаций, а в аккаунтах возможность создания команд с гибкими настройками доступов
- Поддержка Markdown-разметки. Можно более "красиво" оформлять задания.
- Система форков. Может любой человек сделать форк, а потом предложить запрос на слияние. Не всегда нужно всех студентов добавлять в команду.
- Возможность комментировать участки кода при проведении ревью. Очень удобно указывать на сильные и слабые моменты в программах.
- Возможность назначать ревьюером любого члена команды. Студенты должны уметь не только хорошо писать программы, но и проверять чужой код.
- Система issues. Можно давать другим командам студентов задание на проверку кода и выявления багов, с занесением всего в issues.
Для чего я приучаю студентов к GitHub'у?
- Создание своего портфолио уже с самого начала обучения, а не только под конец.
- Понимание принципов написания кода. Когда начинают чужой код проверять - многое понимают
- Понимание "соглашения об именовании". Пока не наступят на грабли разного именования в одной команде - не понимают. Ну или не все понимают
- Понимание как работать в команде. И как командам между собой взаимодействовать.
Прекрасно понимаю, что мои методы не самые лучшие и далеки от совершенства, да и от реальности далековаты. Но стараюсь их приблизить к реальности.
.Вариант с форками.
Начну с варианта, когда не обязательно добавлять студентов в аккаунт организации. Т.е. можно и в своём аккаунте делать репозитории с заданиями.
.Примерный порядок действия.
Создаёте репозиторий с названием задания.
В
README.md
добавляете текст задания и подробную (желательно, но не обязательно) инструкцию что и как должны сделать. Обязательно обращаете внимание на создание форка и после выполнения (читай, наполнения репозитория) создания запроса на слияние (pull request) с вашим исходным репозиторием.
Пример - https://github.com/college-VIVT/TerminalEmulator
В нужном месте сообщаете студентам задание и ссылку на репозиторий.
Ждёте выполнения задания, а точнее создания запроса на слияние.
Проверяете. Оставляете комментарии либо ко всему заданию целиком, либо к его отдельным частям.
Принимать (мерджить) запрос на слияние в данной ситуации не нужно. Если всё хорошо - то можно просто оставить комментарий в ревью кода. Если всё плохо - то не принимаете.
.Плюсы и минусы.
Плюсы:
- Не нужен аккаунт организации
- Можно рассылать любому количеству студентов, даже из разных групп или учебных заведений
Минусы:
- Нужно следить, чтобы не сделали мердж
- Нужно объяснять что такое форк и запрос на слияние (у некоторых моих студентов это вызвало дополнительные затруднения)
- Сложности с принятием запросов Approve . Мне хочется, чтобы в репозитории было только задание и не было кода решения от студентов.
Какие можно внести дополнения: добавить под каждого студента свою ветку, но это лишние действия при создании и дальнейшем наполнении репозитория.
.Вариант командной работы.
Продолжу вариантом про командную работу. Но рассмотрю ту его версию, когда нет большого числа репозиториев и веток. Про работу большой команды расскажу, наверное, в отдельном посте.
.Примерный порядок действия.
Создаёте репозиторий. В README.md добавляете текст задания. Также наполняете репозиторий предварительно необходимым минимумом (нужными файлами для выполнения задания). Создаёте необходимые ветви. Обычно создаю ветвь dev или develop
Студенты получив задания, делают ответвления от последнего коммита. Выполняют задания, коммитят. Задания можно выдавать как через issues, так и какой-нибудь сервис с Kanban или Scrum
Проверяете. Оставляете комментарии либо ко всему заданию целиком, либо к его отдельным частям.
Плюсы и минусы
Плюсы:
- Более приближенный к реальности вариант моделирования
- Можно назначать студентов в качестве ревьюеров кода. Даже преподавательского. Я люблю делать в коде специально ошибки как явные, так и неявные, чтобы студенты их находили и исправляли.
Минусы:
- Нужно создавать отдельный аккаунт для организации
- Нужно объяснить как работать с ветками и следить, чтобы пушили в нужную ветку.
Какие можно внести дополнения: связать репозиторий с Kanban- или Scrum-сервисом, чтобы выдача заданий фиксировалась в карточках на досках.
.Вариант командной работы с несколькими репозиториями.
Расскажу про "самый приближённый" к реалиям вариант, когда в рамках реализации одной программы возникают подпроекты и над ними трудятся разные команды в разных репозиториях.
.Примерный порядок действия.
Часть действий повторяются из предыдущего примера.
Создаёте репозиторий. В README.md добавляете текст задания. Также наполняете репозиторий предварительно необходимым минимумом (нужными файлами для выполнения задания). Создаёте необходимые ветви. Обычно создаю ветвь dev или develop
Студенты получив задания, клонируют репозиторий себе на локальные машины.
По мере обсуждения решения выявляются подпроекты. Создаются команды под каждый подпроект. Для каждого подпроекта создаётся свой репозиторий с предварительным наполнением.
Команды выполняют задания, коммитят, пушат. Задания можно выдавать как через issues, так и какой-нибудь сервис с Kanban или Scrum
Проверяете. Оставляете комментарии либо ко всему заданию целиком, либо к его отдельным частям.
Создаются релизы. Готовые DLL или ещё что берётся из релизов и подключается в основной проект.
Плюсы и минусы
Плюсы:
- Более приближенный к реальности вариант моделирования
- Можно назначать студентов в качестве ревьюеров кода. Даже преподавательского. Я люблю делать в коде специально ошибки как явные, так и неявные, чтобы студенты их находили и исправляли.
- Каждая команда работает над своим подпроектом
- Студенты пробуют межкомандное взаимодействие при разработке одного большого проекта.
Минусы:
- Нужно создавать отдельный аккаунт для организации
- Нужно объяснить как работать с ветками и следить, чтобы пушили в нужную ветку.
- Нужно объяснять что такое релиз, как происходит версионирование.
- Нужно объяснять как пишется и для чего нужна техдокументация.
Какие можно внести дополнения:
- связать репозиторий с Kanban- или Scrum-сервисом, чтобы выдача заданий фиксировалась в карточках на досках
- создавать не отдельные репозитории для каждого подпроекта, а использовать git submodules
Top comments (0)