Открыть список
Как стать автором
Обновить

Комментарии 57

Спасибо за статью. Да, всё так. Сам такой же, выводы о профессиональном росте и специализации сделал (последние — лет 6 назад) именно такие.
Я далеко не сеньер, но все же думаю чо фулстек это плохо, нельзя знать всего, а с циклом технологии в 3-5 лет тем более. Сам такой внутреннее любопытство постоянно двигает меня вперед, поработал в свое время экономистом, аналитиком, админом, бекендером, сейчас делаю фронт. Плохо когда фронтендер не понимает как работает бекенд или наоборот. Что бы достичь понимания надо сделать пару задач(проектов) на фронте\беке. Развиваться надо во одном направлении, но с пониманием смежных областей, например, если ты фронт, помимо понимания бека, надо еще понимать бизнес на который работаешь, его внутренние чаяния, желания, процессы итд.
Это относится не только разработчикам. То, что вы описали, это концепция T-Shaped скиллов — en.wikipedia.org/wiki/T-shaped_skills

Спасибо интересно

Перестаньте учить «технологии/платформы/инструменты». Это все равно что читать инструкции по профессиональному электроинструменту имея очень поверхностное понятие, зачем он вообще нужен и какие проблемы решает. С этим всем достаточно ознакамливаться. Параллельно практикуя решения тех или иных проблем.

Учить на мой взгляд нужно фундаментальные вещи, такие как: Архитектура Современных Компьютеров, Операционные Системы, Сети, Базы данных, Принципы построения языков программирования, Архитектуру ПО, Системный анализ, etc…

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

С этим пониманием с одной технологии/платформы/стека на другую при надобности вы сможете перескочить в промежутке 1-ого года.

К тому же в таком случае не будет подобного рода проблемм:
А во-вторых (и это главное), я не хочу знать, что такое ДэТэО, где оно лежит и как с ним работать. Мне нужен только путь, метод, параметры и набор ответа. В терминах HTTP/REST.
Потому что и DTO и REST и HTTP — термины вне технологий вне фронтэнда/бэкэнда, вне языков программирования.

Я как раз не предлагаю учить, а скорее попробовать. По срокам согласен. У меня примерно через полгода происходит понимание, что я вышел на сеньорский уровень, а через год приходит понимание, что полгода назад сеньор я был хреновый.


Иногда раньше иногда позже. Все зависит от того, есть ли в текущей команде хорошие практики или надо до них доходить самому.

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

Плюс разные роли скажем аналитик и программист, но могут быть два в одном )
Ну фронт и бэк есть и у десктопных клиентов


Настолько разные, что «десктопный фронт» и «десктопный бэк» стали «типа разными» профессиями?

Всё зависит от величины проекта, а больших проектах есть разделение по функциям разработки. И грязными лапами в бд не всем дозволяется ковыряться)

Вы не ответили на мой вопрос.
К слову, что такое «бэк десктопного клиента»?

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

Например, я работаю в десктопном проект на ~20кк строк (достаточно большой?) и у нас нет базы данных (реляционной во всяком случае).

Если в вашем проекте нет разделения ролей это не значит, что во всех проектах так. Вот взять граф редактор, кто-то делает ui, кто-то работой с файлами разных форматов, кто-то с плагинами для обработки картинки. И все являются крутыми, но узкими специалистами. Фронт бэк — это всего лишь роли, они могут быть и называться как угодно. В проекте также все могут быть универсалами, но это зависит и от проекта и от людей

… и вы начинаете противоречить собственной же статье.

UPD Я повторю вопрос — все эти роли настолько разные и требуют настолько разного набора знаний, что вырождаются в отдельные профессии, как это происходит в вебе, и требуют написания таких статей?
Где-то да, где-то нет. Всё зависит от веса багажа и логичности инструментов. Но и тех, кто работает в энтерпрайзе очень много. И появляются новые ветки профессий, то же машинное обучение. Вроде разобраться в нём несложно, но вот строить достоверные модели… на это потребуется серьезная наработка опыта

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

Причем тут вообще энтерпрайз и машинное обучение если вы же говорите о стеках?
К слову, что же все-таки такое «бэк десктопного клиента»?
Ну вот пара вариантов, реальных, с больших энтерпрайз-систем.

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

2) Да собственно апп-сервер и есть бэк декстопа в multitier, нормальная практика, хоть и устаревшая по нынешним временам.
1) Так десктоп-клиент имеет бэк, или он реализует бэкенд для других клиентов?

