Совместное проектное обучение студентов ИТ-направлений подготовки на основе разделения задач в проекте и применения средств контроля версий

Полный текст

Постановка проблемы. Большая потребность в специалистах, которые призваны обеспечить цифровизацию экономики, вызывает необходимость в новых формах, методах и средствах их подготовки, сближающих учебную и профессиональную деятельность и позволяющих сформировать их профессиональную компетентность на момент окончания вуза [1-3]. В современных условиях, диктующих необходимость цифровизации образования, некоторые преподаватели и вузы уже начинают использовать средства профессиональной ИТ-среды, такие как системы контроля версий, в рамках реализации учебного процесса [4; 5]. Особенную актуальность средства командной разработки получают при реализации совместных проектов при дистанционном обучении, как и при удаленной работе, востребованность которых существенно возросла в последние годы [6-9]. Применение методов снижения связности кода, шаблонов проектирования, направленных на модульность программных проектов и систем контроля версий в рамках дисциплин компьютерного цикла, позволяет сместить акценты в процессе обучения с чисто учебных действий на решение профессиональных задач средствами, применяемыми в профессиональных сообществах, в командах разработчиков программного продукта [1; 2]. Цель исследования - изучить вопросы применения средств контроля версий в полноценном контексте их использования в подготовке ИТ-специалистов при работе над совместным проектом, что позволит обеспечить наиболее эффективный способ получения востребованных компетенций реализации коллективной разработки ПО [1; 10]. Методология. Обучение вопросам коллегиальной разработки проектов можно провести в рамках одного или нескольких занятий, желательно совмещенных в относительно небольшом временном периоде. В рамках подобного «хакатона» преподаватель выступает в роли ведущего программиста, который формирует архитектуру проекта и рассказывает о ней студентам. Пишет (а лучше показывает заранее написанные) основные части приложения, выделяет области приложения, реализацию которых можно легко делегировать, и располагает там интерфейсы для подключения будущих реализаций. После этого студентам предлагается произвести совместную доработку проекта, реализовав эти интерфейсы (под интерфейсом здесь и далее подразумевается чисто абстрактный класс, указывающий какие методы и свойства должны иметь его наследники). В качестве проекта для совместной реализации может быть выбрано любое приложение, имеющее несколько сходных элементов с несколько отличающейся логикой. Например, хорошо подойдет игра «Шахматы», где такими элементами могут быть фигуры. В этом случае преподаватель демонстрирует, как устроена общая часть игры, а реализация логики и представления отдельных фигур предлагается студентам для индивидуального или группового исполнения, в зависимости от количества участников. Реализация отдельной фигуры является здесь достаточно понятной и компактной задачей. Код проекта предоставляется в Git-репозитории, например в GitHub или Bitbucket [11]. Подключение к проекту предполагается с помощью любого Git-клиента, например Sourcetree. Первая версия проекта, реализованного в рамках занятий, проведенных по описываемой методике, представлена в открытом репозитории Bitbucket[11]. Структура проекта реализуется на основе MVC шаблона проектирования. Выделяются такие классы модели, как Игрок, Доска, Матч, Ход, Фигура. При этом Фигура реализуется в виде абстрактного класса или интерфейса, от которого студенты будут наследовать конкретные фигуры, определяющие разрешение на ход. Модель можно реализовать в отдельном проекте, подключив его к Unity в виде библиотеки классов (например, указав путь выхода сборки в папку проекта Unity: Assets/Dll). Это продемонстрирует разделение проекта на модули и обеспечит низкую связность кода модели и представления. А в случае реализации серверной части для сетевой игры, позволит подключить эту же библиотеку в серверный проект (например, на Asp.Net или Photon Server). С другой стороны, для облегчения работы по синхронизации этот шаг можно опустить. Рис. 1. Заготовка проекта - отдельные фигуры постепенно реализуются и добавляются студентами в общий проект с помощью Git Figure 1. Project preparation - individual figures are gradually implemented and added by students to the overall project using Git В качестве представления будут выступать префабы. Префаб - особый тип ассетов, позволяющий хранить GameObject со всеми компонентами и значениями свойств. Префаб выступает в роли шаблона для создания экземпляров хранимого объекта в сцене. Любые изменения в префабе немедленно отражаются и на всех его экземплярах, при этом можно переопределять компоненты и настройки для каждого экземпляра в отдельности[12]. По аналогии с моделью потребуются такие префабы, как Доска и Фигура. Префабы Фигур будут реализовываться отельными участниками проекта либо из имеющихся примитивов Unity (куб, цилиндр, сфера), либо на основе импортируемых моделей, подготовленных в средствах 3D-моделирования (рис. 1). Префабы Игрок, Матч, Ход тоже могут быть реализованы, например, как части интерфейса игры. Контроллерами в нашем случае будут скрипты Unity-проекта, обеспечивающие связку между классами модели и префабами. Реализуются как наследники MonoBehaviour, содержащие в себе ссылки на классы модели и подключаемые к соответствующим префабам. Основная задача контроллеров - обеспечить связку между представлением (префабами) и логикой. Можно отметить, что нам будет достаточно одного контроллера для всех имеющихся видов фигур, благодаря полиморфизму в реализации шаблона проектирования «Стратегия» (рис. 2). Изображение выглядит как диаграмма Автоматически созданное описание Рис. 2. Часть диаграммы классов проекта, иллюстрирующая взаимодействие модели и контроллера фигур Figure 2. Part of the class diagram of the project illustrating the interaction between the model and the shape controller Минимальная версия проекта реализуется с мультиплеером в формате попеременного хода участников, находящихся за одним устройством. В зависимости от времени, отводимого на данную тему, можно расширить проект дополнительными возможностями (рис. 3), такими как: 1. Реализация ИИ - можно, например, сделать набор ботов, предложив каждому из участников написать своего. При этом боты будут наследоваться от общего интерфейса, описывающего управление матчем. 2. Сетевое взаимодействие: а) регистрация аккаунта; б) матчмейкинг - запуск матчей; в) синхронизация ходов; г) построение рейтинга. 3. Монетизация приложений: а) внутриигровые покупки, например: скины фигур, дополнительные режимы игры (12×12 ячеек и т. п.) - можно разделить реализацию отдельных покупок между участниками; б) реклама: от Unity, с подключением агрегаторов - можно разделить подключение отдельных рекламных SDK к агрегатору между участниками. 4. Сборка и размещение в магазинах приложений. Рис. 3. Заготовка главного меню, предоставляющего доступ к различным функциям приложения Figure 3. Draft main menu providing access to various functions of the application Для улучшения контроля за выполнением проекта множеством студентов можно воспользоваться, например, google-таблицей, c отметками по шагам реализации проекта и имеющимися вопросами (рис. 4). При этом имеет смысл сделать таблицу доступной для редактирования всем участникам. Кроме того, общий Git-репозиторий позволяет удобно просматривать и оценивать внесенные каждым студентом изменения и осуществлять взаимодействие по возникающим вопросам, что особенно полезно при дистанционном формате обучения. Рис. 4. Google-таблица с прогрессом участников проекта Figure 4. Google-table with the progress of the project participants Результаты и обсуждение. Первоначальный уровень мотивации студентов легко создать, рассказав им о востребованности методов и технологий коллективной работы с кодом. Тем не менее существует риск затягивания проекта, который может привести к потере мотивации и вовлеченности студентов в процесс разработки, в результате чего часть студентов не пройдут своевременно весь путь, а это, в свою очередь может помешать собрать итоговый проект и продемонстрировать плодотворность коллективной работы. Во избежание этого целесообразно заранее проверить основные требования при подготовке к подобного рода занятиям. Во-первых, у студентов должны быть базовые знания в области программирования на выбранном языке. Во-вторых, программное и техническое обеспечение учебной аудитории должно поддерживать весь цикл разработки и синхронизации проекта: необходимы средства разработки одной версии на машинах преподавателя и студентов, Git-клиент, стабильный доступ в сеть, аккаунт в Git-репозитории. Можно, конечно, включить установку ПО в список задач, особенно если часть студентов использует свои ноутбуки. Например, Git-клиент установить можно, но процесс установки сред разработки легко может затянуться, а в случае с разными версиями и усложнить синхронизацию проекта. Если брать в качестве примера именно шахматы, фигур может оказаться меньше, чем студентов. В этом случае можно либо объединить студентов в группы, применив, например, подход экстремального программирования [12], либо расширить список фигур дополнительными, например из «Омега-шахмат»[13]. Основные сложности, возникшие при выполнении проекта Проблема Причина Возможное решение Долгая установка средств разработки Реализация проекта на собственных ноутбуках Предварительная задача на установку ПО (не помогло в 60 % случаев). Работа на аудиторном оборудовании с предустановленным ПО Сложности реализации серверного API Небольшие отличия реализации API в разных версиях фреймворка. Сложность быстрого освоения особенностей клиент-серверного взаимодействия Применение знакомых сред разработки серверной части проекта. Предварительное изучение реализации API. Реализация проекта без серверной части Проблемы подключения библиотек Реализация общей логики клиента и сервера в отдельной библиотеке. Библиотеки, подключаемые к Unity иногда вызывают проблемы при синхронизации через Git, особенно при разных версиях среды разработки Не отделять логику в отдельную библиотеку, что понизит сложность реализации, восприятия и синхронизации через Git, но потребует дублирование кода Сложность восприятия материала Недостаточно структурированная и последовательная подача материала Предварительная реализация проекта преподавателем для устранения подводных камней и сокращения процесса демонстрации разработки за счет использования готовых частей кода Потеря общего контекста проекта Разделение реализации проекта на несколько занятий, ввиду чего проект становится тяжело воспринимаемым, особенно при наличии пропусков части занятий Рассмотрение проекта в заранее подготовленном виде в рамках одного занятия. Краткий пересказ ранее рассмотренного материала, в случае разделения на несколько пар. Поэтапная реализация - сначала в минимальной готовой версии, потом дополнение (библиотеки, API и др.) The main difficulties encountered in the implementation of the project Problem Reason Possible solution Long installation of development tools Implementation of the project on your own laptops A preliminary task for installing software (did not help in 60% of cases). Work on classroom equipment with pre-installed software Difficulties in implementing the server API Small differences in the implementation of the API in different versions of the framework. The difficulty of quickly mastering the features of client-server interaction The use of familiar development environments of the server part of the project. Preliminary study of the API implementation. Implementation of the project without the server part Problems of connecting libraries Implementation of common client and server logic in a separate library. Libraries connected to Unity sometimes cause problems when syncing via Git, especially with different versions of the development environment Do not separate the logic into a separate library, which will reduce the complexity of implementation, perception and synchronization via Git, but will require code duplication The complexity of the perception of the material Insufficiently structured and consistent presentation of the material Preliminary implementation of the project by the teacher to eliminate pitfalls and reduce the development demonstration process by using ready-made parts of the code. Consideration of the project in a pre-prepared form within the framework of one lesson Loss of the overall project context The division of the project implementation into several classes, which makes the project difficult to perceive, especially if there are absences of part of the classes A brief retelling of the previously considered material, in case of separation into several pairs. Step-by-step implementation - first in a minimal ready-made version, then an addition (libraries, APIs, etc.) Апробация предложенной методики проведена в группе студентов 3-го курса Ухтинского государственного технического университета в рамках нескольких занятий дисциплины «Мобильные разработки». По итогам первой апробации с поставленной задачей успешно справились 6 из 10 принявших участие студентов. При выполнении проекта выявлен ряд сложностей (таблица), которые можно предупредить предварительной подготовкой и поэтапной выдачей задачи. Через полгода после реализации проекта был проведен краткий опрос студентов о полезности проделанной работы, по итогам которого активные члены группы оценили полученный опыт на 8,5 из 10. Заключение. Предложенный формат проведения занятий по программированию может быть полезен тем, что совокупно дает ряд компетенций, широко востребованных в современном мире разработки программного обеспечения, таких как: 1) совместная разработка; 2) разделение проекта на модули; 3) работа в системах контроля версий; 4) применение шаблонов проектирования.

Об авторах

Константин Васильевич Рочев

Ухтинский государственный технический университет

Автор, ответственный за переписку.
Email: k@rochev.ru
ORCID iD: 0000-0002-2720-3209

кандидат экономических наук, доцент кафедры вычислительной техники, информационных систем и технологий, факультет экономики, управления и информационных технологий

Российская Федерация, 169300, Ухта, ул. Первомайская, д. 13

Анастасия Викторовна Семяшкина

Ухтинский государственный технический университет

Email: asemyashkina@ugtu.net
ORCID iD: 0000-0002-6781-0396

старший преподаватель, кафедра вычислительной техники, информационных систем и технологий, факультет экономики, управления и информационных технологий

Российская Федерация, 169300, Ухта, ул. Первомайская, д. 13

Список литературы