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