DEV Community

Старинин Андрей
Старинин Андрей

Posted on

Использование GitHub в обучении студентов

Статьи впервые опубликованы на портале Хабр:


В своей преподавательской практике использую GitHub...

Но для начала давайте представлюсь. Зовут меня Старинин Андрей. И я преподаю программирование, хотя по первому образованию я биолог. А ещё - один из основателей и ведущих подкаста "IT за Edu".

Мой стек дисциплин:

  • C++
    • основы программирования
    • основы ООП
    • GUI-приложения (Qt)
  • C#
    • ООП
    • сетевое программирование
    • GUI-приложения (WPF)
    • взаимодействие приложений и БД (ADO.Net)
  • Базы данных
    • проектирование БД
    • SQLite
    • MySQL
  • Управление проектами

Кажется, что всего много. Но успеваем не сильно погрузиться в отдельные технологии. После какого-то времени (точно не помню уже какого) понял, что студентов можно, и даже нужно, "приучать" к системам управления версиями почти сразу - с начала обучения. Для обучения выбрал GitHub. Хотя Bitbucket тоже нравится. Да, я не учу студентов сразу по харду, они не сразу изучают git в CLI. Я их знакомлю сначала с web-интерфейсом GitHub'а. Потом рассказываю про GUI-клиенты. Из них мне нравится GitKraken. Но не заставляю их пользоваться тем, что нравится мне - они вольны выбирать сами чем пользоваться.

Постепенно - это примерно так:

  1. Просто показываю как выкладывать код
  2. Прошу их выкладывать свои решения и присылать мне ссылки на репозитории
  3. Выкладываю текст заданий и прошу ответы присылать через pull-request'ы
  4. Пробуем поработать в маленьких командах над одним репозиторием без веток
  5. Пробуем поработать небольшой командой над одним репозиторием с отдельными ветками
  6. Пробуем работать над большим проектом большой командой с несколькими репозиториями и ветками.

И вот такой постепенный подход стараюсь применять при изучении тем. Иногда темы заканчиваются быстрее, чем успеем перейти к большому или маленькому проекту. Но это несильно страшно. По изучении нескольких тем мы можем полученные знания объединить в один большой проект.

Не все студенты сразу всё понимают и принимают. Но тем интереснее и приятнее когда они "доходят". Ещё люблю подход: учимся на своих ошибках. Во время обучения есть возможность ошибаться и понять к чему это приводит.

Что мне нравится в GitHub при обучении?

  • Поддержка аккаунтов для организаций, а в аккаунтах возможность создания команд с гибкими настройками доступов

github organizations
github organizations teams
github organizations teams role

  • Поддержка Markdown-разметки. Можно более "красиво" оформлять задания. github markdown
  • Система форков. Может любой человек сделать форк, а потом предложить запрос на слияние. Не всегда нужно всех студентов добавлять в команду. github forks
  • Возможность комментировать участки кода при проведении ревью. Очень удобно указывать на сильные и слабые моменты в программах. github codereview
  • Возможность назначать ревьюером любого члена команды. Студенты должны уметь не только хорошо писать программы, но и проверять чужой код.
  • Система issues. Можно давать другим командам студентов задание на проверку кода и выявления багов, с занесением всего в issues. github issues

Для чего я приучаю студентов к GitHub'у?

  • Создание своего портфолио уже с самого начала обучения, а не только под конец.
  • Понимание принципов написания кода. Когда начинают чужой код проверять - многое понимают
  • Понимание "соглашения об именовании". Пока не наступят на грабли разного именования в одной команде - не понимают. Ну или не все понимают
  • Понимание как работать в команде. И как командам между собой взаимодействовать.

Прекрасно понимаю, что мои методы не самые лучшие и далеки от совершенства, да и от реальности далековаты. Но стараюсь их приблизить к реальности.

.Вариант с форками.

Начну с варианта, когда не обязательно добавлять студентов в аккаунт организации. Т.е. можно и в своём аккаунте делать репозитории с заданиями.

.Примерный порядок действия.

  • Создаёте репозиторий с названием задания.

  • В README.md добавляете текст задания и подробную (желательно, но не обязательно) инструкцию что и как должны сделать. Обязательно обращаете внимание на создание форка и после выполнения (читай, наполнения репозитория) создания запроса на слияние (pull request) с вашим исходным репозиторием.
    Пример - https://github.com/college-VIVT/TerminalEmulator
    В нужном месте сообщаете студентам задание и ссылку на репозиторий.
    readme

  • Ждёте выполнения задания, а точнее создания запроса на слияние.
    pull requests

  • Проверяете. Оставляете комментарии либо ко всему заданию целиком, либо к его отдельным частям.
    code review
    code review

  • Принимать (мерджить) запрос на слияние в данной ситуации не нужно. Если всё хорошо - то можно просто оставить комментарий в ревью кода. Если всё плохо - то не принимаете.

