Full-stack разработчики: Программисты, понимающие весь стек, обычно создают более качественные приложения

46 комментариев
Full-stack разработчики: Программисты, понимающие весь стек, обычно создают более качественные приложения

В последнее время словосочетание full-stack developer получило очень широкое хождение. Многие компании хотят заполучить себе в штат именно такого генералиста и мастера на все руки, прямо указывая в разноязычных вакансиях «нужен full-stack разработчик». Тем временем, как раз именно из-за обширности багажа подобного специалиста, представления о «тру фул-стеке» сильно разнятся. Автор этого поста считает, что судить о full-stack разработчике надо по делам его , а именно, по качеству его работы, и не забывает предоставить свой собственный список чудо-умений.

С тех пор, как Карлос Буэно из Facebook написал классическую статью о full-stack, выходит масса постов, авторы которых пытаются определить это понятие. Ходили слухи, что в течение некоторого времени Facebook нанимал на работу только full-stack разработчиков. Вероятно, это все-таки преувеличение, пусть и похожее на правду. Некоторые из авторов фактически считают full-stack разработчика полумифическим персонажем. Так, Лоренс Геллерт пишет, что full-stack разработчик — это «больше, чем senior-специалист», после чего подробно рассматривает те навыки и умения, которыми, на его взгляд, должен обладать такой разработчик. Большинство навыков, упомянутых Геллертом, не связаны с написанием кода.

И еще крестиком вышивает
Подобные списки качеств обычно получаются или слишком длинными, или слишком короткими. Я согласен, что full-stack разработчик и senior-инженер — не обязательно одни и те же люди. Но   идея о том, что full-stack специалист обладает почти волшебными навыками сразу во многих областях, кажется мне неприемлемой. Геллерт же заявляет, что уровень full-stack предполагает «хорошее представление о каждом уровне стека, если не сказать — мастерское им владение». Правда, я бы добавил в список Геллерта еще несколько позиций, о которых он лишь вскользь упоминает: контроль исходников, инфраструктуру данных, распределенные вычисления и т. д.

Учитывая это, давайте попробуем определить, что такое стек. Возьмем для примера уже довольно архаичный стек LAMP: Linux, Apache, MySQL, Perl. Этот список неполный и определенно устаревший. Linux и Apache по-прежнему активно используются, хотя уже набирают популярность другие серверы, например, nginx. База данных MySQL все еще в ходу, правда, уже появились десятки пост-реляционных баз данных (наиболее известными среди них являются MongoDB и Cassandra). Я не удивлюсь, если в ближайшие несколько лет MariaDB придет на смену MySQL. Уже никто не пишет CGI-программы на Perl; вместо него используются самые разные языки, от Haskell до Java. Но пусть стек LAMP и устарел, в нем заложена правильная идея: операционная система, сервер, база данных, связующее ПО. Стек LAMP появился в те времена, когда язык HTML был тривиальным, а все вычисления выполнялись на сервере. JavaScript был «игрушечным» языком, помогавшим склеивать разные компоненты в браузере, но на этом его роль заканчивалась. В настоящее время JavaScript развился, стал серьезным полнофункциональным языком программирования, CSS ненамного от него отстает. Если вы мыслите себя full-stack программистом, то, несомненно, должны полностью понимать ту платформу, на которой базируется клиентская часть вашего приложения. Стек MEAN, Mongo, Express, Angular и Node — более современный аналог LAMP, красноречиво показывающий, что язык JavaScript уже развился в самостоятельную платформу.    

Наряду с веб-программированием, full-stack разработчик должен в известной степени понимать проектирование. Чтобы написать по-настоящему качественное веб-приложение, необходимо обеспечить безупречное пользовательское восприятие. Дизайнер понимает, что его работа отнюдь не ограничивается созданием макетов в Photoshop. Разработчик также должен понимать причины, по которым приложение проектируется так, а не иначе, уметь обсудить с дизайнерами о том, что удастся и что не удастся эффективно реализовать. 

