DEV Community: Старинин Андрей

Использование GitHub в обучении студентов. Автоматизация проверок.

Старинин Андрей — Sun, 09 Oct 2022 14:53:38 +0000

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

Использование GitHub в обучении студентов. Автоматизация проверок. Часть I. - https://habr.com/p/687940/
Использование GitHub в обучении студентов. Автоматизация проверок. Часть II. - https://habr.com/ru/post/692260/

Статья будет обновляться по мере появления нового материала

В конце декабря 2020 года я написал статью по своему опыту использования GitHub в обучении студентов

Ниже буду рассказывать об автоматизации проверки кода студентов. Примеры будут про C#, т.к. это мой основной язык, на котором я преподаю программирование.

Часть I. Code style

Для меня при обучении программированию важно, чтобы студенты умели не только правильно решать задания, но и красиво писать код. В обучении и проверки заданий я использую EditorConfig, dotnet cli и GitHub Actions. Но обо всём по порядку.

EditorConfig

Для C# существуют различные рекомендации по стилю кода, по именованию. Например:

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

Для формализации описания правил использую файл .editorconfig, как сказано в документации Microsoft. За основу взял файл из примера и немного его дополнил. Вот мой файл .editorconfig для C#. Сей файл помещается в корень решения. Это необходимо чтобы правила оформления применялись для всего решения. При этом не важно в какой IDE вы пишите код, EditorConfig поддерживается многими редакторами и средами разработки. Подробнее о поддержке редакторами и формате файла можете почитать на оф. сайте EditorConfig.

`dotnet format`

Для ручной проверки написанного кода на соответствие правил оформления можно использовать команду dotnet format. Подробнее о команде можно узнать из оф. документации Microsoft. К тому же она умеет и автоматически исправлять и приводить код в соответствии с правилами в .editorconfig. Но мне это не нужно для проверки заданий от студента. Наоборот нужно получить только отчёт об оформлении кода. Поэтому я использую команду со следующими ключами: dotnet format --no-restore --verify-no-changes

GitHub Actions

Вручную проверять конечно хорошо, но мне необходимо автоматизировать это действие. Для этого я буду использовать GitHub Actions. Сей инструмент/сервис от GitHub очень мощный и позволяет много чего автоматизировать. Я буду использовать только маленькую толику его возможностей. Почитать подробнее об GitHub Actions можно в официальной документации или в различных статьях, например в этой статье.

Порядок действий

Для начала необходимо задание залить в репозиторий на GitHub.
После этого нужно объяснить студентам что сдают они задние через pull request из своего форка. Подробнее о таком способе работы у меня написано здесь.
Добавляете в корень репозитория файл .editorconfig с вашим набором правил.
Создаётся файл формата YAML dotnet-format.yml для проверки кода на соответствие code style. Файл должен находиться по следующему пути: ./.github/workflows/ (в корне проекта создаётся папка .github, а в ней подпапка workflows). Содержимое файла приведено ниже.

name: dotnet format
on:
  pull_request:
    branches: [ "master" ]

  jobs:
  check-format:
    runs-on: windows-latest

      steps:
      - name: Setup .NET Core
        uses: actions/setup-dotnet@v2
          with:
          dotnet-version: '6.0.x'

      - name: Check out code
        uses: actions/checkout@v3

      - name: Run dotnet format
        run: dotnet format --no-restore --verify-no-changes

Если кратко, то содержимое файла описывает следующее:

файл будет запускаться при создании запросов на слияние (pull request) в ветку master
в виртуальной среде с Windows будет устанавливаться .NET 6
проверка форматирования кода с выдачей отчёта

Пример вывода отчёта:

Вот так, не сильно сложно, можно упростить себе работу по проверке заданий от студентов.

Часть II. Unit-тесты

Добавить в репозиторий проверку прохождения unit-тестов на C# нет ничего сложного. При создании workflow в GitHub Actions можно выбрать workflow специфичные для .Net.

Предлагаемого варианта хватит с лихвой. Я только немного подправляю код "под себя".

name: dotnet test

on:
  pull_request:
    branches: [ "master" ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3

    - name: Setup .NET
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: 6.0.x

    - name: Restore dependencies
      run: dotnet restore

    - name: Build
      run: dotnet build --no-restore

    - name: Test
      run: dotnet test --no-build --verbosity normal

Почему я использую отдельный файл для автоматизации прохождения тестирования, а не добавляю этапы в один workflow? Ответ простой: чтобы разграничить вывод результатов, чтобы понимать что прошло, а что нет. Так проще потом объяснять студентам: тесты пройдены, а вот правила оформления кода не соблюдаются.

После выполнения мы получим "небольшой отчёт", примерно как на изображениях ниже.

Помимо прохождения самих unit-тестов в данном workflow происходит ещё выполнение сборки. Следовательно мы увидим предупреждения и ошибки сборки проектов решения.

Остаётся дело за малым: чтобы студенты научились писать unit-тесты. Почему я не советую писать unit-тесты преподавателю заранее? Потому, что я стараюсь давать такие задания, для которых сложно сразу написать тесты. И мне важно чтобы студенты учились самостоятельно проектировать библиотеки классов. А если они их проектируют самостоятельно - то и подходить к написанию тестов нужно индивидуально. И да, этот подход влечёт за собой ещё и проверку правильности написания unit-тестов. Но нужно же подходить к работе преподавателя программирования со всей ответственностью и с правильным закладыванием фундамента, который требуется отрасли.

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

Старинин Андрей — Wed, 14 Sep 2022 14:45:38 +0000

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

В своей преподавательской практике использую 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