Наши статьи

Тайная жизнь мидл бекенд-разработчика

Компания
У России три пути.. И два из них мне точно не подходят.

Примерно такой логикой я руководствовался когда пришлось думать о

будущей профессии. В университете я начал изучать python, и практически все лабораторные работы и курсовые делал на нем.

Также я и познакомился с backend-разработкой. Для местного конкурса ctf я писал проект на django, и позже, писал курсовую работу на flask.

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

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

Прежде чем выпустить меня на боевой проект, мне сказали:

- Учи Docker.

Окей, тогда я использовал Windows в качестве операционной системы, у меня был слабый ноутбук, я физически не мог запустить Docker под Windows.

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

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

1 - это был парсер, который отправлял свежие и обновленные мероприятия на основной сервер;

2 - основной сервер, который взаимодействовал с мобильным приложением. Все было написано на Django.

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

В качестве положительных итогов можно выделить:

- Расширенный функционал приложения

- Написание и поддержка новых парсеров

- Успешный перенос прода с одного сервиса на другой

- Приобретение бесценного опыта

В качестве отрицательных итогов можно выделить:

- Отправка 1500 одинаковых писем на электронную почту заказчику за утро

- Уничтожение и последствующая реанимация прода, за 20 минут до демонстрации

Периодически были мелкие проекты связанные с парсингом, отчетами, и прочими бизнес задачами. Но однажды это должно было случиться, и случилось - я получил проект который нужно было делать с нуля.

Это было небольшое фитнес приложение, в котором было много текстовых и медиа данных, а также чат с заказчиком приложения)). Это было немного, но это честная работа. Чат был сделан с помощью django channels, это было интересно попробовать, однако сейчас я понимаю, что мое исполнение этой фичи нужно поставить в золотую рамку музея “Как не надо делать”.

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

Иногда на пути разработчика встречаются заказчики которые хотят "Одно приложение чтобы править ими всеми". Мне кажется диалоги с ними выглядят примерно так:

- Что вы хотите чтобы было в MVP?

- Всё.

Окей, мы начали. Чаты мы в итоге сделали с помощью Centrifugo - это сокет сервер, написанный на Go. В проекте была куча периодических задач - этим занимался Celery. Хотите нестрогий поиск? Вот вам алгоритмы на основе расстояния Левенштейна. Слишком много точек отображается на карте в большом масштабе? Значит добавляем кластеризацию объектов. За время этого проекта сложилось ощущение,что мы попробовали все... Но время показало как мы ошибались.

Были и другие проекты, но во всех них, я просто применял те знания, которые я получил до этого.

Далее мой первый аутстаф, прошел собеседование, вышел из родного гнезда компании - страшно, ничего непонятно, незнакомые люди и… openstack. Мы писали прослойку между фронтом и апи опенстека, за каждый логический модуль консоли управления виртуальными машинами отвечал отдельный микросервис на fastapi. На следующие два месяца моими друзьями стали Nova, Cinder, Glance, Keystone, Neutron и прочие компоненты Openstack, довелось поработать с s3, cockroach db и коллегами из других стран.

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

Я читаю это сообщение... и делаю alt+tab из чата.

Я оттягивал этот момент до последнего. Но, как выяснилось в итоге, зря волновался. Мы поняли друг друга, я получил удовольствие от нового опыта, и научился тому, что нет смысла откладывать страшные на первый взгляд вещи на потом).

Тот проект вскоре мы сдали, и вдохновленный этим опытом, я хотел снова пойти на аутстаф, на проект побольше, в большую команду.

Такая возможность вскоре представилась, и встречайте:

- огромное количество чатов

- огромное количество людей в них

- неясный пока тебе флоу проекта

- два огромных репозитория с кодом

- особенности с запуском этого всего локально

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

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

И напоследок главное правило бойцовского клуба большого проекта - если ты задаешь вопрос в общем чате - ты будешь проигнорирован.

Мой путь в программировании наверное не такой, каким он наверное должен быть, с глубоким изучением программирования в университете (у нас все же кодинг не основная специальность) и последующей стажировкой в крупной компании с образцовым рабочим процессом, однако мой опыт может быть полезен кому-то, и поскольку меня еще не уволили, можно сказать, что в целом он удачный.