Не забываем и о железе, на котором работает стек. В большинстве текстов о full-stack программировании делается акцент на производительности. Составить полное представление о производительности зачастую удается при детальном понимании взаимодействия ПО с железом. Буэно совершенно верно подмечает это: программист должен знать, как SQL обрабатывает запросы, как процессор выполняет инструкции, как дисководы предоставляют данные через систему уровней кэширования. 
Далее начинается работа с сетью. В настоящее время практически все задачи решаются с применением сети, и ваша работа в сети может кардинально влиять на производительность. Илья Григорик написал отличную книгу для веб-разработчиков о принципах функционирования сетей.

В настоящее время многие новые приложения (и практически все приложения, разрабатываемые на стартапах) работают в облаке. Они не просто хранят данные в облаке, но и опираются на инфраструктуру Amazon, позволяющую выстраивать виртуальные серверные фермы и датацентры. Масштабируемость таких систем практически безгранична. Соответственно, full-stack разработчику необходимо понимать Amazon и его API: что вы покупаете, как это оплачивается, какими сервисами при этом можно воспользоваться. Кроме того, облачные технологии неразрывно связаны с распределенными вычислениями. Несмотря на всю шумиху об отказах амазоновских серверов, готов поспорить, что Amazon работает гораздо стабильнее, чем любой самодельный датацентр. Тем не менее, вы должны обладать всеми необходимыми знаниями, чтобы обеспечить жизнеспособность приложения в условиях таких отказов.    

В настоящее время существует ряд интересных приложений, в основе которых лежит не обработка данных, а что-то другое. Допустим, вы пишете для электронного магазина такую программу, которая делает рекомендации. В данном случае, кроме всех вышеупомянутых компонентов стека вам придется иметь дело с Hadoop, Mahout, Scikit-learn, либо какой-то другой библиотекой для машинного обучения.

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

В начале статьи я сказал, что мне не нравится отношение к full-stack разработчику как к полумифическому персонажу. Затем на ваших глазах я сильно расширил стек — настолько, что его уже сложно назвать стеком. Фактически, мы получили дерево с инструментальной оснасткой, облачными сервисами, дизайном, данными и сетевой частью. Я нисколько не сомневаюсь в том, что разработчик должен как можно лучше ориентироваться в бизнес-составляющей, в работе менеджеров и т. д. Добавим еще одну ветвь к этому дереву. Что, удалось усугубить картину? Может быть, «full stack-разработчик» — это действительно кодовое наименование волшебного юнита, который умеет все: и программировать на ассемблере, и уговаривать финансистов? Может быть, такой умелец и канализацию в офисе починить может (кстати, на стартапах — незаменимый навык).

Нет, все не так плохо. Действительно, быть full-stack разработчиком — нелегкая задача, но она вполне сравнима по амбициозности со многими другими программерскими затеями. Так, я не считаю, что full-stack разработчик принципиально превосходит в профессионализме senior-разработчика. Более того, могу себе представить junior-разработчика, ориентирующегося во всем стеке, но отнюдь не считаю, что вакансии должны пестреть упоминаниями full stack. Мне больше нравится характеристика «Т-разработчик», подробно описанная (в частности) в пособии для сотрудников Valve. Т-разработчик обладает широкими знаниями и интересами, но при этом глубоко понимает ту область, в которой специализируется. Я не рассчитываю, что разработчик будет в разбираться в проектировании не хуже дизайнера, либо справляться с обслуживанием сетей так же умело, как инженеры-специалисты. Но разработчик должен понимать такие проблемы и уметь грамотно о них рассуждать.   

Более фундаментальная проблема, которая все четче вырисовывается в последние годы, заключается в исчезновении барьеров между разработчиками с разными специализациями. В частности, методология DevOps размывает границы между разработчиками приложений и эксплуатационным персоналом, отвечающим за развертывание и обслуживание этих приложений. Оптимизация производительности зачастую требует нарушать тщательно уложенные уровни многослойной софтверной архитектуры. Иногда мифический «full-stack разработчик» требуется потому, что «мы убрали все барьеры, теперь нам нужен один мастер на все руки». Это нонсенс. На самом деле, нужен не человек, способный заменить всех узких специалистов, а такой сотрудник, который способен продуктивно участвовать в работе самых разных специализаций, эффективно взаимодействовать с коллегами, работающими в других частях команды.   

