В этой статье рассказываем о том, что планируем улучшить в процессе разработки продуктов. Тут только про техническую часть, про процессы и менеджмент - в другой раз
Начнем со стека
Главный продукт Along — это мобильные приложения для стартапов на ранней стадии.
Серверная часть разрабатывается на фреймворке Django/DRF, или на FastAPI
Клиентская часть приложения разрабатывается на Flutter
Приложения мы научились делать довольно быстро и дешево, сохраняя при этом качественный результат, благодаря следующим правилам
- Переиспользование компонентов
- Автоматизация пайплайнов
- Быстрый сбор обратной связи для доработки
Все три правила помогают нам экономить ресурсы нам и нашим клиентам. Улучшения со стороны бэкенда по пунктам ниже
Шаблонные репозитории проектов
Каждый проект должен иметь одинаковую структуру. Две главные причины, почему это нужно:
- В первую очередь для того, чтобы разработчик мог в любой момент залезть в код незнакомого проекта и не заблудиться там на недельку-другую, разбираясь в структуре и методах кода
- Во-вторых, для того, чтобы ускорить инициализацию проекта. Не нужно будет каждый раз создавать все с нуля, вместо этого будет ready-to-deploy проект, в котором можно быстро начать воплощать желаемое в действительное
Реализовывать это мы планируем при помощи Cookiecutter - это когда создается один репозиторий "на стероидах", в котором хранятся всевозможные конфигурации проекта.
Когда необходимо создать новый проект, разработчику предлагается пройти опрос, по которому определяется необходимый набор фишечек в системе.
Там можно конфигурировать как и сервисы, которые мы используем, так и конкретные модули, которые зачастую встречаются во всех проектах.
По итогу получается готовый к использованию/деплою сервис, в котором уже ведется работа над специфичной бизнес-логикой
В течение года мы будем анализировать наши проекты и искать в них модули, которые потенциально могут переиспользоваться в будущих проектах. После чего будем добавлять их в базовый репозиторий
Регламенты
Чтобы грамотно работать с нашим базовым репозиторием и самими проектами, мы будем четко прописывать регламенты, по которым ведется разработка. Основные части, которые подвергнутся регламентированию:
- Описание запросов в документации API
- Добавление новых компонентов в базовый репозиторий/проект
- Написания тестов
Проверять соблюдение наших регламентов, мы будем за счет внедрения дополнительных проверок в наш ci/cd.
Сейчас мы пишем кастомную интеграцию между TeamCity, который используется для деплоя, и Gitea - нашей self-hosted системой контроля версий. При помощи этой интеграции будем проверять каждую фичу перед отправкой на сервер
База знаний
Все это должно где-то храниться, чтобы каждый новый сотрудник мог вкатиться в наши процессы разработки, а каждый "старичок" - освежить их у себя в памяти
Основные разделы базы знаний для бэкенда:
- Обзор Что у нас есть, и для чего мы это используем. С чего начать изучение
- Создание проекта. Пошаговая инструкция по инициализации проекта. В этом же разделе будет информация по базовым репозитория и как ими пользоваться
- Тестирование. Что мы покрываем тестами, в каком случае их нужно писать, а в каком нет. Как правильно писать тесты, чтобы они приносили пользу
- ci/cd. Настройка пайплайнов для наших проектов, обзор системы и инструкция по использованию и расширению
- Полезные материалы. Что стоит почитать в свободное от работы время, чтобы прокачать свой скилл разработчика.
Базу знаний мы планируем организовать внутри нашего гита, используя wiki раздел. В нем можно организовать красивую структуру и все аккуратно отформатировать при помощи Markdown языка разметки.
Городить сложные системы по типу Confluence посчитали нецелесообразным, поскольку информации у нас пока не так много, да и плодить кучу сервисов, которые использует команда, тоже не хочется
Пишите, где мы все делаем не так, и как делать надо, буду очень благодарен! Написать потом статью с результатами изменений?