Comments 57
Учить на мой взгляд нужно фундаментальные вещи, такие как: Архитектура Современных Компьютеров, Операционные Системы, Сети, Базы данных, Принципы построения языков программирования, Архитектуру ПО, Системный анализ, etc…
Имея фундаментальные знания во всех этих областях, прийдет понимание того какие проблемы решает та или иная технология/платформа и каким образом она это делает.
С этим пониманием с одной технологии/платформы/стека на другую при надобности вы сможете перескочить в промежутке 1-ого года.
К тому же в таком случае не будет подобного рода проблемм:
А во-вторых (и это главное), я не хочу знать, что такое ДэТэО, где оно лежит и как с ним работать. Мне нужен только путь, метод, параметры и набор ответа. В терминах HTTP/REST.Потому что и DTO и REST и HTTP — термины вне технологий вне фронтэнда/бэкэнда, вне языков программирования.
Я как раз не предлагаю учить, а скорее попробовать. По срокам согласен. У меня примерно через полгода происходит понимание, что я вышел на сеньорский уровень, а через год приходит понимание, что полгода назад сеньор я был хреновый.
Иногда раньше иногда позже. Все зависит от того, есть ли в текущей команде хорошие практики или надо до них доходить самому.
Плюс разные роли скажем аналитик и программист, но могут быть два в одном )
Ну фронт и бэк есть и у десктопных клиентов
Настолько разные, что «десктопный фронт» и «десктопный бэк» стали «типа разными» профессиями?
Всё зависит от величины проекта, а больших проектах есть разделение по функциям разработки. И грязными лапами в бд не всем дозволяется ковыряться)
К слову, что такое «бэк десктопного клиента»?
Мне кажется, вы опять пытаетесь свести вопрос к очень ограниченному подмножеству проектов и отвечаете в рамках этого подмножества. Я же как раз говорю, что не надо так делать.
Например, я работаю в десктопном проект на ~20кк строк (достаточно большой?) и у нас нет базы данных (реляционной во всяком случае).
Если в вашем проекте нет разделения ролей это не значит, что во всех проектах так. Вот взять граф редактор, кто-то делает ui, кто-то работой с файлами разных форматов, кто-то с плагинами для обработки картинки. И все являются крутыми, но узкими специалистами. Фронт бэк — это всего лишь роли, они могут быть и называться как угодно. В проекте также все могут быть универсалами, но это зависит и от проекта и от людей
UPD Я повторю вопрос — все эти роли настолько разные и требуют настолько разного набора знаний, что вырождаются в отдельные профессии, как это происходит в вебе, и требуют написания таких статей?
Вы критикуете термины бэк и фронт, но это просто хороший пример разных стеков.
Причем тут вообще энтерпрайз и машинное обучение если вы же говорите о стеках?
1) Десктоп-клиент держит в себе встроенный веб-сервер, к которому подключаются браузером саб-клиенты для специальных задач.
2) Да собственно апп-сервер и есть бэк декстопа в multitier, нормальная практика, хоть и устаревшая по нынешним временам.
2) Бэкенд в multitier — это просто бэкенд.
2) Ну так он же бэк для десктоп-клиента, или нет? По роли он практически совпадает с бэком для веба, если на то пошло, только протоколы разные. У меня в практике были даже апп-сервера с подключаемыми логическими модулями на жабаскрипте (wss, самодельные расширения для vb и js) — прям ноджысы какой-то.
И, возвращаясь к контексту, программисты для бэк- и фронт-частей в тех проектах были сильно разные как по скиллам, так и по используемому инструментарию (например, Delphi vs C++).
А теперь смотрим на исходное сообщения, к которому я привязался с целью выяснить что же все таки понимает под фронтендом и бэкендом автор статьи:
Ну фронт и бэк есть и у десктопных клиентов
У меня возникло ощущение, что автор под словом «бэкенд» понимает совсем не то что я или вы, я пытаюсь выяснить что именно.
UPD Ну и да, исходная мысль была в том, что программирование не ограничивается клиент-серверными архитектурами, где есть выделенные фронтенд и бэкенд.
И, возвращаясь к контексту, программисты для бэк- и фронт-частей в тех проектах были сильно разные как по скиллам, так и по используемому инструментарию (например, Delphi vs C++).
Эта разница обусловлена фундаментальными различиями в программировании фронтенда и бэкенда или просто выбором технологии для их реализации?
У меня возникло ощущение, что автор под словом «бэкенд» понимает совсем не то что я или вы, я пытаюсь выяснить что именно.
Да чёрт его знает, у меня уже ощущение, что мы все говорим об одном и том же, но спотыкаемся на терминологии.
Эта разница обусловлена фундаментальными различиями в программировании фронтенда и бэкенда или просто выбором технологии для их реализации?
Скорее первое, чем второе. Дельфя для формочек, Ся для .dll и .so. Совсем разные задачи и подходы (не то, чтобы совсем-совсем нельзя было всё сделать на чём-то одном, но это был бы явный изврат ради изврата, а когда апп-сервер на другой ОС, то и вообще. Хотя — и такое я встречал).
Не очень понимаю, что вам мешает на C++ рисовать формочки, а на Delphi писать dll. И даже класть формочки в dll. И что тут извратного и принципиально разного?
А про класть формочки в dll — лучше не напоминайте, это была одна из моих тем в то время, плагинные системы и динамически подгружаемые формы. Ох, сколько она крови выпила…
И таки таки формошлёпство на дельфи требовало совсем одного тулчейна и набора умений, а разработка слоёв апп-логики и бизнес-логики сильно другого. Даже людей нанимали совсем разных, ровно как во фронте/бэке сейчас.
А, да, пока вспомнил: по моему мнению в нормальном современном энтерпрайз-вебе настоящий фулл таки очень редкая зверюшка. Потому что ну очень накладно знать, например, ангуляр 7 в обвязке (не на уровне туториалов, а понимая, что там внутре за неонка в деталях) и, скажем, цэшарп с дотнетом так же глубоко — и поддерживать эти знания актуальными сколь-нибудь длительный период.
Не накладно, если разбираться в фундаменталке, которая под всем этим лежит. Собственно, мы тут вернулись к самому первому комментарию в этой ветке.
Думаю, что такие люди, которые твёрдо знают теорию и при этом так же твёрдо _нюансы_ практики, существуют, но я лично с такими не сталкивался. В смысле — сразу в нескольких областях, в узких темах специалистов много. Это ж ещё надо иметь довольно разный склад характера.
Сам я клонюсь то в теорию, то в практику в зависимости от того, что мне сейчас интереснее (повезло, могу себе позволить) и в результате не знаю ни того, ни другого, а мне за это платят =)
Мне кажется, что вы сильно преувеличиваете сложность освоения фундаменталки. Но дальше сложно спорить, для этого нужно синхронизировать знания и представления о разработке.
Проблема не в фундаменте проблема в деталях. Человек в фундаменталкой сделает все хорошо, человек с наработанностью ещё и быстро. Плюс чтение кода. Есть общепринятые идиомы и лайв хаки. Погруженный спец их читает влет. У меня 7 лет программирования на перл. Но меня $ и @ бьют по глазам после перерыва. Неделя погружения. И они лучшие друзья
Если клиент построен на принципах близких к MVC, то M — бэк
Ага, у меня в голове что то такое крутилось, но сформулировать не смог)
Но диалог пошел по другой ветке.
— интересно, как вы будете проходить собесы? Нет, есть работодатели, которым нужна твоя голова целиком, которым интересно, как ты мыслишь. Одному из 20, да. Остальные спрашивают, что ты умеешь на этой технологии?
- Я очень быстро вырастал до сеньора. Поэтому мидлом быть не успевал, даже когда усраивался вроде как мидлом.
- Не понял
- Админом нафиг — настроить чтот могу, когда нет на кого свалить, само тестером приходится быть. Но это не то чем нравится заниматься. Поэтому и не призываю, к тому что не люблю сам. Но это немного другое.
2. Настолько нет, но в одной конторе был и аналитиком и разработчиком вебприложений и разработчиком низкоуровневых библиотек. Практически не сходя с одного этажа.
3. Тоже верно, но тут совсем другие приёмы и склад ума. Хорошие админы часто отлично программируют, но вот попытки заюзать их в пользовательских приложениях… Мрак и угар, угар и мрак.
Для меня full stack, это прежде всего увлекательная работа, когда просыпаешься с мыслями о решении сложных задач.
Мне важно понимать большую картину, насколько эффективно решается задача, где мы лажаемся с архитектурой или организацией, как исправить и вписаться в сроки и спецификацию.
По моему опыту, когда каждый работает строго по спецификации, без понимания большой картины, происходят over-engineering и gaps.
Почти 50, но аналогичный настрой был и в 24, когда окунулся в первый коммерческий проект — я должен видеть большую картину и знать, что команда решает задачу максимально эффективно. Иначе мне не интересна работа, где я, возможно, просто обмениваю жизнь за деньги.
Любая технология живёт в среднем 5 лет* (*фантазии Автора).
Каждый раз когда я это читаю я слышу как у меня за спиной улыбается начальник SQL-разработки…
Тоже хотел написать про SQL. Как раз имею бекграунд именно в области СУБД. Со временем пришло понимание, что много где могут закрыть глаза на пробелы в знании определенных технологий за вменяемое понимание основы большинства проектов — базу данных.
Согласен, но посмотрите на обрастание БД фичами. Да таблицы и индексы 40 лет не менялись, но когда идёт борьба за производительность, знание новых специфических фич рулит
Правильно и по канонам построенная архитектура (по канонам 15-летней давности) решает практически все проблемы с производительностью.
Неправильно построенную — костыли из фич надолго не спасут.
Моя любимая поговорка "реальные данные всё испортили". Если проект приносит денежку, то он начинает обрастать всякой фигней. Которая может разрастись и по объёму и по нагрузке. И банальных индексов уже не хватает. Нужно денормализовывать таблицы, плодить обвязку, использовать кэши БД и хитро выраженные индексы последних версий. У меня коллега очередного оракла ждал как маны небесной, поскольку там была какая-то кукарямба, решавшая его проблемы из коробки.
Но в целом да, прямые руки и архитектура без хаков востребована всегда и не только в БД
Ключевое слово в среднем)
у меня мало опыта работы мидлом
сеньором видимо тоже не много
Я мультистек-разработчик, работаю в большой компании и занимаюсь 3 хайлоад (~15k rps каждый) проектами. Являюсь одним из важнейших членов команды.
Я считаю, что люди разные, одни любят развиваться и учиться, другие нет.
Те кто не любит развиваться/учиться, обычно всеми силами пытаются это хоть как-то оправдать.
Каждый синглстек — это тот самый чувак на заводе, который так и продолжает крутить свою гайку для Лады (но уже в программировании).
По мультистековости есть обычная проблема человеческого мышления, человек ищет решения для здесь и сейчас, автор пишет о том, что первым делом ищут того кто решит все проблемы в одну каску. И с этим ни чего не поделать, всегда люди ищут решение которое быстро и полностью, поэтому недооценённость будет хронической, поэтому для бабок надо быть спецом в одной области, а лучше «дуал»-стеком, для разработки по феншую надо быть мультиком.
Фишка то в том что дуалов ищут люди в разработке ни бум бум, и лапшу на уши им можно вешать бесконечно долго, это я к тому что не надо загоняться тем что если ты дуал то ты вечный мидл, работодателю и так сойдёт.
Скорее даже лучше, ибо больше материалов.
Просто у вас 17 лет стажа, а у них — 2. Вспомните себя, посмотрите на ваши решения тех лет(хоть что-то работает еще?)
У меня, например, самая старая развернутая система — 15 лет и там мрак с мой сегодняшней точки зрения.
Очень смущает ваша точка зрения о существовании какого-то сеньорити в рамках конкретной технологии/платформы. Быть сеньором не значит иметь глубокие знания в конкретной технологии. Сеньоры с глубокими знаниями в конкретных технологиях просто встречаются сильно чаще именно потому что они сеньоры (как антропный принцип). Вообще говоря, я уверен что можно быть сеньором не обладая глубокими знаниями ни в одной технологии/платформе, а обладая знаниями в математике CS и культуре работы в цикле ресерч -> продукт.
По самой статье, кажется мне что весь разговор ни о чем. Я имею в виду спор fullstack, singlestack, stack-agnostic и тп. Все эти названия и попытки прикрепить специализации нам (программистам) вроде вообще не нужны. Но они точно нужны работодателям/рекрутерам для экономии. Но поскольку есть спрос, то появляется и предложение — цикл с обратной связью, где программисты начинают развиваться вглубь технологий, поощряя все эти специализации.
Более интересный путь развития о котором я очень мало слышу, но в который верю — это прокачка понимания культуры программирования и решение бизнес-проблем через нее. С логически последовательной культурой программирования можно построить и поддерживать успешный (с точки зрения разработки) продукт в новой для себя области без каких-либо знаний технологий в этой области.
Так и есть. Сеньор человек, который во вменяемые сроки решает сложную задачу самостоятельно. Знать тему глубоко не обязательно, если можно решить простыми приёмами, пусть не оптимально по коду и производительности.
К сожалению, общее понимание бизнес процессов и реализации это тема расплывчатая. Такому не учат потому что это слишком сложно. Когда вы понимаете бизнес процесс, это не значит, что сможете его автоматизировать, поскольку есть ограничения текущей реализации. И каждый раз они свои. И пониманию этих ограничений, и возможностей КОРРЕКТНО их обойти, как раз способствует "работа на земле". У меня бывало, продашь бэкенду идею сделать так чтобы мне хорошо было. Они: да ну, это костыль. А у вас как, вот так? Да! Ну так это у вас костыль, не? Ой!
Не бывает идеальных систем, по крайней мере, идеальных систем в которых можно быстро реализовать разные задачи. Вся соль в ограничениях
Быть фулстеком и не быть им