«Full-stack разработка» — это умение воспринимать самые разнообразные идеи. Со временем такой талант будет становиться все более востребованным. Быть «full-stack разработчиком» не означает в одночасье переключаться с обслуживания кластера Hadoop на программирование связующего ПО на Java, а потом на JavaScript, работающий исключительно в браузере. Специализации придуманы не зря. Но разработчик, понимающий весь стек технологий, будет писать более качественные приложения. Так, разработчик машинного интерфейса будет понимать, чем занимаются разработчики клиентской части, сможет взаимодействовать с ними. Приложение не будет генерировать запросов, из-за которых база данных слетает с катушек. Клиентский разработчик, разбирающийся в проектировании, сможет помочь дизайнеру подготовить красивое приложение, которое при этом будет эффективно функционировать на любой платформе.

Чем активнее вы воспринимаете различные идеи, тем больше вы узнаете о других специализациях, а не только о вашей собственной. Тем более эффективно вы будете работать — по той простой причине, что научитесь взаимодействовать с коллегами. Более того, обладая обширным арсеналом идей и концепций, вы будете лучше справляться и со своими основными задачами. Вот к чему мы стремимся, именно в этом и заключается вся польза full-stack разработки. 

Майк Лукидес

Источник

Фото: flickr.com

По теме
Все материалы по теме

Хотите сообщить важную новость?

Пишите в наш Телеграм

Горячие события

EMERGE 2020
1 июня — 3 июня

EMERGE 2020

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»
4 июня

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»

Читайте также

EPAM разработал бесплатный курс по обучению детей программированию в Scratch
EPAM разработал бесплатный курс по обучению детей программированию в Scratch

EPAM разработал бесплатный курс по обучению детей программированию в Scratch

3 комментария
Как защитить видеозвонки. Советы экспертов
Как защитить видеозвонки. Советы экспертов

Как защитить видеозвонки. Советы экспертов

За месяц число ежедневных активных пользователей сервиса для видеосвязи Zoom выросло в 1,5 раза — с 200 млн до 300 млн, хотя ещё в декабре их было лишь 10 млн. По мере роста популярности приложение стало привлекать хакеров, а в сети появилось столько новостей об уязвимостях Zoom, что на мессенджер обратило внимание ФБР. Издание Computerworld собрало небольшой список рекомендаций от экспертов по кибербезопасности о том, как защитить данные и участников видеоконференций от взломов, утечек и непрошенных гостей.
Guardian: массовые мероприятия как топливо для эпидемии
Guardian: массовые мероприятия как топливо для эпидемии

Guardian: массовые мероприятия как топливо для эпидемии

Коллективная статья семи журналистов Guardian о том, почему массовые скопления, рукопожатия, поцелуи и общие напитки виноваты в распространении коронавируса. Публикуем перевод материала с незначительными сокращениями.
1 комментарий
10 образовательных приложений, чтобы провести самоизоляцию с пользой
10 образовательных приложений, чтобы провести самоизоляцию с пользой

10 образовательных приложений, чтобы провести самоизоляцию с пользой

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

Обсуждение

-5

Сферический конь в вакууме?

-1

нет

0

:))) исходя из аксиомы "нельзя объять необъятное", все же конь и причём в очень глубоком вакууме.

-1

Вовсе нет. Как пример: идеальный ИТ-ВУЗ - после которого выходят junior full-stack специалисты.

0

ИТ-колледж.

ВУЗ все таки должен закладывать мощный фундамент. Из него должны выходить отличные R'n'D. И как следствие соотношение студентов колледжа/вуза должно получиться скажем 9/1.

Anonymous
Anonymous Software Engineer в ScienceSoft
0