2) Бэкенд в multitier — это просто бэкенд.
1) Почему «или»? «и». Имеет бэк (пул апп-серверов и за ним субд-сервера) и сам является бэком для веб-клиентов (планшетов).

2) Ну так он же бэк для десктоп-клиента, или нет? По роли он практически совпадает с бэком для веба, если на то пошло, только протоколы разные. У меня в практике были даже апп-сервера с подключаемыми логическими модулями на жабаскрипте (wss, самодельные расширения для vb и js) — прям ноджысы какой-то.

И, возвращаясь к контексту, программисты для бэк- и фронт-частей в тех проектах были сильно разные как по скиллам, так и по используемому инструментарию (например, Delphi vs C++).
Дело в том, что бэкенд не является частью клиента. Суть архитектуры клиент-сервер в separation of concerns. Соответственно, да, бэкенд может быть ДЛЯ клиента, но он никоим образом не является частью клиента и здесь нет никаких значимых различий с вебом.

А теперь смотрим на исходное сообщения, к которому я привязался с целью выяснить что же все таки понимает под фронтендом и бэкендом автор статьи:
Ну фронт и бэк есть и у десктопных клиентов


У меня возникло ощущение, что автор под словом «бэкенд» понимает совсем не то что я или вы, я пытаюсь выяснить что именно.

UPD Ну и да, исходная мысль была в том, что программирование не ограничивается клиент-серверными архитектурами, где есть выделенные фронтенд и бэкенд.

И, возвращаясь к контексту, программисты для бэк- и фронт-частей в тех проектах были сильно разные как по скиллам, так и по используемому инструментарию (например, Delphi vs C++).


Эта разница обусловлена фундаментальными различиями в программировании фронтенда и бэкенда или просто выбором технологии для их реализации?
У меня возникло ощущение, что автор под словом «бэкенд» понимает совсем не то что я или вы, я пытаюсь выяснить что именно.


Да чёрт его знает, у меня уже ощущение, что мы все говорим об одном и том же, но спотыкаемся на терминологии.

Эта разница обусловлена фундаментальными различиями в программировании фронтенда и бэкенда или просто выбором технологии для их реализации?


Скорее первое, чем второе. Дельфя для формочек, Ся для .dll и .so. Совсем разные задачи и подходы (не то, чтобы совсем-совсем нельзя было всё сделать на чём-то одном, но это был бы явный изврат ради изврата, а когда апп-сервер на другой ОС, то и вообще. Хотя — и такое я встречал).

Не очень понимаю, что вам мешает на C++ рисовать формочки, а на Delphi писать dll. И даже класть формочки в dll. И что тут извратного и принципиально разного?

Ну, например, VCL, наличие и качество компонентов и удобство RAD. А также разница в скорости билда сибилдера и дельфи — дело было в ранних 2000х, на всякий случай, тогда это было очень-очень заметно. В приципе dll и сервисы писались у нас тогда время от времени и на Delphi, но для кросс-платформенных модулей вариантов, прямо скажем, было немного.

А про класть формочки в dll — лучше не напоминайте, это была одна из моих тем в то время, плагинные системы и динамически подгружаемые формы. Ох, сколько она крови выпила…

И таки таки формошлёпство на дельфи требовало совсем одного тулчейна и набора умений, а разработка слоёв апп-логики и бизнес-логики сильно другого. Даже людей нанимали совсем разных, ровно как во фронте/бэке сейчас.

А, да, пока вспомнил: по моему мнению в нормальном современном энтерпрайз-вебе настоящий фулл таки очень редкая зверюшка. Потому что ну очень накладно знать, например, ангуляр 7 в обвязке (не на уровне туториалов, а понимая, что там внутре за неонка в деталях) и, скажем, цэшарп с дотнетом так же глубоко — и поддерживать эти знания актуальными сколь-нибудь длительный период.

Не накладно, если разбираться в фундаменталке, которая под всем этим лежит. Собственно, мы тут вернулись к самому первому комментарию в этой ветке.

… а человек, разбирающийся (действительно разбирающийся) в фундаменталке, называется евангелистом и к практической работе его лучше не допускать. Хотя для всяких PoC он реально незаменим.

Думаю, что такие люди, которые твёрдо знают теорию и при этом так же твёрдо _нюансы_ практики, существуют, но я лично с такими не сталкивался. В смысле — сразу в нескольких областях, в узких темах специалистов много. Это ж ещё надо иметь довольно разный склад характера.

Сам я клонюсь то в теорию, то в практику в зависимости от того, что мне сейчас интереснее (повезло, могу себе позволить) и в результате не знаю ни того, ни другого, а мне за это платят =)

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

