Edu

Продолжу выкладывание примеров использования GitHub'а как инструмента обучения.

Предыдущий пример

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Плюсы:

• Более приближенный к реальности вариант моделирования

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

• Каждая команда работает над своим подпроектом

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

Минусы:

• Нужно создавать отдельный аккаунт для организации

• Нужно объяснить как работать с ветками и следить, чтобы пушили в нужную ветку.

• Нужно объяснять что такое релиз, как происходит версионирование.

• Нужно объяснять как пишется и для чего нужна техдокументация.

Какие можно внести дополнения:

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

• создавать не отдельные репозитории для каждого подпроекта, а использовать gitsubmodules

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

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

• Поддержка Markdown-разметки. Можно более "красиво" оформлять задания.

• Система форков. Может любой человек сделать форк, а потом предложить запрос на слияние. Не всегда нужно всех студентов добавлять в команду.

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

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

• Система issues. Можно давать другим командам студентов задание на проверку кода и выявления багов, с занесением всего в issues.

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

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

• Понимание принципов написания кода. Когда начинают чужой код проверять - многое понимают

• Понимание "соглашения об именовании". Пока не наступят на грабли разного именования в одной команде - не понимают. Ну или не все понимают

• Понимание как работать в команде. И как командам между собой взаимодействовать.

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