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

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

Выступления Антона всегда интересны и зажигательны.
Кекс - торт!!!

Таллина: это самый хорошо сохранившийся средневековый город в Европе, а также европейская IT-столица. Все технологии Евросоюза берутся из Эстонии.

Эээ, что ?!!! :)

Этто шютка.

Крутая статья. Для меня очень даже жизненная. Только не хватает того, что называется "критической массой талантов" (кажется, так в Нетфликсе пропагандируют), т.е. если в группе не наберется n-ное количество профессионалов своего дела, стремящихся к развитию, то группа скатится к стагнации: один суперразраб (без сверхусилий) не потянет двенадцать джунов за собой и либо оставит все как есть либо вообще уйдет туда, где способных людей больше. И под джунами я имею ввиду общую сумму и "hard skills", и "soft skills". И будет все в таком коллективе "как принято".

10 лет прошло, а Кекс всё о том же поёт.

Как фуллстек разработчик, вы будете более прагматичны

Я бы сказал иначе, как фуллстек разработчик вы будете неизбежно отставать от современных трендов. Просто потому, что очень много информации нужно знать и обновлять. И знания эти сильно разнообразные. Например, знания по индексам и планам запросов на БД и умение адаптивно верстать требуют от разработчика квадратной головы.

И есть высокая вероятность, что такой разработчик будет супер прагматичен. Он скажет: а нафига мне выкидывать jQuery? Он работает? Работает. Задачу решает? Ну, вроде, решает. А потом разработчик может, например, уволится... Или превратится в того самого архитектора из статьи, который вроде знает и фронт и бэк, но примерно 5 летней давности.

Но, правда, зачем выкидывать jQuery, если она работает и задачу решает?

Под выкидыванием я имел в виду тащить в новый проект. Т.е. работал такой крафтсмен над каким-то проектом, где был jQuery. Проект старый, но все работает и всех удовлетворяет. И вот тут конечно же не надо ничего выкидывать (хотя иногда быстрее будет переписать и двигаться дальше).

А потом начинается новый проект и разработчик просто на автомате берет тот же jQuery и тащит его в новый проект - я вот про это. В принципе, это тоже нормально, но до тех пор когда такой разработчик не уйдет. Потом будет сложно найти тех, кто будет готов дальше разрабатывать решение на jQuery.

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

jQuery создавался когда в разных браузерах было сильно разное апи, чтобы можно было писать одинаковый код. Последние лет 10 это неактуально, все то же самое можно делать по спекам, так что и jQuery не нужен

А что за последние 5 лет появилось на фронте или беке такого, чего этот архитектор не поймет за 1 день?

Я бы не назвал индексы и адаптивную верстку современными трендами

Так и я это трендами не называл. Почитайте внимательно. Первое это тренды, второе это разнонаправленность информации, которую надо изучить. И вот второе это как раз индексы и верстка просто как пример. Другим примером может быть оптимизация производительности сервера или CI для докер контейнера и мобильная разработка. Думаю, мысль понятна.

Последние лет 10 это неактуально, все то же самое можно делать по спекам, так что и jQuery не нужен

Вот, а фуллстек разработчик из статьи может этого и не знать (просто не следил какое-то время) и продолжает использовать jQuery.

А что за последние 5 лет появилось на фронте или беке такого, чего этот архитектор не поймет за 1 день?

Странный вопрос. Понимания мало, надо постоянно работать с инструментом. И на бэке и на фронте куча разных нюансов. Вот, например, откуда архитектору знать, что jQuery можно выкинуть и использовать нативный api браузера?

Сейчас ваша мысль стала понятнее, спасибо. Согласен, что знать нужно много (но, все-таки в некоторых пределах, фронт и бек - да, а вот БД, девопс, мобильную разработку и микроконтроллеры уже по желанию и поверхностно). Не согласен, что придется неизбежно отставать от современных трендов: действительно чего-то нового появляется редко, обычно это переосмысление каких-то старых идей в новой обертке. 5 минут на сайт библиотеки, 5 минут на github и уже есть понимание, зачем это, как использовать и где это уже было. Если действительно классное, то можно попробовать в домашнем проекте, но это уже редкость. Но повторю вопрос, какой из инструментов появился за последние 5 лет, незнание которого можно поставить фуллстеку в укор, какой может быть критерий отставания от современных трендов?

