Comments 53

Вообще-то design — это больше про проектирование, а не про внешний вид и то, что под дизайном подразумевается у нас. Читая статью — так и не поняла, какой смысл в это слово вкладывает автор.

Я тоже задумывался, не про проектирование ли это, но по контексту всё-таки получается, что речь о графическом дизайне. Например, в комментах там уверенно пишут про visual design и University of the Arts. Спасибо, добавил в пост уточнение, стоило сразу его сделать.

а у меня сложилось впечатление, что графическая-визуальная часть входит в markup and styling :-/

Сейчас всмотрелся, что когда Рэнди в посте приводит первый пример «фуллстека», он пишет «he did all of the user interface design» — то есть говорит, что вот вам разработчик, умеющий в design, и контекст у этого UI-ный.

в итоге это и есть проектирование. иначе он бы, наверное, или прямо написал graphic design или не указывал отдельно про markup & styling

Мне кажется, что в далеком 2008м все было куда проще.
Фулстеком называли человека, который мог и в фотошопе щаблон задизайнить, и потом сверстать его с html+css (да, была отдельная профа — верстальщик, который брал хаотичный psd от дизайнера и пытался все перделки перевести в «тогдашний» веб 2.0), а потом еще и запилить какой либо небольшой движек на простеньком js+php+mysql.
конечно. в тех местах, где я в то время (и чуть раньше) работал это и называлось фуллстэк.
О растяжимости понятия
ещё знавал людей, которых называли фуллстэками за то, что они могли и винду админить, и фряху, а заодно и кабели обжать и по объекту всё как надо протянуть, а потом принтеры и компьютеры отвезти в ремонт :) А один даже фуллстэком назывался за C++/Delphi/FoxBase (или как оно там тогда называлось) :)))
Типичный случай — Java-разработчик посещает конференции не только по Java, но и по тестированию или DevOps. А ещё может посмотреть видеозапись доклада про GraphQL с JS-конференции или про архитектуру с .NET-мероприятия.
Этот человек не занимается фронтендом, но лезет сразу в разные стороны, чтобы лучше понимать всё вокруг, расширять доступный скоуп задач и находить общий язык с окружающими (тестировщиками, фронтендерами, инфраструктурщиками).

Вот это и удручает в сложившейся ситуации. Разработчик смотрит по сторонам, чтобы лучше понимать обстоятельства своей работы. Но не тестировщик/инфраструктурщик/фронтендер ищет пути избежать копипасты или просто именовать константы явно.
Получается некий тренд — назвался груздем, полезай в короб. Тестировщик — никто от тебя не ждет элегантный код на Питоне для автоматизированного тестирования. Разработчик — ну ты там тестерам помоги автоматизацию написать.

На текущей работе на интервью задали вопрос: «Как ты понимаешь, кто такой full stack developer?» — В процессе обсуждения решили, что это разработчик, имеющий знания и опыт в front-end, back-end, database и devops. Вот так вот, специалист, разбирающийся в 4 сферах. Не мастер во всех 4-х, прошу заметить, а имеющий понимание обо всех 4 сферах. Такой разработчик дизайнит полные решения — от пользователя до сервера и обратно (речь о веб-приложениях).
Мне кажется, что database в подавляющем большинстве случаев, это часть back-end. А devops, да базовые вещи и принципы, конечно знать надо, но если речь о хардкоре, это отдельная специальность. ИМХО.

Тут больше не про "знать", а про уметь развернуть, настроить.

Хранение и обработка данных — это все-таки отдельная область, возьмите тот же data science или какие-то сложные системы с очередями, events и подписками и/или иерархической структурой вроде in-memory-disk-archive.

Я встречался со случаями, где к этим 4 добавляли разработку под смарты

Было интересно почитать статью
Я новенький на хабре и как раз учусь на верстальщика (фронтенд в будущем)
Все современный словечки стыреные у Омериканцов, такие как full stack, devops, agile, scrum и др. — это просто, что то, во что можно вложить любой смысл какой захочешь, все они размазаны и вообще не представляю какого то здравого смысла. Очень раздражает, когда какому то естественному процессу, который существует уже сотни лет, и протекает по разному в разных областях, вдруг решают дать какое то название при этом не имея ни какого четкого определения, потому что это в принципе не возможно, и потом русские носятся с этими словечками как с писаной торбой и пишут миллионы статей, которые только отнимают время у людей их читающих, и еще больше их запутывающих. Где то IT свернул не туда и теперь в мире IT вообще нет четких понятий и определений, просто лепи с говна и палок и будешь называть креативным-фулл-стек-дезигнером, главное ловечек забугорных побольше и штаны подвернуть — все, теперь ты топ (то же Англицкое словечко, замены которому нет в русском языке) в IT.
Понимаю ваши ощущения, и согласен, что бывает злоупотребление таким, но согласиться с комментарием в целом не получается.

«Теперь в мире IT вообще нет четких понятий и определений»
Да куда ж они делись, слово «компилятор» как было, так и есть. Предыдущий пост в нашем блоге озаглавлен «Уязвимости в реализации межпроцессного взаимодействия в Android-приложениях» — по-моему, и «уязвимость», и «межпроцессное взаимодействие», и «Android-приложения» довольно конкретные понятия.