По своему опыту могу отметить, что специалисты, имеющие дело с несколькими инженерными/научными направлениями на порядок(!) профессиональнее своих коллег, работающих в одном русле.

0

Дмитрий, тема не раскрыта. Что значит "профессиональнее"? ;)

0

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

0

все как бы тру, но стоит различать понятия "понимать как устроен full-stack" и "использовать/пилить под full-stack". во втором случае вполне можно применить первый комент

0

Есть архитект, он должен понимать стек тех комнонентов из которых состоит продукт и обладая этьим знанием выстраивать оптимальную архитектуру. ВСЁ.
Нет и не может быть архитектора (full-stack специалиста), способного одинаково хорошо и спроектировать здание (как с дизайнерской, так и инженерной точки зрения) так и построить его, положив собственноручно каждый кирпич и смонтировав каждую розетку не том же уровне качества, как и узкий специалист.
Именно поэтому считаю статью высосанным из пальца конём. Поиск такого человека - это поиск птицы счастья. Есть конечно гении, но на всех их не хватит. Поэетому специализация рулит. Кто то специализируется в коде, кто то в архитекторе и будет всем счастье.

3

а вы я смотрю открыты для альтернативных подходов. :D

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

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

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

1

Зря вы про обезьян. Если проект небольшой, то почему бы и каждому не разбираться в нём на дОлжном уровне. Но на нормальном (читай сложном) проекте даже не надо поток изменений увеличивать - далеко не каждый способен в разумные сроки охватить "пониманием" все его части, да и лишнее это - ему бы свою освоить и хорошо сделать. Да, архитект часто достаточно критическое звено, но так бывает - это дешевле, нежели из всех делать архитектов.

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

3

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

Я вижу смысл статьи не в том, что “давайте нанимать мастеров на все руки и менять их местами каждый день”. Автор несколько раз подчеркивает что “специализации никто не отменял”. Однако знание и понимание UX причин того или иного интерфейса однозначно поможет FE разработчику спроектировать иили реализовать этот интерфейс лучше ; знание бизнес причин той или иной функциональности поможет BE разработчику спроектировать иили реализовать эту функциональность и т.д. и т.п.

P.S. И прошу еще раз заметить, что в статье акцентировано внимание на то, что автор вкладывает в понятие full-stack специалиста не "мастера на все руки, супермена с клавиатурой", а скорее Т-образный специалиста Valve. Если вы не читали эту концепцию - очень рекомендую, это интересно!

1

"пользовательское восприятие" странный термин

1

В оригинале - user experience. В издательстве "Питер" термин считается адекватным, в книгах регулярно встречается http://bit.ly/Ruw9QL, http://bit.ly/1lcNwm8

0

"пользовательское восприятие" 6 раз
"user experience" 539000 раз

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

1

На мой взгляд, лучше и распространеннее:
- "пользовательский опыт"
- "удобство пользователя / пользования"

0

эти чудо термины всплывают после работы переводчикака за 3 бакса страница :)

3

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

Михаил Дубаков
Михаил Дубаков Writer в Fibery
8

Все очень просто (эта фраза — такой прием, чтобы убедить других в своей правоте сразу). Чем больше человек хранит знаний из самых разных областей, тем больше у него шанс решить проблему круче, чем узкие специалисты. Вопрос ширины vs глубины сложно определить однозначно, потому что глубина может быть разной и не всегда понятно, какая оптимальна. Но возьмем для примера двух программистов — Васю и Петю, с одинаково хорошим знанием допустим OОП + Java + Java stack. Но вот Вася, к примеру, читал книжки по биологии, астрономии, физике, математике, лингвистике и теории музыки. Так вот Вася будет более крутым разработчиком чем Петя. У него в голове гораздо больше примеров систем, архитектур и концепций. Он чаще будет придумывать более оригинальные и целостные решения и сможет атаковать проблемы с разных направлений. А Петя, скорее всего, будет долбить всю жизнь несколько паттернов, постепенно и медленно расширяя свой арсенал.

-1

