Comments 22
Фронтендеров вам наоборот придётся всеми силами удерживать от перехода на фреймворк, вышедший час назад.
Когда-то давно мне нужно было нанять человека себе в команду для разработки ПО промышленных контроллеров. Долго я проводил собеседования с людьми, от которых можно было ожидать вменяемых результатов - ребят с профильным образованием. Но поиск совершенно неожиданно остановился на человеке, который никогда в этой области не работал, но проявил редкую заинтересованность и активность в освоении предмета, в кратчайшие сроки показав самые лучшие результаты.
Так что в этом смысле я согласен - такое бывает, но скорее, как исключение, чем удобное и безотказное правило. Всё-таки гораздо эффективнее вести поиск среди целевой группы, но использовать критерии из сферы общего интеллектуального развития, выбирая человека с гибким и живым умом.
Высказывание "талантливый человек талантлив во всём" довольно часто работает, и особенно ценен такой подход в ситуации новых проектов и трудно формализуемых задач, работа над которыми имеет перспективу более 3-5 лет.
Я как фронтендер отношусь к категории "не любой разработчик захочет поменять свой стек", но не потому, что боюсь других фреймворков или прикипел к своему — а потому, что накопился опыт решения широкого спектра задач. На бэкенде на любом языке достаточно просто описывать логику для веб-приложений (взаимодействие с базой очень похожее, апи везде достаточно просто реализуется, паттерны организации кода тоже несложно реимплементируются), меняется лишь синтаксис и названия методов у библиотек.
На фронте же фреймворки и подходы кардинально различаются. За несколько лет работы на одном наступаешь на бесчисленные тысячи граблей в организации эффективной сборки, роутинга с валидациями и редиректами, генерации валидаторов апи, потоков ошибок, изоморфного кода для серверного рендеринга, оптимизации производительности, решения асинхронных проблем, модульного разделения кода с асинхронной подгрузкой, подходов к стилизации, темизации, локализации. Накапливается большое количество кастомного кода, перебираются сотни библиотек, зачастую с детальным изучением их кода и вариантов обхода ограничений. Когда же меняется стек — все нужно подбирать заново и наступать на все грабли.
Даже если знаешь, как идеально все организовать с точки зрения логики — подобрать подходящие библиотеки и написать аналогичную систему на другом стеке — дело не месяцев, но лет, путем нескольких масштабных итераций рефакторинга. Для чего это нужно, если на своем стеке решишь бизнес-задачи за N времени, а на новом за N*X? Если люди приходят "получить новый опыт, расширить свои компетенции и прокачаться" — это хорошо, но компаниям нужно совершенно не это, а качественное и быстрое решение задач. Поэтому на вакансии на других стеках я даже не смотрю — самокритик меня живьем съест, если буду делать задачи за значительно более долгое время, не смогу планировать сроки даже приблизительно, и качество значительно упадет. Считаю, что это более ответственный подход, чем "пойду не знаю куда и будь что будет, там разберусь".
На бэкенде на любом языке достаточно просто описывать логику для веб-приложений (взаимодействие с базой очень похожее, апи везде достаточно просто реализуется, паттерны организации кода тоже несложно реимплементируются), меняется лишь синтаксис и названия методов у библиотек.
Это очень поверхностное суждение, на бэкенде самое интересное начинается далеко не на уровне обработки запросов — это всего лишь триггер, один из множества.
Лично я получаю самое большое удовлетворение когда удаётся сделать так, чтобы потенциально высоконагруженная система перестала такой быть, сохранив при этом внутреннюю простоту.
Так и бэкендер сможет сказать — что там на этом фронте? Все формочки одинаковые, UI паттерны устоялись — знай себе дергай api, да во вьюхи пихай. А вот на бэкенде все разное, там sql, тут nosql, вон там всякие кафки и рэббиты, очереди, многопоточность, нагрузку нужно распределять, данные с одной стороны размажь и продублируй, с другой обеспечь целостность и непротиворечивость…
На мой взгляд разницы во фронтенде и бэкенде особой нет. Везде есть задачи разной степени сложности и в каких-то случаях смена стека проходит проще, в каких-то сложнее.
Я сам фронтендер, если что :)
SQL синтаксис запросов и работа с базой разве сильно отличаются? Если используются ORM, только в синтаксисе различия, поэтому это не в счет сложности миграции. Кафки и рэббиты тоже те же самые, адаптеры как правило пишутся в сопоставимом формате — разве нет? Та же история про целостность и непротиворечивость — паттерны реимплементируются. Конечно, будут некоторые локальные особенности и ограничения подходов в фреймворках на других языках — но концептуально все, в моем понимании, то же самое.
А вот многопоточность да, может очень сильно различаться. Если не прав, буду рад более подробному объяснению — сам только на php и node.js фулстачил, да на python по мелочи дорабатывал — каких-то концептуальных отличий не видел, кроме ноды — там можно писать изоморфный код бэк-фронт, делать единую схему моделей и валидаций апи бэк-фронт. В этом смысле удобство и переиспользуемость шикарные, но производительность по сравнению с более низкоуровневыми серверными языками оставляет желать лучшего (судя по обзорным статьям), хотя и на ноде под танком 1000 запросов / сек для ряда кейсов сервер за 10мс секунд стабильно отдавал ответ, если задача не требует подключения к базе. Существенные различия по скорости только в сложных сценариях, включающих походы в разные базы и микросервисы. Но у нас речь не о скорости, а о сложности перехода в бэке с одного стека на другой — и тут мой опыт говорит, что это намного проще, чем на фронте.
Стоит наверное начать с того, что одних популярных баз сейчас очень много: реляционные (MySQL, PostgreSQL), документоориентированные (MongoDB), key-value (Redis, Memcache), колоночные (Clickhouse) и wide-column (Cassandra, ScyllaDB), NewSQL (CockroachDB, TiDB), графовые (Neo4j, Dgraph) и полнотекстовые (Elasticsearch, Sphinx), есть ещё базы для control-plane (ZooKeeper, Consul, Etcd).
С message-brokers в целом попроще, основные это: RabbitMQ, Kafka и Pulsar — у каждой своя архитектура и каждая со своими особенностями и best-practices.
Хорошо бы понимать хотя бы примерно как они устроены внутри, в чём их различия и уметь их эффективно применять.
Да, с половиной я работал, и с Firebase для no-server сайтов. Речь о том, насколько разное взаимодействие с одной и той же базой на разных серверных языках. Вряд ли переход на другой язык потребует внезапно изменить базу одного типа на другую — скорее всего останется та же самая, а переход на другую будет по причинам, не зависимым от языка.
Во фронтенде используется хранилище в оперативной памяти, взаимодействие с которым реализуется через state manager, который у разных фреймворков, как правило, кардинально различается, и в этом плане все сложнее.
Всё так. У меня по этому поводу как раз синдром самозванца. Мне постоянно присылают непрошенные вакансии на Java/Kotlin (и почему-то даже .NET) senior developer. Я читаю список требований и понимаю, что вообще мои текущий знания нерелевантны. И что мне делать, если меня внезапно попрут с текущего места? Остаётся только надеяться, что рано или поздно я выйду на людей, которых впечатлит мой опыт и мои скилы и которые поверят, что вспомнить Spring, которого я лет 8 уже не трогал, я быстро смогу. Но учитывая конвейер найма, не думаю, что это случится прямо совсем быстро. Останется мне с апломбом приходить и заявлять, что я синиор и продаю не знания какого-то там фреймворка, а общеинженерные навыки. Интересно, вот действительно, что важнее: понимать, как в очередном фреймворке используются корутины Kotlin или глубокое понимание устройства этих самых корутин и причин именно такого их дизайна в языке и рантайме языка?
Ещё такой момент, что в любом случае в каждой компании есть своя культура, своя специфика. В неё всё равно придётся вникать, и порой там пласты будут побольше, чем просто разобраться в каком-нибудь стеке. Так что совокупный вклад стека в онбординг будет не таким уж большим.
Конечно, это работает, если человек переходит с бэкэнда на бэкэнд - стеки хоть и разные, но общие подходы в принципе уже давно отработаны и ничего принципиально нового так же не то, чтобы очень много появляется. А вот с бэкэнда на фронтэнд перейти или вообще попасть в бэкэнд из чего-то где нет такого разделения (например, из разработки компиляторов) будет сложнее, т.к. нет понимания, какие задачи возникают и какие бывают подходы к их решению.
И главное: вот нанимаешь такой человека с хорошим резюме. И вещи он правильные на собеседовании говорит. А как нанимаешь - он сидит и пишет комментарии на Хабре ничего не делает. Так что в этом смысле конкретный стек вообще вещь не принципиальная.
и которые поверят, что вспомнить Spring, которого я лет 8 уже не трогалВы не одиноки! Из-за повального засилья Spring в вакансиях, пришлось несколько лет назад расширить кругозор и начать использовать Golang в небольших проектах. Просто чтобы хоть какая-то подушка безопасности была.
или вообще попасть в бэкэнд из чего-то где нет такого разделения (например, из разработки компиляторов) будет сложнее, т.к. нет понимания, какие задачи возникают и какие бывают подходы к их решению.
Знают программисты всё. Даже побольше всего вашего веба с его абстракцией на абстракции, передачей всех объектов первым классом и отсутствием адекватных подходов к конструкции сайтов, где дизайнерские выглядят сделанными на коленке, а простые энтузиасты кажутся богами в дизайне. Кто вам вообще дал право судить, что знает конкретный человек, а что нет?!
вот нанимаешь такой человека с хорошим резюме. И вещи он правильные на собеседовании говорит. А как нанимаешь - он сидит и
пишет комментарии на Хабреничего не делает.
Либо делать реально нечего, либо превираете вы сильно.
Нанимать человека, чтобы он вашей галерке работу у фрилансеров отбирал такое себе достижение российского IT.
Во-первых, многие, и особенно кандидаты, до сих пор верят, что стек — это первый фильтр, по которому отсеиваются вакансии и резюме. Мне бы хотелось, чтобы больше людей понимало, что это далеко не всегда так.
Я тоже думаю, что сменить стек бакенда не проблема, если речь не идет о чем-то с большим порогом вхождения типа С++.
Мой стек это python/django также был опыт работы 2.5 года node.js. Конечно же я знаком с другими языками программирования C++/Go/Kotlin/Rust, но большого опыта в них нет, так что на это никто даже не смотрит.
Я пробовал откликаться на вакансии на go, и мне вообще никто не ответил. Я правда не много откликался, но все-таки это показатель.
А в одной вакансии по node.js мне сказали, что мой опыт c node.js не релевантен, т.к. это было 5 лет назад и что 2.5 года этого не достаточно. (Это при общем стаже 14 лет)
С незнакомым стеком тратится туча времени на дурацкие ошибки от разного приведения типов до непривычных способов работы с стандартными вещами (с массивами, например) и изобретения велосипедов, которые в данном стеке уже существуют.
Иногда можно потерпеть этап "собирания граблей" ради хорошего в целом специалиста, но это редко кто будет делать. Поэтому такой бонус я бы указывал отдельно!
А разве смена стека — это не шаг назад в карьере?
Тут мое мнение совпадает с вашим, и я полностью согласен с вашими доводами.
Но есть но, на мой взгляд, или я может с таким сталкивался и не знаю обратной стороны, для компаний которые тебя в дальнейшем будут звать на интервью это так, и это повод снизить сумму офера.
Более того на одном из прошлых мест работы, когда ты помогал ребятам с java, руководителем это не воспринималось как твое развитие, следовательно ты не растешь как специалист в своей области, а исходя из этого и поднимать тебе зп нет смысла. Хоть это и грустно, но я с таким сталкивался ни раз :(
Я придерживаюсь таких же принципов, стек не важен. Сам менял C++ на Java, на C++, на C#, на С++. Работодатели попадались разумные, скажем когда проходил последнее интервью на С++ позицию, писал код на С#. Ничего, одна из интервьюеров оказалось была Java программистом, и когда я написал что-то неправильное с точки зрения Java мы приятно обсудили разницу в пространствах имён в Java и C#.
Но надо очень следить что человек будет учить новый стек, а не работать по принципу "на Фортране можно писать на любом языке". У нас часть тестов были на Питоне, и занявшись ими однажды, я ужаснулся как всё ужасно, сколько ошибок они пропускают и так далее. Были написаны как на Фортране, ничего не ясно, кроме того что там миллион багов. Вот за такое надо было гнать. Я Питон знаю плохо, но поймал знакомого питониста, и за 30 минут мы превратили это в идиоматический Питон, код читался как родной язык.
Во фронтенде фреймворк зачастую подменяет основы веба: вместо HTML специфичные компоненты, вместо CSS - Styled Components, и так далее. Настолько, что знание основ может даже мешать: как например onInput/onChange в React.
Другое дело, что это не отменяет необходимости знания основ программирования, тех же структур данных, многопоточности, сложности алгоритмов. Если эти знания есть, то любой фреймворк не должен быть проблемой.
По поводу идеи "У нас проект на Java, а не сможем ли мы переписать его на Пайтон?". Очень условно говорим, что если к нам пришел "явно не Джун" в Пайтоне, то он понимает, что в Пайтон он будет использовать вместо JDBC. Это я сейчас пишу условно, т.к. я совсем не программист.
Значит ему только нужно объяснить опсам, что установить на сервер вместо GlassFish.
Лично я пока наоборот придерживаюсь гиперспециализации. При рассмотрении вакансий ориентируюсь не только на ЯП, но и на фреймворк. Еще, желательно, и современных версий. Т.к. опыта работы с ним уже накопилось немало, куча подводных камней найдена и успешно обойдена, да и в целом он меня устраивает. Так зачем же распыляться?
Ясное дело, если у вас очередь отличных специалистов, которые вдоль и поперек знают какую-нибудь Django (или на чем там у вас бек)
Если разраб вдоль и поперёк знает только один фреймворк, 3/4 батареек из которого становятся все менее актуальны, он не такой уж и отличный. Сейчас все новое пилят на сервисах/микросервисах и питонисту, стоит иметь представление о 3-4 фреймворках:
что-то простое, как топор (flask)
что-то асинхронное и простое, как топор (aiohttp)
что-то напичканное полезными батарейками (FastApi/Django, чаще DRF)
Поэтому да, крут тот, кто знает в первую очередь базу, а не фреймворк. И подход:
На собеседовании мы обсуждаем вопросы, общие для всех бекендовых стеков: как работает HTTP, что делать, чтобы сервис держал нагрузку, как проектировать схемы БД, как искать и устранять ошибки и т.д.
как раз отсеит тех, кто ковырял только джангу. Но так ли нужно ли это, если:
Ничего особо экзотического: Python, Django, MySQL, вот это все
?
Главное быть профи в своём деле, а не раскидываться на всё и понемногу. В конечном итоге так ничего знать и не будешь на хорошем уровне.
Вместо тысячи слов:
Так ли важно, на каком стеке вы умеете писать бекенд? А фронтенд?