.Плюсы и минусы.

Плюсы:
  • Не нужен аккаунт организации
  • Можно рассылать любому количеству студентов, даже из разных групп или учебных заведений
Минусы:
  • Нужно следить, чтобы не сделали мердж
  • Нужно объяснять что такое форк и запрос на слияние (у некоторых моих студентов это вызвало дополнительные затруднения)
  • Сложности с принятием запросов Approve . Мне хочется, чтобы в репозитории было только задание и не было кода решения от студентов.

Какие можно внести дополнения: добавить под каждого студента свою ветку, но это лишние действия при создании и дальнейшем наполнении репозитория.

.Вариант командной работы.

Продолжу вариантом про командную работу. Но рассмотрю ту его версию, когда нет большого числа репозиториев и веток. Про работу большой команды расскажу, наверное, в отдельном посте.

.Примерный порядок действия.

  • Создаёте аккаунт организации
    account organization

  • Добавляете в него студентов.
    add students to organization

  • Создаёте репозиторий. В README.md добавляете текст задания. Также наполняете репозиторий предварительно необходимым минимумом (нужными файлами для выполнения задания). Создаёте необходимые ветви. Обычно создаю ветвь dev или develop
    create repo

  • Студенты получив задания, делают ответвления от последнего коммита. Выполняют задания, коммитят. Задания можно выдавать как через issues, так и какой-нибудь сервис с Kanban или Scrum
    create issues

  • Создают запрос на слияние
    create pull request

  • Проверяете. Оставляете комментарии либо ко всему заданию целиком, либо к его отдельным частям.
    code review
    code review

Плюсы и минусы

Плюсы:
  • Более приближенный к реальности вариант моделирования
  • Можно назначать студентов в качестве ревьюеров кода. Даже преподавательского. Я люблю делать в коде специально ошибки как явные, так и неявные, чтобы студенты их находили и исправляли.
Минусы:
  • Нужно создавать отдельный аккаунт для организации
  • Нужно объяснить как работать с ветками и следить, чтобы пушили в нужную ветку.

Какие можно внести дополнения: связать репозиторий с Kanban- или Scrum-сервисом, чтобы выдача заданий фиксировалась в карточках на досках.

.Вариант командной работы с несколькими репозиториями.

Расскажу про "самый приближённый" к реалиям вариант, когда в рамках реализации одной программы возникают подпроекты и над ними трудятся разные команды в разных репозиториях.

.Примерный порядок действия.

Часть действий повторяются из предыдущего примера.

  • Создаёте аккаунт организации
    account organization

  • Добавляете в него студентов.
    add students to organization

  • Создаёте репозиторий. В README.md добавляете текст задания. Также наполняете репозиторий предварительно необходимым минимумом (нужными файлами для выполнения задания). Создаёте необходимые ветви. Обычно создаю ветвь dev или develop
    create repo

  • Студенты получив задания, клонируют репозиторий себе на локальные машины.
    clone repo
    clone repo

  • По мере обсуждения решения выявляются подпроекты. Создаются команды под каждый подпроект. Для каждого подпроекта создаётся свой репозиторий с предварительным наполнением.
    teams
    teams

  • Команды выполняют задания, коммитят, пушат. Задания можно выдавать как через issues, так и какой-нибудь сервис с Kanban или Scrum
    github projects

  • Создают запрос на слияние
    create pull request

  • Проверяете. Оставляете комментарии либо ко всему заданию целиком, либо к его отдельным частям.
    code review
    code review

  • Создаются релизы. Готовые DLL или ещё что берётся из релизов и подключается в основной проект.
    realese

  • В каждой команде ведётся техдокументация.
    documentation

Плюсы и минусы

Плюсы:
  • Более приближенный к реальности вариант моделирования
  • Можно назначать студентов в качестве ревьюеров кода. Даже преподавательского. Я люблю делать в коде специально ошибки как явные, так и неявные, чтобы студенты их находили и исправляли.
  • Каждая команда работает над своим подпроектом
  • Студенты пробуют межкомандное взаимодействие при разработке одного большого проекта.
Минусы:
  • Нужно создавать отдельный аккаунт для организации
  • Нужно объяснить как работать с ветками и следить, чтобы пушили в нужную ветку.
  • Нужно объяснять что такое релиз, как происходит версионирование.
  • Нужно объяснять как пишется и для чего нужна техдокументация.
Какие можно внести дополнения:
  • связать репозиторий с Kanban- или Scrum-сервисом, чтобы выдача заданий фиксировалась в карточках на досках
  • создавать не отдельные репозитории для каждого подпроекта, а использовать git submodules

Top comments (0)