Проблема не в фундаменте проблема в деталях. Человек в фундаменталкой сделает все хорошо, человек с наработанностью ещё и быстро. Плюс чтение кода. Есть общепринятые идиомы и лайв хаки. Погруженный спец их читает влет. У меня 7 лет программирования на перл. Но меня $ и @ бьют по глазам после перерыва. Неделя погружения. И они лучшие друзья

Если клиент построен на принципах близких к MVC, то M — бэк

Ага, у меня в голове что то такое крутилось, но сформулировать не смог)

Спасибо. Я собственно пытался подвести к мысли, что в некоторых архитектурах одна из частей клиента как отдельного приложения тоже может быть бэкендом. А отсюда — к мысли, что у веб-приложения работающего внутри браузера есть бэкенд, который пишет… «фронтендер»!

Но диалог пошел по другой ветке.
Ну тогда уж и понимать, что не все работают в энтерпрайзе.
А причем тут энтерпрайз?
К тому что в энтерпрайзе также существует множество ролей, не существующих вне его.

К примеру если делаешь проект один, то ты сам себе все роли сразу, и формальное разделение их теряет смысл, а фундаментальное понимание вещей нужно везде.
Соглашусь.
Перестаньте учить «технологии/платформы/инструменты»
— интересно, как вы будете проходить собесы? Нет, есть работодатели, которым нужна твоя голова целиком, которым интересно, как ты мыслишь. Одному из 20, да. Остальные спрашивают, что ты умеешь на этой технологии?
НЛО прилетело и опубликовало эту надпись здесь
  1. Я очень быстро вырастал до сеньора. Поэтому мидлом быть не успевал, даже когда усраивался вроде как мидлом.
  2. Не понял
  3. Админом нафиг — настроить чтот могу, когда нет на кого свалить, само тестером приходится быть. Но это не то чем нравится заниматься. Поэтому и не призываю, к тому что не люблю сам. Но это немного другое.
НЛО прилетело и опубликовало эту надпись здесь
1. И по факту и по должности. По факту на тебя наваливают как на сеньора, как только понимают, что ты тащишь. А по должности фиксируют, что на тебя можно столько валить, чтоб продолжал тащить.
2. Настолько нет, но в одной конторе был и аналитиком и разработчиком вебприложений и разработчиком низкоуровневых библиотек. Практически не сходя с одного этажа.
3. Тоже верно, но тут совсем другие приёмы и склад ума. Хорошие админы часто отлично программируют, но вот попытки заюзать их в пользовательских приложениях… Мрак и угар, угар и мрак.
Понимаю позицию автора, но не принимаю.

Для меня full stack, это прежде всего увлекательная работа, когда просыпаешься с мыслями о решении сложных задач.
Мне важно понимать большую картину, насколько эффективно решается задача, где мы лажаемся с архитектурой или организацией, как исправить и вписаться в сроки и спецификацию.
По моему опыту, когда каждый работает строго по спецификации, без понимания большой картины, происходят over-engineering и gaps.

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

Если бы я претендовал на истину, писал бы не спорные статьи, а учебники.


Спасибо за мнение.

Любая технология живёт в среднем 5 лет* (*фантазии Автора).

Каждый раз когда я это читаю я слышу как у меня за спиной улыбается начальник SQL-разработки…

Тоже хотел написать про SQL. Как раз имею бекграунд именно в области СУБД. Со временем пришло понимание, что много где могут закрыть глаза на пробелы в знании определенных технологий за вменяемое понимание основы большинства проектов — базу данных.

Согласен, но посмотрите на обрастание БД фичами. Да таблицы и индексы 40 лет не менялись, но когда идёт борьба за производительность, знание новых специфических фич рулит

Там этих фич — одна в пять лет. И то — сомнительная )
Правильно и по канонам построенная архитектура (по канонам 15-летней давности) решает практически все проблемы с производительностью.

Неправильно построенную — костыли из фич надолго не спасут.

Моя любимая поговорка "реальные данные всё испортили". Если проект приносит денежку, то он начинает обрастать всякой фигней. Которая может разрастись и по объёму и по нагрузке. И банальных индексов уже не хватает. Нужно денормализовывать таблицы, плодить обвязку, использовать кэши БД и хитро выраженные индексы последних версий. У меня коллега очередного оракла ждал как маны небесной, поскольку там была какая-то кукарямба, решавшая его проблемы из коробки.


Но в целом да, прямые руки и архитектура без хаков востребована всегда и не только в БД

