В первой из серии статей поделюсь планами по улучшению процессов разработки бэкенда. Рассказываю о том, что планируем автоматизировать, описать и улучшить.
Привет! Как и все, мы в along.pw строим планы по развитию нашей компании на предстоящий год.
В этой статье рассказываем о том, что планируем улучшить в процессе разработки продуктов. Тут только про техническую часть, про процессы и менеджмент - в другой раз
Начнем со стека
Главный продукт Along — это мобильные приложения для стартапов на ранней стадии.
Серверная часть разрабатывается на фреймворке Django/DRF, или на FastAPI
Клиентская часть приложения разрабатывается на Flutter
Приложения мы научились делать довольно быстро и дешево, сохраняя при этом качественный результат, благодаря следующим правилам
- Переиспользование компонентов
- Автоматизация пайплайнов
- Быстрый сбор обратной связи для доработки
Все три правила помогают нам экономить ресурсы нам и нашим клиентам. Улучшения со стороны бэкенда по пунктам ниже
Шаблонные репозитории проектов
Каждый проект должен иметь одинаковую структуру. Две главные причины, почему это нужно:
- В первую очередь для того, чтобы разработчик мог в любой момент залезть в код незнакомого проекта и не заблудиться там на недельку-другую, разбираясь в структуре и методах кода
Во-вторых, для того, чтобы ускорить инициализацию проекта. Не нужно будет каждый раз создавать все с нуля, вместо этого будет ready-to-deploy проект, в котором можно быстро начать воплощать желаемое в действительное
Реализовывать это мы планируем при помощи Cookiecutter - это когда создается один репозиторий "на стероидах", в котором хранятся всевозможные конфигурации проекта.
Когда необходимо создать новый проект, разработчику предлагается пройти опрос, по которому определяется необходимый набор фишечек в системе.
Там можно конфигурировать как и сервисы, которые мы используем, так и конкретные модули, которые зачастую встречаются во всех проектах.
По итогу получается готовый к использованию/деплою сервис, в котором уже ведется работа над специфичной бизнес-логикой
В течение года мы будем анализировать наши проекты и искать в них модули, которые потенциально могут переиспользоваться в будущих проектах. После чего будем добавлять их в базовый репозиторий
Регламенты
Чтобы грамотно работать с нашим базовым репозиторием и самими проектами, мы будем четко прописывать регламенты, по которым ведется разработка. Основные части, которые подвергнутся регламентированию:
- Описание запросов в документации API
- Добавление новых компонентов в базовый репозиторий/проект
- Написания тестов
Проверять соблюдение наших регламентов, мы будем за счет внедрения дополнительных проверок в наш ci/cd.
Сейчас мы пишем кастомную интеграцию между TeamCity, который используется для деплоя, и Gitea - нашей self-hosted системой контроля версий. При помощи этой интеграции будем проверять каждую фичу перед отправкой на сервер
База знаний
Все это должно где-то храниться, чтобы каждый новый сотрудник мог вкатиться в наши процессы разработки, а каждый "старичок" - освежить их у себя в памяти
База знаний поможет нам отойти от такого подхода
Основные разделы базы знаний для бэкенда:
- Обзор. Что у нас есть, и для чего мы это используем. С чего начать изучение
- Создание проекта. Пошаговая инструкция по инициализации проекта. В этом же разделе будет информация по базовым репозитория и как ими пользоваться
- Тестирование. Что мы покрываем тестами, в каком случае их нужно писать, а в каком нет. Как правильно писать тесты, чтобы они приносили пользу
- ci/cd. Настройка пайплайнов для наших проектов, обзор системы и инструкция по использованию и расширению
- Полезные материалы. Что стоит почитать в свободное от работы время, чтобы прокачать свой скилл разработчика.
Базу знаний мы планируем организовать внутри нашего гита, используя wiki раздел. В нем можно организовать красивую структуру и все аккуратно отформатировать при помощи Markdown языка разметки.
Городить сложные системы по типу Confluence посчитали нецелесообразным, поскольку информации у нас пока не так много, да и плодить кучу сервисов, которые использует команда, тоже не хочется
Пишите, где мы все делаем не так, и как делать надо, буду очень благодарен! Написать потом статью с результатами изменений?
Ждём вас в нашем тг-канал @alongpw — мы пишем про создание стартапов, разработку и управление проектами.
Идея писать документацию - хороша :)
Но из опыта скажу - серьёзная документация требует организационного решения:
- кто и когда должен писать какие разделы,
- как его этому обучить и на это мотивировать,
- кто и когда будет контролировать соответствие написанной документации реальности.
Описания этого решения в тексте явно не хватает :)
Хороший комментарий! Мы решили эту проблему так:
- собрали команду из людей, которые больше всего заинтересованы в расширении внутренней инфраструктуры
- мы работаем как студия, поэтому для нас внутренние улучшения устроены как проект на заказ. Я выступаю в роли заказчика, а команда вместе с ПМом в роли исполнителей
Отличная статья! Интересно еще, почему вы используете только селф-хостед решения (для гита например)?
прикольно когда СЕО компании из поста задает вопрос в комментах)))
Ну надо же с чего-то начинать)
это намного более безопасно, плюс чтобы нам не пришлось в срочном порядке искать альтернативы, в случае "необычных" ситуаций)
Грамотный и систематический подход это здорово, но сколько уйдёт времени на создание всего этого?(ну точнее создании той же базы знаний)
Альтернатива этому - суперзнающий лид как на картинке. Вскоре его задолбают вопросами и он будет отвечать: "смотрите код". В результате разработчик будет делать задачу в два раза дольше, не зная нюансов.
Когда работаешь на проекте, где есть документация, то сразу понимаешь, что работа по её составлению была проделана не зря.
Но самое сложное в документации - не писать её, а поддерживать в актуальном состоянии.
полностью с вами согласен!
мы планируем выделять определенное количество часов на улучшение внутрянки, чтобы был баланс между проектами и внутренними процессами. А там уже посмотрим по ситуации, что получится сделать и что будет важнее для нас
будем использовать наш любимый гибкий подход)
Не знал что у гита есть вики раздел. Какой командой посмотреть? git wiki не срабатывает.
Ну как бы это опция гит-хостинга, а не натив самого гита.
https://docs.gitlab.com/ee/user/project/wiki/
https://docs.github.com/en/communities/documenting-your-project-with-wikis/about-wikis
Так надо так и писать, а не путать понятия.
это нужно настраивать в месте, куда вы свой код загружаете. У нас это Gitea, большинство используют GitHub или GitLab
Я о том, что надо быть точнее в терминологии.
Согласен, буду учитывать в своих будущих материалах. Спасибо!
Спасибо за статью. А почему не используете Gitlab CE (вместо TeamCity + Gitea)? Он тоже self-hosted
мы используем YouTrack в качестве тасктрекера, и выбрали TeamCity, чтобы быть в одной системе. Плюс так сильно дешевле) Gitea вообще опенсорс
Понятно. Но если что - Gitlab CE тоже open-source и тоже бесплатный :)
Комментарий недоступен
Можно же. И Merge Request и Protected Branch в self-hosted есть. Или вы о чем-то другом?
Комментарий удален модератором
Спасибо)
Не заметил у вас пункта о требованиях:
Что я считаю очень важным документировать для заказной разработки - это окончательные, детальные требования к приложению, то есть, как же в итоге должно быть. Если это не документировать, то очень сложно потом бывает что-то починить или не сломать при развитии, потому что знания об итоговых требованиях как назло оказываются в голове человека, которого с нами сейчас нет. Приходится читать код, изучать данные в базе и логах, что затратно и всё равно не гарантирует полного понимания всех требуемых вариантов использования.
По теории, это знание раскрывается тестами, но практика показывает, что всё тестами не покроешь по причине их затратности. Описать же 100% требований текстом вполне посильно, а при наличии шаблона и навыков - и недолго.
Да, вы правы - покрывать все тестами в наших планах нет, потому что они слишком затратны для большинства клиентов. Документация по логике у нас идет вместе с документацией запросов API. В них объясняются требования, которые ожидает бэкенд и его ожидаемое поведение. Для этой документации мы как раз-таки будем составлять шаблоны и регламенты по написанию. Вы еще подразумеваете, что бэкендер должен по шаблону в документе с ТЗ описывать свою работу?
Зависит от детальности ваших ТЗ, конечно. Если предположить, что ТЗ у вас детальное, с точностью до каждого поля и развилки, то повторно это описывать смысла нет, разве что уточнить по итогу. В реальности же, как правило, в ТЗ бывает описано всё довольно крупноблочно, детали потом обсуждаются в каких-то переписках, а потом вообще устно. ИМХО, будет полезно, если кто-то в конце соберёт детальные итоговые требования в кучу. Наверное этот кто-то это рядовой разработчик, больше наверное некому. Хотя скорее это работа аналитика, на мой взгляд. Не знаю, есть ли у вас такие.
Комментарий недоступен