Как стать автором
Обновить

Не повторять, выполнено профессионалами: как не надо разрабатывать таск-трекер

Время на прочтение4 мин
Количество просмотров4.8K

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

Ошибка №1. Начали разрабатывать десктопное приложение на Electron

Electron – фреймворк с открытым исходным кодом для создания десктопных мультиплатформенных приложений с использованием языков JavaScript/HTML/CSS.

В 2018-2019 годах, когда мы начали разработку, экосистема Electron была достаточно маленькой, проект только начал обрастать комьюнити, библиотеками и Best Practice.

Столкнувшись с первыми трудностями сборки проекта в стеке Electron + Vue и победив их, мы думали, что сложнее проблем уже не будет. Но они начались при использовании нативных возможностей ОС.

Так как у нас трекер времени, нам нужно снимать экран, действия пользователя, сайты, на которых он сидит, и используемые приложения. Необходимо было дописывать модуль для трекинга самостоятельно на C++ и прибиндить его к Node.JS модулю.

Гайдов и мануалов по этому ещё не было, мы решили что не будем отказываться от этой функции, так как она была нашим конкурентным преимуществом на рынке и решили переписать все на C++ в связке с Qt. К счастью, удалось найти друга, который взялся за проект и реализовал его за пару месяцев.

Ошибка №2. Выбрали старые технологии

Изначально мы ориентировались на создание серьёзного проекта с интерактивными возможностями и полезными фичами. Выбрали стек технологий без полноценного современного фронтенда.

В прототипе мы использовали jQuery в связке с UI фреймворком Bootstrap 4. Как прототип сервис работал отлично, только показывать это миру было нельзя. Также такая тесная связка фронтенда с бэкендом сильно замедляла разработку продукта – мы тонули в багах и не успевали делать фичи.

Решили, что будем делать полноценный дизайн и искать в команду фронтендера. Жаль, конечно, эти 3 месяца работы над интерфейсом, но решение было принято 🥲

После jQuery и Bootstrap перешли на Vue.js – он нам показался удобным, текущая команда бэкендеров знала Vue, а мы могли спокойно провести собеседование на позицию фронтендера.

Ошибка №3. Не протестировали отчёты на большом объёме данных в PostgreSQL

Таблица логирования времени работы над задачей в таск-трекере строится из даты начала трекинга, даты окончания трекинга, активности пользователя, процесса прогресса и других сервисных полей. Мы не учли отрезки — данные, которые отправляются в систему с интервалом от 30 секунд до 5 минут.

На большом объёме данных агрегационные функции PostgreSQL показали себя достаточно плохо. Мы решили обработать их в Python, но это тоже не дало результата – запросы по-прежнему обрабатывались от 1-30 секунд в зависимости от объёма данных.

Проблему решили переходом на Clickhouse от Яндекса. Принципы построения таблиц отвечали нашему формату – удалось сократить время ответа с 30 секунд до 50 миллисекунд (если честно, я не знаю, как там это работает под капотом, сколько с командой не смотрели конференции и выступления по ClickHouse, ответ так и не получили, но результатом довольны). Визуально отчёт выглядит так:

А это код запроса после перехода (оказался кратно проще, если исчислять в количестве строчек кода):

Ошибка №4. Подходили к дизайну несистемно

Мы прошли 4 итерации дизайна, чтобы прийти к нынешнему внешнему виду сервиса. Сразу желаемого не добились, потому что мы не использовали системный подход. К работе мы привлекали веб-дизайнеров, которые до этого работали только с лендингами, маленькими сайтами и интернет-магазинами: им просто не хватало релевантного опыта.

С опытом мы начали подходить к вопросу дизайна с инженерной точки зрения: теперь у нас меньше итераций. Теперь у нас получается точнее формировать гипотезы, адаптироваться под требования фронтенда — больше времени тратить на аналитику, меньше – на дизайн.

По-прежнему не обходимся без ошибок при разработке новых интерфейсов — часто меняем и переделываем их на этапе проектирования, а при запуске отслеживаем фидбэк и оперативно исправляем недочёты. К фокус-группам и дополнительным исследованиям не обращаемся, A/B тесты не проводим.

Ошибка №5. Плохо настраивали мониторинг и слабо развивали инфраструктуру

С самого начала мы углубились в разработку и не уделили внимания инфраструктуре. Работал всего один сервер для всех сервисов: фронтенда, бэкенда, баз данных. Когда число клиентов выросло, мы столкнулись с проблемой масштабирования и поздно заметили проблемы с нехваткой мощностей сервера.

Раньше мы использовали только одну метрику — доступность сервера. Не проверяли нагрузку на него и оперативную память, поэтому время ответа доходило до 30 секунд (у нас так настроен таймаут). К тому же, 16 Гб оперативной памяти с задачей не справлялись.

Наша инфраструктура стоила приблизительно 500$ на Digital Ocean до февраля этого года, но в ближе к весне мы вынужденно переехали к другому хостеру. Долго присматривались к Selectel, который располагал SaaS-решениями для баз данных и удобного управления серверами, но дорого стоил.

Даже сделали сравнительную таблицу с ценами инфраструктуры Digital Ocean и Selectel при курсе доллара 90 на момент переезда.

Предложений лучше не нашли, решили, что нужно переезжать. Но сделать это качественно за две ночи нам одним было сложно: привлекли part-time dev-ops команду наших друзей. Благодаря им получилось перевезти инфраструктуру в Россию без затруднений.

Кроме того, мы настроили различные дашборды в графане для всех наших сервисов и серверов, а также подключили публичный BetterUptime и алертинг на инциденты. Выдали доступ юзерам для просмотра статуса, если появятся проблемы с Shtab. Теперь если что-то идет не так, команда знает об этом заранее.

Мораль

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

Сейчас мы стабильно работаем и периодически исправляем баги. Кстати, если поможете нам с поиском неточностей, будем рады: заходите к нам в Shtab.

Максим Стихарев

Технический директор Shtab

Теги:
Хабы:
Всего голосов 15: ↑5 и ↓10-4
Комментарии18

Публикации

Истории

Работа

DevOps инженер
53 вакансии
Программист C++
109 вакансий
QT разработчик
12 вакансий
React разработчик
51 вакансия

Ближайшие события

Конференция «IT IS CONF 2024»
Дата20 июня
Время09:00 – 19:00
Место
Екатеринбург
Summer Merge
Дата28 – 30 июня
Время11:00
Место
Ульяновская область