Организация рабочего процесса разработки системы проверки домашних заданий (OSSDEVCONF-2023)

Ссылки сюда (1) →

Короткая ссылка: 20230929C

Докладчик

• Вениамин Арефьев
• Никита Барабанов

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

Разбираются особенности организации рабочего процесса в условиях сжатых временных рамок и ограниченных человеческих ресурсов, а также проблемы, с которыми можно встретиться в процессе разработки и варианты их решения.

Видео

on youtube

Thesis

• https://github.com/FrBrGeorge/HWorker

Постановка задачи

Основным назначением системы является сопровождение учебных курсов «Язык программирования Python», «Совместная разработка на Python» и «Практические аспекты сетевых протоколов в Linux», которые читаются на кафедре АСВК факультета ВМК МГУ, а также любых других курсов со схожей структурой. А именно: сдача заданий по электронной почте или путём выкладывания в открытых репозиториях, оформление тестов в виде «входные данные -- эталонный вывод».

Рабочий процесс и его особенности

Ограничения

Данный проект имел строгие временные рамки, начать его можно было не раньше 1 июля, а закончиться он мог не позже 31 августа. То есть на всё планирование, разработку и тестирование отводилось не больше двух месяцев.

Precious source

Разработка велась в одном главном публичном репозитории, в который принимались только (почти) пулл--реквесты. Ревью не проводилось ввиду крайне малого размера команды, процесс «вливания» изменений увеличился бы в кратном размере.

Обсуждение архитектуры

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

Пятиминутки

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

Wiki

Основная информация о проекте, причём эта вики не является обычным генератом от того же sphinx. В вики проекта были описаны формальные и неформальные требования к каждому модулю системы и их подмодулям, а также различные предложения по тому, как могут быть реализованы данные модули предлагались на соответствующих страницах.

API

Для создания межмодульного взаимодействия были выделены специальные публичные функции, которые могут вызывать конечные пользователи модуля. Поэтому эти функции были выделены в отдельную страничку API на вики проекта. На этой страничке описаны все публичные функции всех модулей, которыми могут пользоваться другие модули. Также во время разработки эта страница использовалась для создания запросов на написание таких функций.

Стиль программирования и документирование

Все публичные функции, описанные в API должны иметь полное документирование, то есть иметь описание и типизацию всех аргументов и возвращаемого значения. При создании Pull request'a в Precious source весь исходный текст должен быть обработан с помощью форматтера black. Данные требования были введены исключительно в интересах упрощения взаимодействия между разработчиками, то есть унификации результатов их работы, которое способствовало пониманию кода друг друга.

Тесты и CI

В самом начале разработки было принято решение о том, что весь написанный публичный функционал модулей стоит покрывать тестами c помощью pytest, если это представляется возможным сделать за разумные сроки (меньше чем писался сам модуль). В последние две недели разработки было выяснено, что проект работает по--разному на разных операционным системах, поэтому был внедрён Github Continuous Integration, который при каждом измерении репозитория запускает тесты, позволяя убедиться в том, что функционал работает корректно.

Результаты

По итогу совместной работы система успешно функционирует на корпусе решений прошлогодних курсов, и далее планируется введение в полную эксплуатацию и соответствующее сопровождение проекта. На данный момент HWorker умеет:

• Скачивать выполненные студентами домашние задания.
• Разбивать их на решения, тесты и ссылки на тесты других студентов (с возможностью для преподавателя указывать свои тесты отдельно).
• Запускать ассоциированные тесты.
• Оценивать результаты при помощи функций, написанных преподавателем.
• Публиковать эти результаты в удобном для восприятия виде.

Анализ эффективности

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

Благодаря тому, что на формирование и обсуждение архитектуры было выделено достаточно времени, получилось придумать и реализовать модули системы сравнительно независимо. Это очень помогло исправить серьёзный «костыль» в логике работы с домашними заданиями в последние дни работы над проектом, не приводя к накоплению технического долга.

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

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