Сам себе режиссёр?

Сегодня принято считать, что FrontOps — это попытка соединить посредственного DevOps-инженера и фронтендера в одном лице. Но, как по мне — это наглядная демонстрация T-shape подхода в оценке разработчиков

T-shape — это модель компетенций, где обычно выделяют одну доминанту (например, фронтенд) и множество навыков рядом с основным (для фронтендера, например — CI/CD, DevOps, UI/UX и тд)

Также к навыкам рядом можно относить и soft skills, например навык управления командой и прочее

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

В первую очередь, развитие вширь и обретение ещё каких-то навыков за рамками основной компетенции — это отличное развитие «вширь» для любого специалиста в любой профессии

Для кандидата выгода очевидна:
— зачастую выше зарплата
— конкурентное положение на рынке
— больше возможностей для развития внутри основной компетенции за счёт заимствования (очень много что в современном фронтенде взято из бекенда, например)

Для компании, в целом, тоже:
— человек «швейцарский нож», который способен закрывать большой пул задач без увеличения штата и зарплатного фонда (один крутой разраб всегда дешевле двух хороших)
— быстрее протекают кросс-процессы

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

➡️ Ситуация первая, печальная
Для деплоя по хорошему нужно бы настроить CI/CD. Если фронтендер не может сделать это сам, на проект будет выделен отдельный DevOps (или FrontOps)

Очень часто наблюдается ситуация, в которой DevOps-ов не хватает, а на мелких проектах держать отдельного DevOps в целом не рентабельно. В таких случаях создается общий пул и один девопс может работать сразу на нескольких проектах

В этой ситуации есть риск потенциального простоя

Какие выходы есть их этой ситуации?
1. Экстренно дёрнуть девопса с другого проекта (плохо — негативный импакт)
2. Заставить фронтендера учиться как там что делается (плохо — долго)
3. Поставить задачу на холд и ждать когда девопс до нее доберётся (плохо — долго)

➡️ Ситуация вторая, выгодная
Фронтендер сам накидает себе базовый .gitlab-ci.yml, а с этим реально не каждый человек на рынке может справиться, и задача решится за час-два

Из двух этих карикатур лично мне очевидно какую именно выберет большинство руководителей

Лично моя философия в том, что не существует такой позиции, как FrontOps-инженер

FrontOps — это фронтендер, который что-то как-то умеет в DevOps (в большинстве случаев)

FrontOps — это DevOps, который что-то как-то умеет в фронтенд

Иного я никогда в своей жизни не видел

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

FrontOps это не про замену DevOps как такового. Более того, в бигтехе иногда девопс настолько сложный бывает, что разработчика во все процессы погрузить ну очень уж сложно и дорого, поэтому отдельные девопсы и существуют

FrontOps это больше о:
— хотя бы примитивном CI/CD
— базовом понимании что такое nginx, CDN, кеширование
— умении добавить джобу на прогон юнит тестов без слёз
— умении прочитать логи с кубер пода, логи с sentry, нажать кнопку в кейклоке без панических атак ну и тд

Навык безусловно полезный и который точно нужно качать, но какого-то «рецепта успеха» тут точно нет

Самый адекватный способ преисполниться в таких процессах — это написать десяток пет-проектов разной направленности или взять подобную задачу на работе, иначе получить какой-то релевантный опыт ИМХО тут просто невозможно

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

Также советую прочитать статью из блога Игоря Федюкина

Не бомбите, берегите нервы, себя и своих близких. Всех благ❤️

@prog_way_blog — чат