«Какому-то естественному процессу, который существует уже сотни лет, решают дать название, не имея никакого четкого определения, потому что это в принципе невозможно»
Тут какая штука: если естественный процесс существует уже сотни лет, вероятно, это довольно значимый процесс. А значит, может быть необходимо учитывать его в работе и обсуждать в рабочих диалогах. А для этого нужны какие-то слова, даже если абсолютно чёткие невозможны и приходится использовать какие есть.

И не знаю, чем для вас провинились «омериканцы», но хочу отметить, что слово «scrum» в IT-мир принесли японцы, а слово «devops» — бельгиец. Вот более конкретное «compiler» — американское, да.
А для этого нужны какие-то слова,

а можно имеющееся назвать новыми словами, скажем платформа и конфигурация и уже можно окормлять выделенную паству.

Насчёт компиляторов на 100% не уверен, то вот многие популярные интерпретаторы весьма далеки от классических. Тут и промежуточная компиляция в байт-код, и компиляция этого байт-кода в машинный в процессе его интерпретации ака JIT.

Согласен, что в «чётких» терминах тоже есть некоторая степень свободы — пограничные случаи, изменение значения со временем и так далее.

Но если подходить настолько строго, то получится не «теперь в мире IT нет чётких понятий», а «в мире IT никогда и не было чётких понятий» :) Прямо с того момента, как впервые было использовано слово «баг», можно было спорить о том, где заканчивается баг и начинается фича.

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


Поэтому в оригинальном варианте «full stack» —было вопросом отчасти дарования, ну вот как full stack поэт: автор стихов, если захочет, может стать бардом — но тогда, и только тогда, когда ему по рождению достался музыкальный слух. А в нынешнем понимании — «full stack» — это вопрос исключительно желания. Мне просто не нравится, например, javascript — ну вот я и избегаю всего, что с ним связано. Но когда потребовались расширения для браузера, которых не было — ну, сел, да написал, чего уж там. С дизайном так не прокатит.


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

Говорят, что музыкальный слух можно развивать. Если это правда, то и приемлимую иконку можно, наверное, научиться рисовать, если несколько (ближе к 10 чем к 1) лет тратить по часу в день на это под руководством опытного учителя.

Это так, говорю, как человек, развивший и музыкальный слух, и навык рисования иконок :)


Но все равно предел — это вот что-то типа такого:


Agency — для библиотеки Agency


или


Telemetria — для Telemetria


или


Tempus — для Tempus


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

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

Ну если я предпочитаю писать на C#, мне кажется вполне логичным указывать в резюме, что я C# Developer — при чем тут "приговор", если я этот язык по собственному желанию выбрал? Или вы имеете в виду "должно быть делом предпочтений работодателя"?

Скорее "должно быть делом договоренностей работника с работодателем".

Мне кажется логичным в резюме писать так:


— разработчик
люблю: C#
— могу: Rust, F#
могу, но не буду: C++, Java, Go, Haskell


У меня (когда у меня было резюме) — именно так и было написано (только языков побольше).


В любом случае, позиция обычно обозначает список услуг, которые компания норовит получить от разработчика.

Я стараюсь быть максимально конкретным, чтобы не приходилось продираться через горы мусора в ответах. Сейчас у меня вообще написано "Backend C# Developer", а прилетает и фуллстек, и джава, и бог весть еще что — чего даже в списке "могу, но не буду" нет.

Ну, то есть ваша конкретность вам помогает не особо :)


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


У меня закрыта страница в Linkedin; во всех местах, где можно наткнуться на мое существование ажурным капслоком набрано «я не ищу работу, и отправляю рекрутеров в бан немедленно». И да, особо инициативные просачиваются и зовут на позицию «Java Junior» в США (хотя про мое отношение к США в целом написано там же, в еще более обсценной форме).


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

А может вам пора уже уйти с вашей работы и начать учить людей в реальном мире, а не в комментах на хабре?

И не пишите мне что я указываю вам что вам делать. Я просто со стороны советую. Со стороны, как известно, виднее.
Не важно как понимают fullstack программисты. Важно как fullstack понимает бизнес.
А для бизнеса fullstack == тыж программист.
<:o)
Зависит от размера задач. Если нужны несложные веб приложения, то и один сможет с ними разобраться.

Да на чём сэкономить-то? Если нужно для фичи 100 часов фронта и 100 часов бэка, то сэкономить с фуллстэком получится хорошо если процентов 15-20 суммарного времени при одинаковой квалификации за счёт отсутствия потерь на коммуникации. Но в деньгах эти проценты аннулируются, скорее всего, более высоким рейтом, а фича будет готова через 160 часов, а не через 100.

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

С одной стороны, куча примеров когда не заставляло: подошёл фронт к бэку, обсудили вдвоём и родили какой-то API по фиче с понятной только им двоим логикой.


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