Ключевое слово в среднем)

у меня мало опыта работы мидлом

сеньором видимо тоже не много
У меня полностью отличается мнение от автора.
Я мультистек-разработчик, работаю в большой компании и занимаюсь 3 хайлоад (~15k rps каждый) проектами. Являюсь одним из важнейших членов команды.

Я считаю, что люди разные, одни любят развиваться и учиться, другие нет.
Те кто не любит развиваться/учиться, обычно всеми силами пытаются это хоть как-то оправдать.

Каждый синглстек — это тот самый чувак на заводе, который так и продолжает крутить свою гайку для Лады (но уже в программировании).
Ну я примерно о том же и писал)
В статье приятные рассуждения.
По мультистековости есть обычная проблема человеческого мышления, человек ищет решения для здесь и сейчас, автор пишет о том, что первым делом ищут того кто решит все проблемы в одну каску. И с этим ни чего не поделать, всегда люди ищут решение которое быстро и полностью, поэтому недооценённость будет хронической, поэтому для бабок надо быть спецом в одной области, а лучше «дуал»-стеком, для разработки по феншую надо быть мультиком.
Фишка то в том что дуалов ищут люди в разработке ни бум бум, и лапшу на уши им можно вешать бесконечно долго, это я к тому что не надо загоняться тем что если ты дуал то ты вечный мидл, работодателю и так сойдёт.
Тоже девелопер 40+, думал в 23 когда начинал что в 40 уже молодые меня заменят, а я останусь без работы, но оказалось что система подоготовки специалистов за это время стала хуже и работы за глаза. Тоже пробовал делать диверсификацию и в дополнение к .net платформе изучил и java. Тоже получаю удовольствие от того как делаю, а не что делаю. Автор прав насчет колеи, попадешь в такой проект и останавливаешься в развитии. Счас взялся за reactjs, очень много работы предлагают.
Система подготовки не лучше и не хуже.
Скорее даже лучше, ибо больше материалов.
Просто у вас 17 лет стажа, а у них — 2. Вспомните себя, посмотрите на ваши решения тех лет(хоть что-то работает еще?)
У меня, например, самая старая развернутая система — 15 лет и там мрак с мой сегодняшней точки зрения.

Очень смущает ваша точка зрения о существовании какого-то сеньорити в рамках конкретной технологии/платформы. Быть сеньором не значит иметь глубокие знания в конкретной технологии. Сеньоры с глубокими знаниями в конкретных технологиях просто встречаются сильно чаще именно потому что они сеньоры (как антропный принцип). Вообще говоря, я уверен что можно быть сеньором не обладая глубокими знаниями ни в одной технологии/платформе, а обладая знаниями в математике CS и культуре работы в цикле ресерч -> продукт.


По самой статье, кажется мне что весь разговор ни о чем. Я имею в виду спор fullstack, singlestack, stack-agnostic и тп. Все эти названия и попытки прикрепить специализации нам (программистам) вроде вообще не нужны. Но они точно нужны работодателям/рекрутерам для экономии. Но поскольку есть спрос, то появляется и предложение — цикл с обратной связью, где программисты начинают развиваться вглубь технологий, поощряя все эти специализации.


Более интересный путь развития о котором я очень мало слышу, но в который верю — это прокачка понимания культуры программирования и решение бизнес-проблем через нее. С логически последовательной культурой программирования можно построить и поддерживать успешный (с точки зрения разработки) продукт в новой для себя области без каких-либо знаний технологий в этой области.

  1. Так и есть. Сеньор человек, который во вменяемые сроки решает сложную задачу самостоятельно. Знать тему глубоко не обязательно, если можно решить простыми приёмами, пусть не оптимально по коду и производительности.


  2. К сожалению, общее понимание бизнес процессов и реализации это тема расплывчатая. Такому не учат потому что это слишком сложно. Когда вы понимаете бизнес процесс, это не значит, что сможете его автоматизировать, поскольку есть ограничения текущей реализации. И каждый раз они свои. И пониманию этих ограничений, и возможностей КОРРЕКТНО их обойти, как раз способствует "работа на земле". У меня бывало, продашь бэкенду идею сделать так чтобы мне хорошо было. Они: да ну, это костыль. А у вас как, вот так? Да! Ну так это у вас костыль, не? Ой!



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

Для начала неплохо знать вообще о существовании бизнес-процессов в принципе и понимания, что многие, если не все, операции принадлежать одному или нескольким. А то налепят CRUD интерфейсов и "вот все данные учтены — что хотите с ними, то и делайте".

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