Полностью согласен. Но есть одна проблема.
>>Вася будет более крутым разработчиком чем Петя.
Но по результатам собеседования в любой минской компании им определят одинаковую з/п.
Повторюсь, в любой, даже в тех компаниях, которые считаются (ну хотя бы ими самими) "самыми лучшими", "продвинутыми" и "не такими как все" и т.д.
А на знания и список книжек по "биологии, астрономии, лингвистики и прочей теории музыки", даже ваши, что менеджеры или HRы, что технические специалисты (или кто там у вас рекрутингом занимается) будут удивленно округлять глаза и в лучшем случае говорить то же самое, что здесь недавно писал один лид, рассказывая о своём опыте подбора кадров: мол, что вы мне мозг всем этим "мусором" выносите, какая нафиг "теория музыки", только внимание этим зря отвлекаете...
Поэтому, на мой взгляд, в вашем комментарии, как от лица, желающего быть хорошим работодателем, гораздо интереснее было бы увидеть ваше мнение, что таким Васям делать... что б им не платили, как Пете?

Михаил Дубаков
Михаил Дубаков Writer в Fibery
1

Я сам занимаюсь рекрутингом, так что пока такой проблемы нет, и у Васи все в порядке :)

-2

Петя + специалист в предметной области будут более крутыми разработчиками чем два Васи. Вот в чем превосходство специализации перед "универсальными солдатами".

Михаил Дубаков
Михаил Дубаков Writer в Fibery
0

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

0

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

0

Очевидно, что визуальный редактор MIDI-мелодий Вася спроектирует лучше Пети.

amok
amok Team Lead в Ergalio
0

Если вы про UI, то они оба его криво спроектируют.

0

Очевидно, что Петя в команде со специалистом в данной области спроектируют его лучше, чем два Васи.

-2

Тут уже пошла какая то "мешанина"...
У Михаила, даже следуя логике рассуждений в статье, Вася - это скорее "T-shape"-специалист, а не "full-stake". Ведь "OОП + Java + Java stack" какой то не совсем "ИТ - full-stake" получается, согласитесь. Но называть "T-shape" - специалиста в отличии от "full-stake" "универсальным солдатом" как то не совсем логично.
Поэтому, для меня из рассуждений Михаила, более-менее понятно: Вася - "T-shape", Петя - "узкий ИТ-специалист" и идёт их сравнение. При этом ширина "Т", как Михаил и писал, может выходить даже за пределы ИТ - хоть в астрономию или теорию музыки.
Но что вы имеете ввиду, мне тогда не совсем понятно. Кого вы противопоставляете? Кого прибавляете к Пете? Специалиста из ИТ или из "теории музыки", как у Михаила?
---
Когда мы говорим не про "эникей", а нормальных специалистов, для меня в современном мире очевидна как раз таки противоположная проблема: матёрый лид Вася, формально являющийся разработчиком, фактически же, на деле, можно сказать, сам в одиночку работает с заказчиком, изучает его потребности, формирует тз, планирует работу команды и ход выполнения проекта. В то время как на митинги вместе с них ходят и рядом сидят два, как вы пишите, "специалиста" в своей предметной области: одна девочка - "системный аналитик", вторая девочка - "менеджер проекта". Пришедшие, кстати, после очередных "крутых" 40-часовых курсов, которые я здесь часто ругаю. И эти девочки отсутствие вообще каких либо элементарных знаний в CS как раз и оправдывают своей "узкой специализацией". Но заказчику от их "узкой специализации" не холодно, не жарко. Ему дело надо делать - и он, соответственно, разговаривает с тем, кто реально понимает, о чем идёт речь и что надо дальше делать. А не с теми, кто просто кивает и всеми силами пытается выразить понимание, даже деловито что то помечая в блокнотике. Но никакие кивания, ни строгий деловой наряд и мэйк-ап, ни выложенные в ряд макэир-айпад-айфон не скроют в красивых глазках той всеобъемлющей, космической, вселенской, бездонной пустоты и абсолютного непонимания, что вообще вокруг происходит.
И пока "узкие специалисты" пытаются ещё чётче очертить круг своей "узкой специализации", яростно его защищая, боясь выучить что-нибудь новое, что б не дай Бог никто не поручил выполнять работу по этому новому направлению, этот самый Вася, смотря на всё это б... безобразие, с грустью сплёвывает в сторону и начинает сам е-башить проект, параллельно закрывая ещё кучу дырок за этими "узкими специалистами". Потому что "специализация"-"специализацией", но кому то ещё и проект надо делать. А сколько в этом процессе Вася своей работой таких "узких специалистов" закрывает: два, три, пять, а может даже и десять, он обычно даже и не задумывается. Жаль, что и руководство обычно тоже об этом не задумывается. Но это только пока Вася не решает свалить. Тогда то и начинается самая интересная часть марлезонского балета. И для руководства и для "узких специалистов" ;)
Но это уже, как говорится, совсем другая история...