Из Вашего комментария складывается впечатление, что фуллстеки - это какие-то невероятные монстры с зашкаливающим IQ, книжные черви. Боюсь, что от популяризации такой идеи, фуллстеков будет становиться только меньше(

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

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

Из Вашего комментария складывается впечатление, что фуллстеки - это какие-то невероятные монстры с зашкаливающим IQ, книжные черви. Боюсь, что от популяризации такой идеи, фуллстеков будет становиться только меньше(

И прекрасно, если будет меньше. Очень хорошая аналогия с врачами. Представьте что останутся одни терапевты. Вы бы хотели лечиться у таких врачей? Простуду можно, а что-то серьезное я бы не хотел. А казалось бы, неужели окулист не разберется с желудком?

А потом окулист отправляет к неврологу, невролог к специалисту по сосудам, потом проверяют гормоны и т.д. Доктор хаус тоже иногда нужен.

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

Очень хорошая аналогия с врачами.

Отвратительная, как и большинство аналогий, которые используются в аргументации. Все врачи, даже самые узкоспециализированные, получают в университете широчайшую квалификацию. То, что они практикуют узкую специализацию, обусловлено высокой ценой ошибки. К чему эта аналогия вообще? Что общего между врачами и разработчиками, что вы захотели их сюда приплести? Врачи исправляют проблемы в сложных, не до конца изученных системах с высокой ценой ошибки. Разработчики разрабатывают системы, в контексте статьи делают это с нуля.

Все врачи, даже самые узкоспециализированные, получают в университете широчайшую квалификацию

А вы думаете бэкендеры не имеют понятия как работает браузер что ли? Тоже есть общее представление. Но в этом и проблема, что оно "общее". Для каких-то проектов этого будет достаточно, а для каких-то нет.

Врачи исправляют проблемы в сложных, не до конца изученных системах с высокой ценой ошибки. Разработчики разрабатывают системы, в контексте статьи делают это с нуля.

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

Чтобы поспевать за трендами, не нужно закапываться в технологию с головой. Ваш пример с jQuery топит вас самого же. Даже далекие от фронта и даже от разработки люди в ит, которые хоть раз в тысячу лет открывают сайты типа хабра, в курсе, что jQuery не используется в современной разработке, и им даже не обязательно знать, по какой причине. Для того, чтобы не отставать от трендов, не нужно быть погруженным в одну область с головой. Достаточно пару раз в неделю открывать ленту профильного сообщества, поглядывать в комментарии и участвовать время от времени в каких-то обсуждениях. Концентрироваться на какой-то одной области нужно не для того, чтобы поспевать за трендами, а для того, чтобы эти тренды задавать.
Что касается "супер прагматичности" (хотя к прагматичности это не имеет никакого отношения). Я тоже могу придумать таких примеров, когда узкоспециализированный фронтэндер с десятилетним стажем предпочтет писать на jQuery, потому что у него релевантного опыта много. Это черта характера конкретного человека. Я пока что куда больше встречал людей с большим опытом и узкой специализацией, которые отставали от трендов, нежели тех, кто постоянно пробует что-то новое.

Пример с jQuery конечно же гиперболизированный. Просто чтобы многим было понятно направление мысли. В реальности все конечно же потоньше и не настолько очевидно. Например, какую версию postgres взять для проекта, должен ли бэк быть реактивным и нужно ли использовать федерализацию на фронте, где и как лучше разворачивать сервер и т.д. И тут просто чтение хабра не поможет, нужно все это "щупать". А на это все нужно время. И этого времени зачастую не хватает на всю область фуллстека. Конечно, есть люди у которых все это получается, но они и стоить могут как два узкоспециализированных разработчика.

Любопытное чтиво, я вот тоже люблю нанимать фулстеков, как по приведенным в статье причинам + на старте они просят меньше чем стоят, потому что себя как правило недооценивают.

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

И, конечно, есть еще те, кто до сих пор программирует на C, на С++, тоже абсолютно отдельный мир

на плюсах в основном пишут такой же бекенд как и на джаве, только быстрее. Не вижу "абсолютно отдельного мира"

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

офтальмолог, терапевт, невропатолог... Потому что один человек просто не способен выучить как работает всё человеческое тело и уметь его всё лечить.

На помощь приходит возвращение к старому-доброму фуллстек разработчику. Раньше все разработчики такими и были. Это мастер на все руки:

проблема в том, что один разработчик не может знать несколько стеков так же хорошо, как несколько более специализированных разработчиков. Получается, что толпа фуллстеков имеет офигенный bus factor, но в размен пострадает качество кода. И не надо про overengineering - он бывает как от "избыточного", так и от недостаточного владения языком/фреймворком.

Давайте подумаем: кто из вас знает, как написать полностью с нуля свой текущий проект? А если мы еще включим сюда сторителлинг, то есть сбор требований? Вы смогли бы целиком всё это сами сделать? 

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

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

Представляете, терапевт - он как фуллстек. Знает всё. Что не знает - к профильному врачу. Если тот не может помочь - в больницу. Если больница простая не может - в спец. госпиталь.

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

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

>Вообще для меня программирование — это уже давно постоянная коммуникация

Половину qsort изобрёл один напарник, а вторую другой, про это речь? В 15м веке было парное рисование картин. Только работало оно гораздо разумнее. Подмастерья рисовали неважные куски по эскизам мастера. И несложно увидеть, что это ускоряет дело. А как дело ускорит обмен данными со скоростью пару килобайт в минуту и кучей ошибок в канале непонятно совершенно.

Все это хорошо если только не одно но: наниматели ищут по стэку. И им не видно что такой full stack может все - и в VoIP и в Web и в IoT. Им нужен тот кто умеет или одно или другое.

Спасибо за интересное видео. Полностью согласен.

Для нормальной работы качественных разработчиков нужна соответствующая среда. Поэтому качественные разработчики либо её находят (что редкость), либо тихо вымирают (встречается чаще).

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

Хотя скорость освоения моды у таких разработчиков сильно выше остальных. Так же помогает психологическая готовность к изучению нового (это просто, потому что принципы там обычно детские, максимально адаптированные под массовых кодеров). Это всё даёт возможность оперативно менять работу при необходимости.

Но в целом ниша кодеров на порядки толще. Как и во всём остальном - китай доказал, что некачественные, но дешёвые, вещи, вполне конкурентоспособны.

Какой подход в итоге победит? Ответ - победят роботы.

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

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

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

Кстати, касательно аналогии с врачами: как раз в славном городе Таллине происходит процесс их «фуллстекизации». На качестве услуг это сказывается, скажем, прямо, неоднозначно. Например, уже давно педиатрия не выделяется отдельно: если у вас заолел маленький ребенок, вы пойдете не в детскую поликлинику к врачу-педиатру, который учился (и всю жизнь совершенствовал) навыкам лечения детских болезней, и детскому течению болезней, а к т.н. семейному врачу — т.е. врачу общей практики. Который будет лечить всех — от вчера родившегося младенца до пенсионера. Да, он может послать к специалисту — кардиологу, например. Но, во-первых, компетенции врача общей практики не всегда хватит, чтобы понять даже необходимость перенаправления, а во-вторых, кардиолог тоже будет «широкого профиля». А еще есть метрики эффективности, и семейному не всегда выгодно перенаправлять больного к специалисту. В итоге получаем следующее: типичные, самые распространенные болезни лечатся хорошо, а что-то редкое, всякие corner-case'ы — никак. Получается, что, условно, 75% болячек лечатся и лечатся дешевле, чем при старой системе — бюджет сэкономлен. А остальным 25% — не повезло, бывает.

Блин, как здорово, неужели есть компании, в которых работают ремесленники. Много раз сталкивался с тем, что просто не представляю как себя затаргетить во что-то одно, в ангуляр например, или только в .NET, или еще в какую либо область, ведь все равно они будут связаны потом. Радостно слышать что кто-то практикует такой подход к разработке

Все-таки прокомментирую, хоть и не новый доклад, потому что вижу много спорных утверждений и выводов.

Прежде всего, доклад для меня выглядит как описание интересного и крутого опыта, но опыта маленькой, почти не растущей компании (https://www.inforegister.ee/ru/11885355-CODEBORNE-OU), работающей над небольшими проектами. Причем, это не продуктовая разработка, а аутсорс: разработка множества проектов на заказ. И через призму этой единственной роли оценивается вообще вся разработка.

Мир IT можно поделить на startup и enterprise (маленькие, не растующие проекты отбросим, потому что там толком нет активности), требования к разработке у которых сильно разнятся. В стартапе важно с минимальными затратами за кратчайшее время выйти на рынок. Получить MVP и проверить жизнеспособность. Здесь разработчик ценен умением работать быстро, умением работать без ТЗ, умением пообщаться с основателем и клиентами, знанием всех технологий и актуальных деталей проекта, чтобы мочь в любой момент реализовать любую внезапно потребовавшуюся фичу, возможностью всегда быть на связи, потому что людей-то мало, а кризисы случаются, возможностью хоть как-то закрыть совсем непрофильную компетенцию типа составления и подписания договоров или поиска и найма людей в одиночку - опять-таки, людей и денег же мало. Здесь полностью согласен с докладчиком, на ранних этапах проекта фуллстеки идеально вписываются в требования.

В энтерпрайзе же, то бишь уже устоявшемся бизнесе, задачи другие: в первую очередь сохранить то, что уже есть, а потом уже по возможности развиваться дальше с оглядкой на обстановку. Спешка тут может сильно навредить: можно банально не справиться с ростом и развалить всю компанию. Цена ошибок тоже велика: есть, что терять. Отсюда выстраивание процессов разработки: код-ревью, юнит-тесты, авто-тесты, формализованные релизы или CI/CD. Тут от разработчика требуются углубленные знания теории в целом и конкретных технологий в частности (привет, специализация!), чтобы пропускать минимум своих и чужих проблем на прод, умение общаться с коллегами по поводу архитектуры и кодовой базы и поддерживать и менять общее техническое видение продукта (привет, техдир/архитектор!), умение не нарушать процессы, даже если очень хочется.

С ростом проекта приходится управлять инфраструктурой более серьезно: подход "инфраструктура как код" необходим. Здесь уже неизбежно появляется еще одна специализация: admin/sysops/devops, где как называют (хотя девопс все же не совсем то). И высшему руководству уже как-то неохота постоянно общаться с разработчиками по поводу цветов раскраски кнопок -> нужен зам по этом вопросам -> привет, техлид/тимлид/глава отдела! И все актуальнее становится вопрос безопасности: компанию замечают конкуренты и просто нехорошие личности, повышается риск атаки/взлома/утечки и серьезность последствий - появляется безопасник. И поток обращений клиентов растет до неприличных размеров - нужен саппорт. И за конкурентами следить надо, и свою репутацию поддерживать - отдел маркетинга. И размер кодовой базы становится настолько велик, что отдельному разработчику просто не под силу хорошо знать все компоненты проекта и быть в курсе всех изменений - специализация по подпроектам/областям/отделам. И технологий становится много, потому что нет одного универсального языка. И легаси проявляется с устаревшими версиями/фреймворками. И так далее, и так далее.

В скраме есть, как мне кажется, хорошее понятие: T-shaped специалист. Человек, который очень хорошо знает небольшой набор технологий и поменьше разбирается в широком круге других. Отсюда две крайности: когда человек разбирается в огромном количестве вещей, но в каждой из них весьма посредственно, или сосредоточился на узкой области, но достиг в ней больших высот. В докладе подробно пропесочиваются проблемы второго типа, но замазывается главная проблема первого: невозможно быть экспертом сразу во всем. Если ты пишешь на 5-10 языках, то при прочих равных в каждом из них ты будешь слабее того, кто пишет условно на 1-3. Если ты разрабочик, то тестировщик найдет больше багов, чем ты. Админ лучше знает, как настроить сервер/сеть, подтюнить базы и шины данных и т.д. Безопасник найдет больше проблем, качественнее закроет дыры и гораздо лучше справится с грянувшей атакой. Как успевать еще и знания актуальными поддерживать и не на поверхностном уровне? А как скоро бизнес поймет, что с ростом проекта недостаточно компетентные в каждой конкретной области специалисты становятся неприемлемо опасными?

Докладчик, конечно, упоминает об этом и даже предлагает свое определение фуллстек-разработчика: "вы знаете все стеки вашего собственного проекта". Но много вы знаете людей, которые действительно хорошо умеют одновременно, ну например, в php5+php7, python2+python3, bash+powershell, java, c++, js+typescript клиентский и серверный, 1-2 фреймворка на перечисленных языках, Android(java/kotlin), iOS(swift), sql+nosql, пишут пайплайны, могут тонко подтюнить виндовые и линуксовые сервера, настроить сети между несколькими датацентрами, организовать мониторинг zabbix+prometheus, поднять и поддерживать кластеры DB+ELK+RMQ, описать прод и дев инфраструктуру в ansible+terraform, могут провести аудит безопасности и сертифицировать компанию по ISO, а заодно работают 1/2/3 линией техподдержки и лично общаются с клиентами через почту и телефонию, верстают и отправляют почтовые рассылки, делают клиентские и технические аналитические сводки и прогнозы... и я подчеркиваю - хорошо умеют все это делать, потому что даже по словам докладчика все нужно сразу делать хорошо. Давайте даже выкинем все, не относящееся к разработке, оставим только работу с кодом и часть админского шаманства. Мне вот на питоне однажды пришлось писать компонентик строк эдак в тысячу-две, впервые имея дело с этим языком. Уже можно зачесть это как развитую компетенцию в рамках фулстека или все-таки любой мидл-питонист этот код на помойку выкинет?

Описывая "конфликты" между специализациями людей, свой прошлый опыт и даже опыт в Codebourne, докладчик сам называет проблему: нет общения. А если и "крафтсмен" заменить на "разработчик, погруженный в предметную область", то все встает на свои места: специалисты максимально эффективно вносят вклад в продукт, потому что хорошо знают его в целом, применяют свои самые сильные стороны и работают сообща. Точка.

Ну и немного по тексту:

Потом вы берете какой-то новый язык программирования, играетесь с ним пару дней, и после можете так же круто перформить, как вы делали это на Java, например.

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

И нас теперь понизили до API-разработчиков.

Очень сильно зависит от предметной области и размаха проекта. Где-то в UI вся суть продукта, а где-то UI - это лишь маленькое окошко в огроменную систему, где и происходит вся магия.

Все доходит до того, что есть разработчик функции X и функции Y, и считается, что мы разные, и мы не общаемся

Кто сказал? Коммуникации жизненно необходимы, будь то внутри команды или между отделами, иначе будет как с пошивом пальто у Аркадия Райкина.

Если мы посмотрим немного в прошлое, то увидим, что в прошлом все программисты были фуллстек-крафстменами

Тогда мир IT был намного-намного меньше.

«Совершенство достигается не тогда, когда вам больше нечего добавить, а когда вам больше нечего убрать».

Мне тоже нравится эта цитата, Микеланджело похожее видел в творчестве: "Я беру камень и отсекаю всё лишнее.". Вот только фулстек - это как раз о том, чтобы напихать всего, да побольше.

Сейчас весь скрам превратился в полный buzzword. Например, extreme programming пропагандирует техническое совершенство — но где это совершенство?.. А скрам теперь просто buzzword, оно больше ничего не стоит. И даже Кен Швабер, изначальный создатель скрама, ушел из Scrum Alliance, потому что это все превратилось в армию консультантов: они прошли двухдневный курс и говорят, что знают, как наладить процессы в организации. Это стало религией, которую никто не знает, как практиковать.

Но мы можем делать лучше. Через какое-то время появился новый манифест. Манифест получился еще круче, он назывался «Manifesto for Software Craftsmanship».

Слово "скрам" превратилось в баззворд? Не проблема, мы придумаем вам новое слово "крафтсмен", которое тоже превратится в баззворд, и тогда мы придумаем еще какое-то слово...

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

Но, по мере развития компании ...вы придете к необходимости нанимать профильных специалистов ... Разделение идет не просто так, а потому что и на бэке и на фронте своя специфика ...разные потребности, даже разные языки ...
Я бы советовал , брать смежные ниши в рамках своего языка...Чем перепрыгивать из одного мира в другой )
Для Java/C# это бэк и мобильная разработка

Зарегистрируйтесь на Хабре , чтобы оставить комментарий