Опыт контрибьютинга в свободное ПО как практической работы студентов в процессе обучения разработке (OSEDUCONF-2022)

Короткая ссылка: 20220520Q

Докладчик

Традиционными заданиями для самостоятельной работы при обучении программированию является решение стандартных задач или разработка студенческих проектов. Хотя данный подход обеспечивает тренировку студентов на достаточно лёгких задачах и объективную оценку результатов работы, сам процесс и результаты самостоятельной работы очень сильно отличаются от того, с чем встречается разработчик на практике. Мы на нашей кафедре уже несколько лет экспериментируем со студенческими проектами, результатом которых является коммит в свободное ПО, принятый мантейнерами.
В докладе мы расскажем, какие преимущества даёт подобный подход по сравнению с решением стандартных задач, с какими трудностями приходится сталкиваться, чем надо руководствоваться при выборе подходящего проекта свободного ПО, и кратко расскажем о нескольких примерах проектов: LJV/JOL, Jedis-Mock, JSyntrax, Xylophone

Содержание

1 Видео
2 Презентация
3 Thesis
- 3.1 Перечень проектов
- 3.2 Выводы
4 Примечания и ссылки

Видео

Презентация

300px

Thesis

https://github.com/atp-mipt

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

Совместная работа многих разработчиков с использованием GitHub и подобных систем.
Процесс разработки: issues, pull requests, code review.
Технологический аспект: CI-системы, quality gates, ситуации, когда изменения не принимаются статическим анализатором.
Работа с существующим кодом, не идеальность существующего кода, необходимость рефакторинга перед внесением изменений.
Необходимость писать автотесты (культуре и навыкам написания автотестов практически не уделяется внимание при обучении разработчиков).

Закрыть эти пробелы можно с помощью практики разработки на реальных Open Source проектах. На протяжении трёх лет на кафедре АТП МФТИ мы проводим эксперимент, при котором студентам, обучающимся технологиям разработки на Java, имеющим базовые знания и желающим получить более сложное задание, предоставляется возможность в течение семестра работать над каким-либо из проектов с открытым исходным кодом в виде альтернативы к стандартному домашнему заданию.

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

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

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

Небольшой объём: один инженер (преподаватель) должен быть в состоянии «охватить» все его аспекты. Объём наших проектов не превышал 10 KLOC.
Наличие базы пользователей: это источник сообщений об ошибках и желаемых функциональных возможностях
Отсутствие процедур обсуждения изменений: длинные сроки обсуждений и согласований, как правило, делают невозможным произвести учебный цикл в течение семестра.
Преподаватель должен входить в число мантейнеров проекта и должен иметь право интегрировать изменения в основную ветку. (Это происходит после code review изменений от студентов и также зачастую после дополнительных изменений кода, сделанных самим преподавателем.) Хорошо, если преподаватель также имеет возможность принимать решение о релизе новых версий проекта: быстрое попадание изменений в релиз является фактором, мотивирующим студентов.

Помимо выбора проекта, важен выбор задач к реализации на проекте. Успешность реализации задачи является основанием для оценки работы студента, но должна существовать возможность объективно оценить успешность. По нашему опыту хорошо подходят следующие задачи:

Исправление ошибок из числа открытых тикетов: Обязательным требованием является написание автотестов, воспроизводящих ошибки.
Рефакторинг при наличии тестов: Обсуждается желаемая архитектура, после чего студент производит улучшение кода, добиваясь «зелёной» сборки на CI. Иногда для таких задач требуется написание дополнительных тестов преподавателем.
Переимплементация известной функциональности: Наиболее успешными оказались проекты, в которых стояла задача переимплементации, существующей на другом языке / фреймворке. В этом случае легко сверять результат с «эталоном» и создавать тесты.

Неудачными являются задачи, для которых нет абсолютно точно сформулированных требований. Студент не готов к тому, чтобы выполнять задачи, включающие в себя дизайн решений. Отсутствие точных требований означает также и отсутствие критериев успешности выполнения, что затрудняет оценивание студента.
Опасными' являются задачи, для которых нет понятного способа решения, и, как следствие, требующие исследований со стороны студента. Исследования могут завершиться успехом, но в случае отрицательного результата часто невозможно определить причину: виной недостаточная работа студента или объективное отсутствие решения.

Как правило, в течение семестра студенты получают задачи разного типа: как простые, так и «исследовательские».

Перечень проектов

LJV: Lightweight Java Visualizer. [1]. Объём 1.5 KLOC. Является оживлением заброшенного проекта LJV для визуализации внутренних структур данных. Проект набрал с нуля 200+ звёзд на гитхабе, публикации и выступления по LJV были довольно успешны.
Jedis-mock: тестовый мок Redis на Java. [2]. Объём 8KLOC. Jedis-mock является частичной реимплементацией Redis на Java для нужд тестирования. Проект обладает небольшой пользовательской базой. Успешно проведён массированный рефакторинг, реализована новая функциональность, закрываются запросы пользователей.
JSyntrax: визуализация формальных языков в виде railroad-диаграмм в форматах PNG и SVG [3]. Объём 3KLOC. Является переимплементацией старого заброшенного проекта Syntrax c Python на Java. Проект поддержан в AsciiDoctor.
Xylophone: [4]. Объём 3KLOC. Решает задачу создания отформатированных Excel-документов на основе данных, представленных в XML. Библиотека нужна для многих организаций, генерирующих печатные формы, отчёты и тому подобное. Проект старый, имеет пользовательскую базу.

Выводы

Практика студенческой работы над Open Source проектами в целом показывает очень позитивные результаты. Для того чтобы работа была успешной (студенты ощущали, что делают полезную работу, результаты работы попадали в релизы), проекты и задачи к реализации на проектах должны быть выбраны по ряду признаков, перечисленных в данном докладе.

Примечания и ссылки