1

>> ... и рядом сидят два, как вы пишите, "специалиста" в своей предметной области: одна девочка - "системный аналитик", вторая девочка - "менеджер проекта" ...

Это у вас "гендерные" стереотипы или эротические фантазии?

-3

>>Это у вас "гендерные" стереотипы или эротические фантазии?
Это оценка математического ожидания пола и возраста высококлассного специалиста в ИТ, основаная на объективной окружающей реальности...
Я не гуманитарий, я технарь... у меня всё просто... основано на статистике, фактах...
Это в вашем мире, я так понимаю, "свободном от гендерных стереотипов" неплохо "фантазируют"... в своих толерантных подходах уже "дофантазировались", что ребенка то в мальчика, то в девочку переодевают, что б он "сам определился".
Поэтому вы там "освобождайтесь", а я уж, спасибо, лучше останусь со своими, как вы говорите "стереотипами" ;)

0

Честно говоря, в моем мире это эротические фантазии.

-2

ну тогда "жениться вам, барин, надо..." :)

0

Интересный пример. Но все же, на мой взгляд вы немного не то сравниваете.
Ваш пример скорее идет в сторону мотивации и степени вовлеченности специалиста на проекте, и ваши "спецы" больше похожи на латентных агрессоров (сидят никому не мешают пока сами не вляпаются, а как вляпаются начинают бурю). Вот, собственно, все это и упираются в командный дух, в коллективе где каждый ежедневно задает себе вопрос "а что я сделал для проекта", такое вряд ли встретишь, и не важно I-shape или T-shape.

Со статьей и позиционированием Full-stack полностью согласен и поддерживаю. А к вопросу как им стать - вовсе "не трудно", создайте собственный сервис с "0" в одиночку, запустите и развивайте :)

-2

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

0

Чтение книжек по биологии противопоставляется "долблению нескльких паттернов" ?

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

Из личного опыта (а не из книжек) знаю что хорошие и мощные решения идут исключительно от людей занимающихся не музыкой и биологией, а именно от ребят расширяющих кругозор в достаточно узкой (:)) области Computer Science и нескольких связанных. Слишком сильная (искренняя) увлеченность чем то сторонним частенько выливается в излишнюю болтливость и полное непонимание ценности надежных и проверенных решений.

Petr Popov
Petr Popov Technical Recruiter в Toptal
2

Full-stack разработчек атомарен и независим. Это элементарная единица разработки, если так можно выразиться. Такой разработчик в состоянии сделать систему в одиночку на должном професиональном уровне. В этом его ценность.

Хотя также существует понимание, что full-stack разрабочик - это тот, кто может одинаково хорошо работать на разных уровнях хорошо известной многоуровневой архитектуры - UI (пользовательский интерфейс, причем обычно речь про клиентскую часть веб приложений), Business Logic (ядро системы с закодированными бизнес правилами), Data Access (уровень доступа к данным), Back End (обычно хранилище данных - база данных или внешние сервисы используемые для получения и хранения данных).

Или иногда также full-stack разработчиком часто просто называют веб разработчика. кто одинаково хорошо справляется как с программированием клиентской части приложения, так и серверной. http://dev.by/blogs/toptal/init-js-zachem-i-kak-razrabatyvat-s-full-stack-javascript-toptal-blog

