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

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


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

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

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

Версия 18:38, 25 февраля 2024

Докладчик

• 
  Олег Ивченко
• 
  Иван Пономарёв

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

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

Видео

Презентация

Thesis

• https://github.com/atp-mipt

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

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

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

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

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

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

1. Небольшой объём: один инженер (преподаватель) должен быть в состоянии «охватить» все его аспекты. Объём наших проектов не превышал 10 KLOC.
2. Наличие базы пользователей: это источник сообщений об ошибках и желаемых функциональных возможностях
3. Отсутствие процедур обсуждения изменений: длинные сроки обсуждений и согласований, как правило, делают невозможным произвести учебный цикл в течение семестра.
4. Преподаватель должен входить в число мантейнеров проекта и должен иметь право интегрировать изменения в основную ветку. (Это происходит после 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 проектами в целом показывает очень позитивные результаты. Для того чтобы работа была успешной (студенты ощущали, что делают полезную работу, результаты работы попадали в релизы), проекты и задачи к реализации на проектах должны быть выбраны по ряду признаков, перечисленных в данном докладе.

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