Как мы улучшаем жизнь нашим Бэкендерам

В первой из серии статей поделюсь планами по улучшению процессов разработки бэкенда. Рассказываю о том, что планируем автоматизировать, описать и улучшить.

Как мы улучшаем жизнь нашим Бэкендерам

Привет! Как и все, мы в along.pw строим планы по развитию нашей компании на предстоящий год.

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

Начнем со стека

Главный продукт Along — это мобильные приложения для стартапов на ранней стадии.

Серверная часть разрабатывается на фреймворке Django/DRF, или на FastAPI

Клиентская часть приложения разрабатывается на Flutter

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

  • Переиспользование компонентов
  • Автоматизация пайплайнов
  • Быстрый сбор обратной связи для доработки

Все три правила помогают нам экономить ресурсы нам и нашим клиентам. Улучшения со стороны бэкенда по пунктам ниже

Шаблонные репозитории проектов

Каждый проект должен иметь одинаковую структуру. Две главные причины, почему это нужно:

  • В первую очередь для того, чтобы разработчик мог в любой момент залезть в код незнакомого проекта и не заблудиться там на недельку-другую, разбираясь в структуре и методах кода
  • Во-вторых, для того, чтобы ускорить инициализацию проекта. Не нужно будет каждый раз создавать все с нуля, вместо этого будет ready-to-deploy проект, в котором можно быстро начать воплощать желаемое в действительное

Реализовывать это мы планируем при помощи Cookiecutter - это когда создается один репозиторий "на стероидах", в котором хранятся всевозможные конфигурации проекта.

Как мы улучшаем жизнь нашим Бэкендерам

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

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

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

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

Регламенты

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

  • Описание запросов в документации API
  • Добавление новых компонентов в базовый репозиторий/проект
  • Написания тестов

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

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

База знаний

Все это должно где-то храниться, чтобы каждый новый сотрудник мог вкатиться в наши процессы разработки, а каждый "старичок" - освежить их у себя в памяти

<p>База знаний поможет нам отойти от такого подхода</p>

База знаний поможет нам отойти от такого подхода

Основные разделы базы знаний для бэкенда:

  • Обзор. Что у нас есть, и для чего мы это используем. С чего начать изучение
  • Создание проекта. Пошаговая инструкция по инициализации проекта. В этом же разделе будет информация по базовым репозитория и как ими пользоваться
  • Тестирование. Что мы покрываем тестами, в каком случае их нужно писать, а в каком нет. Как правильно писать тесты, чтобы они приносили пользу
  • ci/cd. Настройка пайплайнов для наших проектов, обзор системы и инструкция по использованию и расширению
  • Полезные материалы. Что стоит почитать в свободное от работы время, чтобы прокачать свой скилл разработчика.

Базу знаний мы планируем организовать внутри нашего гита, используя wiki раздел. В нем можно организовать красивую структуру и все аккуратно отформатировать при помощи Markdown языка разметки.

Городить сложные системы по типу Confluence посчитали нецелесообразным, поскольку информации у нас пока не так много, да и плодить кучу сервисов, которые использует команда, тоже не хочется

Пишите, где мы все делаем не так, и как делать надо, буду очень благодарен! Написать потом статью с результатами изменений?

Ждём вас в нашем тг-канал @alongpw — мы пишем про создание стартапов, разработку и управление проектами.

27
26 комментариев

Идея писать документацию - хороша :)
Но из опыта скажу - серьёзная документация требует организационного решения:
- кто и когда должен писать какие разделы,
- как его этому обучить и на это мотивировать,
- кто и когда будет контролировать соответствие написанной документации реальности.
Описания этого решения в тексте явно не хватает :)

1
Ответить

Хороший комментарий! Мы решили эту проблему так:
- собрали команду из людей, которые больше всего заинтересованы в расширении внутренней инфраструктуры
- мы работаем как студия, поэтому для нас внутренние улучшения устроены как проект на заказ. Я выступаю в роли заказчика, а команда вместе с ПМом в роли исполнителей

Ответить

Отличная статья! Интересно еще, почему вы используете только селф-хостед решения (для гита например)?

Ответить

прикольно когда СЕО компании из поста задает вопрос в комментах)))

2
Ответить

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

2
Ответить

Грамотный и систематический подход это здорово, но сколько уйдёт времени на создание всего этого?(ну точнее создании той же базы знаний)

Ответить

Альтернатива этому - суперзнающий лид как на картинке. Вскоре его задолбают вопросами и он будет отвечать: "смотрите код". В результате разработчик будет делать задачу в два раза дольше, не зная нюансов.

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

Но самое сложное в документации - не писать её, а поддерживать в актуальном состоянии.

2
Ответить