Комментарии 40
Мне кажется, что если у вас в проекте есть фуллстеки, то тут вероятно что-то из нижеперечисленного:
1) вы консалтинговая компания, которая быстренько прибегает (желательно по тендеру), говнокодит и убегает.
2) вы разрабатываете что-то очень простенькое, где вопросы ядреных оптимизаций не стоят.
3) ваши фуллстеки — это просто перегруженные работой бэки, взявшие на себя фронт, а тот, кто вас нанял, отлично экономит до поры. Либо они выгорят, либо они какие-то мутанты
4) ваши фуллстеки — это девелоперы, которые отлично понимают разницу между собственными интересами и интересами тех, кто их нанял. Они честно работают положенные часы, тратя их на изучение всего что нужно для фуллстеченья. В итоге проект двигается очень медленно или становится кривым, но так как мы не умеем отслеживать продуктивностью программистов, такие ребята могут устроить себе этакий оплачиваемый университет за два-три года.
ЗЫ: Я очень не люблю словосочетания «бизнес-логика», потому что под это что только не подписывают. Никогда не видели, как делающий кнопочки фронтэндщик рассуждает, что переключение стилей нажимаемых кнопок — это у него «бизнес-логика»? А я видел.
Моё мнение, что любой сервис должен быть в первую очередь доступен и полностью работоспособен через API, во вторую — иметь доступ к этому API через максимально простой интерфейс, и только на третьем месте — свистелки, метеоризм и прочий реакт с вебпаком, как бы ни странно это звучало от человека, чьим основным хлебом очень долго был фронт.
любой сервис должен быть
Чрезмерные обобщения до добра вас никогда не доведут. Не любой.
Широкому слою общепубличных вещей «простой интерфейс» к API вообще нафиг не сдался, и может спокойно полностью отсутствовать.
Для вещей, где важна именно клиентская логика работы — да тот же гугльдокс — бекэнд будет в многие разы проще фронтэнда. Он конечно всё равно нужен, но соль совершенно не в нём.
2) вы разрабатываете что-то очень простенькое, где вопросы ядреных оптимизаций не стоят
В большинстве приложений не стоят вопросы ядреных оптимизаций.
И даже в оставшемся меньшинстве ядреные оптимизации нужны, как правило, только для небольшого подмножества задач.
Так что ваш пункт 2 покрывает довольно-таки большой спектр работ )
Либо стоит уточнить, что вы называете ядреными оптимизациями.
Переоптимизация — типичная ошибка джунов.
Насколько большие проекты вы разрабатываете? RPS?
Я веду к тому, что совсем без оптимизации нельзя. Как минимум индексы должны быть проставлены корректно
Если у вас наблюдаются тормоза в базе и вы не в курсе про индексы, то платится за 2-3 часа *DB expert и он вам ставит индексы.
Более того, я постоянно вижу высоконагруженные системы, в которых не только индексов нет, но и на 128Gb RAM сервере mysql использует конфиг по умолчанию и выделяет себе 2гб. Ничего, работает все. Просто ставят быстрые SSD и куча процессоров.
Оптимизация имеет смысл, когда у вас уже есть пользователи. На старте более важно, чтоб работало хоть как-то.
Я разрабатываю разные проекты, у меня вторая специализация mysql. Но по факту эти оптимизации не везде нужны, мягко говоря. Современное железо нереально круто. Даже full-scan по таблице в 2млн выполняется секунды.
Индексы — слишком надуманный пример.
Пусть будет пример с циклом в цикле в котором идёт обращением к БД.
На нормальном ревью, коллеги должны отклонить такой запрос. Ведь даже, несмотря на знаменитое высказывание кнута о преждевременной оптимизации, допускать такое в коде — просто небрежность.
Да, там можно соптимизировать. Да, я знаю как.
Но оптимизация будет стоить не меньше дня разработки, а неоптимизированный код кушает всего два ядра из 56, потому будет еще работать долго. Просто вынесен на отдельные ядра и все.
Я все же придерживаюсь позиции, что лучше иметь начальные знания у всех разработчиков, чем глубокие, но 10х размер команды.
Как минимум пока проект не приносит миллион в год.
Понятно, что если у вас 50-500 человек сидит в офисе, то выгоднее для всего кроме прототипов узкая специализация. Но в малых командах не все так очевидно.
Так что делать фуллстеку-то? Уходить в узкую область или продолжать развивать кругозор?
Надо взвешивать плюсы и минусы. ЗП у fullstack и узкого специалиста, плюс-минус равны, но узкому быстрее расти.
Я ушел с fullstack разработки во frontend, и знания fullstack'а мне очень помогают понимать весь процесс разработки, легко читать серверный код, чтобы лучше понимать его поведение на мои запросы, иногда могу что-то дописать (но по этическим соображениям стараюсь этого не делать, если под это выделены люди). Я стал меньше уставать, т.к. из-за того, что я лучше знаю свою область, мне приходится меньше штудировать документацию, ловить баги. Учиться приходится столько же, т.к. материала для изучения все равно очень много даже в узких областях. Но думаю, в этом нет необходимости, можно спокойно сосредоточится только на том, что необходимо в работе.
Надо понимать, что плюсов fullstack'а больше для работодателя, а не для вас лично. Нужно в первую очередь думать о себе, понимать, что нужно в вам, чтобы проще и эффективнее работать, также нужно выделять время на отдых и хобби, иначе если перегорите, потеряете очень много времени и сил на восстановление (если вообще восстановитесь).
Ну а если интересен и бэк, и фронт, и хочется иметь широкий кругозор? Даже будучи фуллстеком хочется осваивать смежные стеки, но на все времени не хватит. Так же, если уже подсел на иглу фуллстека, слезть с нее непросто, поскольку в узкой специализации фуллстек скорее всего проиграет тем, кто давно является узким спецом.
Ну а если интересен и бэк, и фронт, и хочется иметь широкий кругозор?
Можно просто сделать смещение в определенную сторону. Например, больше заниматься backend разработкой, а frontend по мелочи. Или заниматься frontend разработкой, а backend заменить на nodejs. Моя основная мысль, чтобы на работе использовать один стек, а дома в своих проектах можно заниматься чем хочется.
Даже будучи фуллстеком хочется осваивать смежные стеки, но на все времени не хватит.
Это сложная проблема. В жизни очень много чего интересного, чем мне хотелось бы заниматься, но времени и сил на все не хватает. Но нужно оценивать свои силы, чтобы потом не перегореть и не потерять интерес ко всему.
Так же, если уже подсел на иглу фуллстека, слезть с нее непросто, поскольку в узкой специализации фуллстек скорее всего проиграет тем, кто давно является узким спецом.
Я плавно переходил. Я не бросал fullstack разработку, просто сконцентрировал обучение на frontend, да и сейчас по мелочи пишу на питоне. Таким образом, у вас будет серьезный плюс над другими узкими разработчиками, например в frontend — вы будете понимать внутреннюю кухню бека, лучше понимать взаимодействие фронта и бека, легче будет общаться с backend'разработчиками, понимать их. Это отличный пункт в резюме.
т.е. я не говорю, что стоит бросить один стек, достаточно сконцентрировать свое внимание на определенном, а также поменять специализацию с фуллстека на определенную. Выберите ту, которую лучше знаете, или которая больше нравится.
Рекомендую прокачивать скилл ораторского искусства и уверенности, это поможет и время высвободить, и ЗП увеличить
Когда бек и фронт делают архитектуру сами по себе, получается полный треш и угар, в стиле «вот вам REST-API как в книжке, GET /users?id=123, живите как хотите». И фронт начинает делать распределенные join-ы данных из нескольких микросервисов, а бек — чинить возникшие от этого проблемы с перформансом.
Или все пытаются имплементнуть что-то дикое, что вообще бы техлид-фуллстек отговорил бы делать на этапе дизайна.
Или фронтам приходится закрывать архитектурные дыры бека, вроде «покажите какой-нибудь спиннер там пока наши микро-сервисы синхронизируются через очередь», или «если сервис А лежит, а Б — нет, должно как-то там все работать».
Короче фулл-стеки нужны как минимум, чтобы тех-лидить веб-проекты. Тех лид на веб-проекте без фулл-стека — это какое-то дно, непонятно как вообще оно может работать.
В статье точно есть цитата, что фулстекам не хватает глубины. А также есть мысль, что я не приписываю фулстеку лидерские качества (тимлидинг соответственно, думаю, это очевидно).
Ни о каких «отделах» в статье речи не идёт в принципе. Взаимодействия и отношения внутри отделов разработки — это отдельная тема. К этой статье отношения не имеет.
Вы два раза в своём комментарии упомянули, что я якобы имел ввиду, что фулстек — это тимлид. Поэтому во второй раз попрошу вас внимательно перечитать и обратить внимание, что тимлидерских качеств я фулстеку не придавал, а наоборот обращал внимание, что это про другое.
И так же, прошу обратить ваше внимание на начало моего материала, где явно дал понять, что это личное мнение, не претендующее на последнюю инстанцию.
Страшно за медленный рост в знаниях, из-за широкого спектра. Нет времени на ковыряние инструментов, надо писать
Как по мне, фуллстэки — те, кому нужно контролировать всё и вся. Да и людей, которые не умеют ни в один стэк, тоже встречал. Лучше выбрать одну сторону.
Исповедь фуллстека: профессия, религия, мечты