-1

чисто рекрутерский подход :)
вы прям методичку процитировали:)

Petr Popov
Petr Popov Technical Recruiter в Toptal
1

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

1

И отлично получилось! Ваш предыдущий коммент описывает full-stack разработчика более полно, чем статья ;)

amok
amok Team Lead в Ergalio
1

Можно ещё добавить, чтобы умел (веб) сервисы чужие вызывать и свои создавать. Мог быстро въехать в домен и бизнес-требования. Ещё что-то знал про производительноть и что в связи с этим нельзя делать. Ещё немного уметь конфигурировать database and web server.

-2

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

0

Мне кажется что очень трудно на профессиональном уровне разрабатывать UI и писать какую то серьезную алгоритмическую логику. Но часто вижу разработчиков которые знают JS фреймворк, сишарп на уровне непонимания того как работает async/await "но работает и ладно", SQL на уровне базовых операций (курсоры, повороты таблиц даже не знакомы как термины), http как некий протокол по которому "шлются запросы" (слова syn/ack/fin обычно расширяют зрачки до размера 5копеечной монеты).

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

Petr Popov
Petr Popov Technical Recruiter в Toptal
2

Обладание этими навыками отличает эксперта от специалиста. Клиенту нужна работающая оттестированная система. Как правило ему не очень интересно, что писал его систему - специалисты или эксперты. И подавляющее большинство заказываемых систем не требует очень глубоких знаний. Так что в нашей индустрии (при молниеносной смене технологий) уход в эксперты означает как правило меньшую востребованность и более узкую специализацию при более высокой зарплате, но более проблематичном поиске новой работы. Посколькуо специалист знакомый с актуальными фреймворками на уровне 1-2 проектов за плечами - досупен по стоимости и достаточен для 90% работы. Это, возможно, печально для нас как для представителей профессии, но нормально для любого рынка в целом. Первые 20% знания в любой области позволяют решать 80% задач этой области. Последующие 80% - соответственно всего 20%. Это - принцип Парето. :)

-1

На самом деле фундаментальные вещи молниеносно не меняются. Реляционная алгебра стабильна последние лет 20. Сокеты - еще больше. Асинхронное, параллельное программирование - тоже не сегодня появилось. и с приходом в каждый дом многопроцессорных(многоядерных) устройств - будет процветать и дальше.

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

Petr Popov
Petr Popov Technical Recruiter в Toptal
1

Чувствуется некое пренебрежение к понятию full stack :) Как говорят лингвисты - негативная сема :)

Само по себе понятие - раз уж оно появилось - необходимо для того, чтобы как-то обозначить специфику разработчика. Ничего плохого в том, чтобы быть таким (универсальным в какой-то мере) программистом нет. Хотя конечно нужно понимать, что речь идет о полном цикле весьма определенного вида разработки - как правило - это веб и/или мобильная разработка бизнес приложений. Универсального (в широком смысле) программиста, наверное, нет существует. Достаточно справедливо говорят - "универсальный - это когда все одинаково плохо".

Если говорить о full-stack, то это явление - следствие требований рынка. Сейчас клиент не хочет вникать во все наши многоуровневые архитектуры и отдельную разработку бекенда, бизнес логики и UI, и что для этого нужен DBA, парочка программистов и дизайнер/юзабилист/верстальщик. Клиент хочет одного человека, коорый достаточно компетентен во всех необходимых для выполнения работы областях. Разработчики вынуждены "универсализироваться", чтобы как-то в одиночку можно было делать то что когда-то делали небольшой командой. И именно из-за этой тенденции создаются десятки различных фреймворков, позволяющих быстро "накидать" приложение по одному из типовых сценариев. Это нормально. Так работает любая промышленность - типовые решения, стандарты, паттерны и проч. Представьте если каждый автомобиль собирался нинзя автомехаником с изготовлением каждой детали вручную. Он стоил бы огромных денег и в производстве и в последующем обслуживании.

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже