Привет! Меня зовут Рома и это моя первая статья на Хабр. Я так давно хочу написать сюда, что в поисках наиболее подходящей темы успел разочароваться в ИТ, окончить бакалавриат физического факультета, вновь проникнуться программированием и закончить магистратуру по системной и программной инженерии. Путь был долгий, тернистый, но, в конце концов, я нашел отличных друзей и единомышленников и заработал бесценный опыт. И вот, пройдя его, я готов написать, как я на практике попытался максимально применить полученные мной знания и контакты.
Думаю, у каждого, кто учился в универе последний десяток лет и умел программировать, чесались руки написать самое удобное, безоговорочно прекрасное, лучшее приложение с расписанием для себя и своих однокурсников. За время моего обучения в бакалавриате у нас было таких аж 3 или 4. Каждые год-два находится студент, который пишет свою реализацию, она живет годик, а потом про нее все забывают. Нет, приложения не были плохими, не были багованными, не были неудобными. Просто расписание в этих приложениях некому было обновлять. Студент выпускался и вместе с ним уходило и приложение. Так появилось первое нефункциональное требование к приложению: его должно быть интересно поддерживать нынешним студентам факультета и будущим поколениям.
Найти людей, кто будет заниматься разработкой здесь и сейчас, не составило труда: около года назад мы с друзьями организовали "клуб программистов" факультета, в котором большинство участников – нынешние студенты. Найти людей, которые будут менеджерить и заниматься развитием приложения тоже оказалось не сложно – во время учебы я много времени проводил в профкоме студентов, на них и было решено ориентироваться, они были очень заинтересованы. Посоветовавшись и с теми и с другими появился список требований к приложению (извините, я без IEEE SRS Template, как учили, пет проект все-таки):
Требования
Нефункциональные требования
-
Приложение должно поддерживаться и развиваться силами действующих студентов физфака
Приложение должно иметь низкий порог входа для новых разработчиков
Приложение должно строиться на стандартных, понятных и популярных технологиях
Приложение должно быть устойчиво к ошибкам. Неверный коммит не должен положить целиком все приложение
Приложение должно быть дешевым в обслуживании. $100 в год за аккаунт разработчик Apple уже неприятная сумма
Приложение должно быть довольно легковесным на серверные ресурсы, т.к. сервера оплачиваются тоже студентами
Функциональные требования
-
Возможность просмотра расписания
В расписание нужно иметь возможность встраивать внеучебные мероприятия, которые устраивает профком и другие студенческие организации
В приложении должны найти развитие сервисы, которые я писал во времена своего студенчества. Например, приложение печати на бесплатном принтере профкома
В приложение должны однажды переехать умирающие без постоянного надзора сервис оценки преподавателей и вики с шпорами
Нужно сделать меню с важными для профкома, динамически изменяющимися в зависимости от обстоятельств кнопками
Мы должны уметь измерять полезность приложения: сколько человек им пользуются,
Сформулировав основные требования приступили к дизайну UI. По описанию вырисовывался эдакий ненавистный всеми суперапп: приложение с кучей мало связанных кнопок и сервисов. При входе видишь основной функционал: календарь-расписание на сегодня, а дальше проваливаешься в меню с ссылками на веб странички.
Архитектура
А дальше наступила самая сложная часть. Надо было выбрать, на каких технологиях писать приложение, чтобы удовлетворить всем требованиям. От отдельных приложений на Android и iOS отказались почти сразу: это хоть и самый понятный, но очень затратный в плане сил, времени и денег подход. Решили делать web-приложение, нынешние технологии позволяют сделать их почти неотличимыми от нативных, а при желании всегда можно упаковать в бинарь под интересующую ОС. С помощью Service Workers и HTML5 API можно организовать работу без интернета, а технология PWA позволит устанавливать приложения на рабочие столы Android и iOS в обход магазинов приложений. А на сдачу, приложение еще и с компьютеров будет доступно.
Так как сервисы в приложении все равно будут мало связанными друг с другом, то стал реализовывать микросервисную архитектуру. Она чуть сложнее в поддержке, но проще в плане привлечения новых участников в команду: новый сервис можно пилить с нуля на новых технологиях, код проще и лаконичнее, проще искать ошибки.
Чаще всего, говоря про микросервисы в веб приложениях имеют в виду бэкэнд, а фронтэнд все равно делают монолитным. Здесь я сделал довольно опасный шаг и на фронте тоже навязал микросервисы с использованием single-spa. Пока это решение принято с теплом, но использование сложного и не очень популярного фраемворка без документации на русском языке может сказаться на удобстве поддержки проекта в будущем.
Несмотря на возможность писать сервисы почти на чем угодно, пока принудительно заставил ребят с факультета писать бэкэнд на питоне с использованием FastAPI и SQLAlchemy, а фронтовые микросервисы на Vue.js. В первую очередь потому, что технологии популярные и очень простые, а во вторую потому, что я просто с ними хорошо знаком и был готов помочь начинающим разработчикам для которых это приложение – самое большое задание по разработке в жизни.
Старались придерживаться не только популярных фраемворков, но и популярных подходов. Бэкэнды, например, писали с оглядкой на старый добрый REST.
Разработка
Начав незадолго до 1 сентября мы с командой запилили MVP:
Написали 2 полноценных микросервиса-бэкэнда (API расписания и API для мониторинга действий пользователей) и еще 3 API ручки с захардкоженными JSON ответами (для меню и списка сервисов)
Создали 1 приложение single-spa и 3 микрофронтэнда к нему (расписание, навигация, страница с списком сервисов)
Заполнили все это распаршенными данными с сайта факультета
Арендовали 1 виртуальный сервер и раскатали на нем все базу данных, веб сервер с reverse proxy и все наши микросервисы в докер контейнерах в двух экземплярах: продакшн и тест
А еще успели для удобства разработки:
Настроить процессы CI/CD для автоматической сборки и деплоя контейнеров на VDS
Написать на весь код и на типовый процесс разработки ✨документацию✨ (ну почти написали, еще не все готово)
Составить дорожную карту ближайших доработок
Не все успели вовремя, выкатились не первого сентября, как планировали, а только спустя неделю. Первая версия получила множество конструктивных отзывов, которые приоритетно вошли в список задач. Ребята дочинивают баги на фронте и готовятся выпустить новую версию, после чего должна начаться активная рекламная компания.
Вам, хаброжители, к сожалению, оставить ссылку посмотреть не могу. Cервер у нас маленький и хаброэффекта точно не выдержит. Кстати, если хотите поддержать проект сервером помощнее – напишите нам, пообщаемся о сотрудничестве!
Заключение
Мы проделали большую работу над приложением, еще большую предстоит провести ребятам для поддержки и развития приложения в ближайшем будущем. Будем ждать от них новых релизов и собственных публикаций на Хабр.
С большим удовольствием отвечу на ваши вопросы и почитаю в комментариях, как можно было иначе организовать архитектуру проекта. Любая обратная связь будет очень полезна!
Комментарии (17)
Exchan-ge
08.10.2022 22:13Приложение должно строиться на стандартных, понятных и популярных технологиях
От отдельных приложений на Android и iOS отказались почти сразу: это хоть и самый понятный, но очень затратный в плане сил, времени и денег подход.
Хотите сделать полезное и долгоживущее приложение — сделайте простой импорт из популярного планировщика (для меня это Календарь от МС)
С заполнением планировщика справится любой учебный отдел. Более того, они таки научатся использовать планировщик для составления и изменения расписания :)
Ну а если хотите сделать что-то реально полезное для всех — сделайте нормальный аналог Moodle (вместо одноименного монстра :)
Вам скажут спасибо буквально миллионы.
djakov Автор
08.10.2022 23:29+1Боюсь что там все несколько сложнее. Есть ПО для составления расписаний, которое учитывает занятость преподавателей и составляет расписание почти автоматически, для обычный календарей очень сложная фича
А про LMS есть идеи, но мы не уверены, что у учебного отдела будет желание работать с приложением, поддерживаемым студентами
Exchan-ge
08.10.2022 23:35+1Есть ПО для составления расписаний, которое учитывает занятость преподавателей и составляет расписание почти автоматически
Берем готовое расписание и загоняем его в планировщик.
Потом импорт в приложение.
В любом случае это лучше, чем вывешивание расписания на доске в бумажном виде и последующее его фотографирование студентами (преподавателям их расписание обычно комбинируют лаборанты, после чего преподаватели таки самостоятельно загоняют его в планировщик. Куча лишней работы :)
Exchan-ge
08.10.2022 23:36+2но мы не уверены, что у учебного отдела будет желание работать с приложением, поддерживаемым студентами
Если это не прибавит работы учебному отделу, а наоборот — ее сократит, то возражать они не будут :)
Gryphon88
10.10.2022 14:41Как человек, который занимался составлением расписаний, такая стройная картина не очень работает, особенно для мультидисциплинарных курсов или случаев, когда надо синхронизировать дисциплины. Учебный отдел не столько расписания составляет, сколько выпасает котов: не дает преподавателям забыть или потеряться, не дает завкафам или деканам переправить уже составленный, а то и подписанный учебный план и программу. Вот воркфлоу, когда оперативно собираешь запросы и информируешь все стороны. За месяц: хороший учебный план, я не могу по пятницам и в будни между 14 и 17 часов. За 3 недели: да, все хорошо. За две недели: ой, теперь я еще и по средам не могу и в понедельник с 9 до 12. За неделю: что вы понасоставляли?! За день: ой, я не успеваю. В итоге ты в лучшем случае утром того же дня матерясь идешь вешать на доску объявлений листочек «лекция в понедельник в 12.30 переносится на вторник, 17.30».
Exchan-ge
10.10.2022 14:57«лекция в понедельник в 12.30 переносится на вторник, 17.30».
Гм… а мы-то думали, что наш учебный отдел работает не очень четко :)
У нас такого бар… беспорядка нет — накладки случаются, но их исправляют оперативно в первые же дни действия нового расписания.
(проблема у нас в том, что УО рассылает свои файлы в формате PDF/только изображение, так что приходится обратно преобразовывать их работу в электронную форму, что всех бесконечно радует)
furior
09.10.2022 15:20У меня на сайте вуза есть ссылка на импорт в гугл календарь, вполне нормально синхронизируется( с мобильного приложения правда обновляется криво, в браузере все идеально)
Exchan-ge
09.10.2022 15:26есть ссылка на импорт в гугл календарь
По моим личным наблюдениям, айфонов у студентов тоже много :)
(на мой взгляд, таки лучше использовать импорт в мобильное приложение Outlook — там есть Календарь, а среди ПК по прежнему доминируют компьютеры с Windows. Установить это приложение и научить им пользоваться — дело пяти минут, причем участие преподавателя особо не требуется — достаточно показать одному, по цепочке узнают все :)
Винда и Аутлук более универсальны.
shark14
09.10.2022 07:41Для чего в ваших API для обновления групп, кабинетов и событий есть методы PATCH, если нет методов PUT?
Напомню, что метод PATCH обновляет только те поля, что пришли в объекте, а PUT целиком перезатирает объект тем, что пришло с клиента.Обычно добавляют именно PUT, а PATCH — уже дополнительно к нему для оптимизации запросов.
Если оставлять как сейчас, то ваше API в принципе не позволяет удалить какое-то поле из объекта, не удаляя объект целиком и не создавая его заново с перегенерацией id, лишними запросами и прочими нежелательными спецэффектами.
djakov Автор
09.10.2022 10:27В патче все поля, которые могут быть без значений, nullablе, поэтому можно затереть нужные поля просто передав Null в нужном месте. А передав значения всех полей можно получить ту же функциональность, что и PUT. Показалось что ручка PATCH имеет тот же функционал, что и PUT, но более гибкая
borovinskiy
Вангую, что следующим поколениям студентов будет влом разбираться в написанном и они с нуля будут пилить свое.
djakov Автор
Я надеюсь на ребят-студентов, которые продолжают сейчас развивать приложение, что они передадут его следующим поколениям. Мой прошлый большой проект, не связанный с прогой, уже 2 с небольшим года живет на факультете без меня и хорошо себя чувствует, надо закреплять опыт
avdosev
абсолютно согласен, обычно такие решения потом медленно или быстро, но умирают. Без поддержки вуза (финансовой и административной) таким приложениям уготована только одна дорога — на кладбище пет проектов.
DuangellowX
Не скажите. Такие приложения могут держаться полностью и на студенческой поддержке. Если вопрос финансовый, то никто не отменяет возможности краудфандинга (да, некоторые студенты (даже с учётом мизерного, при наличии, заработка) готовы подкинуть разработчикам монету на ресурсы), по поводу административного - тут тоже решают студенты. Руководство не может жёстко регламентировать чем может, а чем не может пользоваться студент (условно, для просмотра расписания). Единственное как университет может попортить малину - усложнить возможности для парсинга, однако, как показывает личная практика, этим заниматься либо нет ресурса, либо наоборот, IT-отдел университета улучшает свой сервис расписания.
avdosev
С тем, что эти приложения могут держаться полностью на студенческой поддержке, я не сомневаюсь, но обычно запал быстро пропадает, особенно когда в университете очень скудный IT-отдел или которого в принципе нет. Лично у меня есть пример с моим университетом: расписание студентам дается через xlsx файл, огромной таблицей на несколько групп и потоков, таких таблиц не мало и их формат различается в зависимости от факультета — полная неразбериха форматов и автоматизированно парсить их мега сложно.
Но. У меня есть и контр пример: когда я поступил в магистратуру другого вуза, то приложение с расписанием (функционал этим неограничен) вышло из под крыла вуза (с административной и финансовой поддержкой), и оно мега функционально, настолько насколько это впринципе позволяет it-инфраструктура вуза. Хотите электронную зачетку? Пожалуйста.
И знаете, это гораздо приятнее и удобнее. Вот я как первокурсник, первый раз прихожу в вуз не знаю ни про расписание, ничего, а мне на официальном вузовском мероприятии говорят: "Вот приложение, мы сделали, пользуйся". И это кайф, гораздо лучше, чем когда тебе старшекурсник рассказывает по секрету, что есть вот такое неофицальное приложение.
DuangellowX
Неоспоримо, так конечно намного лучше, однако не у каждого университета имеется возможность развивать так свой IT-отдел и не у каждого IT-отдела возникает желание развивать свои сервисы для студентов. Мотивация делать и развивать своё как раз возникает отсюда: хочется сделать для себя, попрактиковаться в программировании, попробовать свои силы.
Одно дело, когда есть что-то "в чём в лом разбираться", а другое - отсутствие в принципе чего-либо.
Согласен, что когда всё это берёт на себя ВУЗ - становится намного проще.
anthtml
На программистких факультетах, чуть ли не через курс возкают темы курсачей/дипломов "сайт вуза/приложение/АСУ "Расписание занятий"", но выход за пределы петпроектов, особенно без административно-финансовой поддержки вуза - изначально утопия. И здесь, как правильно сказано, пока кафедра/профком/ректорат не признает приложение официальным (не возьмет под крыло), оно так и не разовьется исключительно на энтузиазме. Тут даже со свободным ПО трудно сравнивать, тк. там есть более-менее постоянный ментор, а здесь раз в 2-3 года полностью меняется вся команда