Проблема в таком походе на мой взгляд в том, что специализируясь на, например, бэкенде со временем перестаёшь понимать современные фронтенд технологии, их проблемы и ограничения. Вот банальный Реакт 2015-го года и 2020-го года — две большие разницы. Да даже 2018-го и 2020-го.

«Full stack» — это значит, что при приёме на работу тебе дадут на 10-15% большую зарплату, чем у просто фронта или просто бека, но зато потом всю свою карьеру в этой компании ты будешь обязан решать ЛЮБЫЕ задачи на любых языках, базах данных, операционках, задачи программера, дизайнера, девопса, тестировщика, менеджера. Ну потому что ты же фуллстек, значит можешь всё, да тебе и платят за это больше!
Я ни разу не программист, но возник вопрос: А бывает ли Full Stack в отрыве от веба? Есть же всякие программисты на C++ или там эмбеддед или прастихоспади 1С. У них может быть Full Stack или нет?

Вполне может быть там, где клиент-северная архитектура, особенно с GUI клиентами. Пускай один и тот же стэк (C++ например), но одни могут специализироваться на сервере, другие на клиентах, а третьи и то, и другое писать.


Насчёт конкретно 1С не уверен, есть ли там заметная специфика разделения.

Конкретно для 1С — там программист был всегда фулл стеком. И за главного бухгалтера закрытие бухгалтерского месяца выполнял, исправляя все накопившиеся косяки бухгалтеров. И у пользователей хотелки выпытывал, что же тебе всё-таки нужно. И ТЗ писал, хотя обычно не писал, а на пальцах. И интерфейсы пользователей проектировал, иногда даже учитывая юзабельность, переходы фокуса и хоткеи, а теперь и с учетом работы в вебе. И код пректировал и писал, теперь раздельный для клиента и сервера. И базы данных окучивал, на своем наречии SQL, а теперь эти запросы стали на несколько сотен строк, с временными таблицами, вложенными запросами и соединением, да ещё с динамической сборкой в рунтайме. И тестирование делал, ручное без тестирующего кода. И профайлинг делал, определяя тормозные места в коде. И на рабочую базу новые релизы накатывал, теперь динамически без выброса пользователей — глючащее. И сервера готовил, от железа, до настроек ПО, потому как админы не разбираются в этом «вашем 1С». И в принтеры картриджи менял, потому как «тыж программист».
Десктоп — человек, могущий написать еще и бэкенд к своей аппликации. Эмбеддед — тоже бывает, во-первых — очень часто драйверы к железяке пишут те же люди, что и firmware, во вторых — сейчас у многих железяк есть UI.

Иногда задумываюсь о том, чтобы пойти на курсы UI/UX дизайна, чтобы закрыть весь стэк компетенций, нужных для создания типичного веб-приложения. Потом вспоминаю, что сюда уже и мобайл суют, и СКЗИ и вообще безопасность надо подтянуть. Сети опять же (BGP что такое, стыдно признаться, не знаю, AS какие-то ещё). Хотя бы пару облаков, Amazon и Google надо освоить нормально. Terraform какой-то. Навыки продаж, в прямом и переносном смысле, технических и организационных решений отточить. И английский хотя бы до Upper intermediate подтянуть. И Макось освоить хоть немного, чтобы больше не позориться, на собесах и посмотреть куда винда ушла со времён XP. И курсы по руководству… И Кнута дочитать… И DDD, который DataDrivenDesign И BigData c ML. NoSQL, хотя бы монгу…


И возвращаюсь в свою уютную зону комфорта из, навскидку:
Linux + простыни Ansible для разворачивания
Docker (+ k8s когда bash+docker-compose/swarm не хватает)
БД (MySQL, Postgresql)
Сервера (PHP, JS/TS), монолит и выделяемые микросервисы
Веб-клиенты (Html, немного CSS, ванильный JS/TS или React+MobX)
CI/CD пайплайнов
Selenium или pupiter для тестов
Руководство небольшой командой


Возвращаюсь с мыслями, что создать от А до Я современный проект я уже не смогу, и последние лет 10 я 100% самозванец, когда пишу в резюме Full Stack Web Developer. Но только так могу претендовать на вакансии, где востребована хотя бы половина моих навыков. Правда вот ещё с некоторыми вакансиями DevOps инженеров, чтобы это не значило, пересекается сильно.

Ну по приведенному списку скиллов создается впечатление, что вы именно девопс, а не разработчик — видимо, из-за линукса и докера на первых позициях.

собственно, full ты stack или не full зависит от самого́ стэка — какие технологии использует или хочет/готов использовать наниматель. Вот надо ему сайты делать, чтоб блэкджек и мадамы были — один стэк. Надо какие-то сервисы с аналитикой и автоматикой — другой стэк. ятакщетаю.

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

вот удивительно, всегда считал, что это чел, который напишет сайт сам с нуля, а прочел статью и мало того что не убедился в этом, а только стал более в себе не уверен. хорошо что я не фулстэк, а стэковэрфлоу!
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

25 March 2012

Location

Россия

Website

jugru.org

Employees

51–100 employees

Registered

22 August 2013

Habr blog