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

;{{SpeakerInfo}}:
* {{Speaker|Олег Ивченко}}
* {{Speaker|Иван Пономарёв}}
<blockquote>
Традиционными заданиями для самостоятельной работы при обучении программированию является решение стандартных задач или
разработка студенческих проектов. Хотя данный подход обеспечивает тренировку студентов на достаточно лёгких задачах и
объективную оценку результатов работы, сам процесс и результаты самостоятельной работы очень сильно отличаются от того,
с чем встречается разработчик на практике. Мы на нашей кафедре уже несколько лет экспериментируем со студенческими
проектами, результатом которых является коммит в свободное ПО, принятый мантейнерами. 

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

{{VideoSection}}
{{vimeoembed|920251728|800|450}}
{{youtubelink|}}

{{SlidesSection}}
[[File:Опыт контрибьютинга в свободное ПО как практической работы студентов в процессе обучения разработке (OSEDUCONF-2022).pdf|left|page=-|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. [https://github.com/atp-mipt/ljv]. Объём 1.5 KLOC. Является оживлением заброшенного проекта LJV для визуализации внутренних структур данных. Проект набрал с нуля 200+ звёзд на гитхабе, публикации и выступления по LJV были довольно успешны.
;Jedis-mock: тестовый мок Redis на Java. [https://github.com/fppt/jedis-mock]. Объём 8KLOC. Jedis-mock является частичной реимплементацией Redis на Java для нужд тестирования. Проект обладает небольшой пользовательской  базой. Успешно проведён массированный рефакторинг, реализована новая функциональность, закрываются запросы пользователей.
;JSyntrax: визуализация формальных языков в виде railroad-диаграмм в форматах PNG и SVG [https://github.com/atp-mipt/jsyntrax/]. Объём 3KLOC. Является переимплементацией старого заброшенного проекта Syntrax c Python на Java. Проект поддержан в AsciiDoctor.
;Xylophone: [https://github.com/CourseOrchestra/xylophone]. Объём 3KLOC. Решает задачу создания отформатированных Excel-документов на основе данных, представленных в XML. Библиотека нужна для многих организаций, генерирующих печатные формы, отчёты и тому подобное. Проект старый, имеет пользовательскую базу.

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


{{----}}
[[File:{{#setmainimage:Опыт контрибьютинга в свободное ПО как практической работы студентов в процессе обучения разработке (OSEDUCONF-2022)!.jpg}}|center|640px]]
{{LinksSection}}
<!-- <blockquote>[©]</blockquote> -->

<references/>

[[Категория:OSEDUCONF-2022]]
[[Категория:Draft]]