Перевод статьи Даны Фредерик «The Strange Politics of the “Full-Stack Developer”».
В идеальном мире full-stack разработчики это люди, которые – теоретически – могут создавать пригодный к использованию конечный продукт при минимальных затратах и с минимальной поддержкой других людей.
Камнем преткновения является вопрос, что именно делает вас full-stack разработчиком. Не все считают, что этот термин стоит использовать. Кто-то, напротив, стойко его защищает. А кто-то вообще не верит в существование full-stack разработчиков!
Разногласия относительно определения «full-stack разработчик» не только вызывают жаркие онлайн-споры, но и влекут за собой несогласованность относительно оценки, привлечения и найма таких разработчиков.
И хотя было бы проще просто отодвинуть эту дискуссию на второй план, термин «full-stack разработчик» от этого никуда не исчезнет. Спрос на специалистов с такими навыками вырос на 198% только за прошлый год. Кроме того, большинство разработчиков со всего мира именно этими словами описывает свой род деятельности (согласно нашему 2018 Developer Skills Report).
В этой статье мы попробуем пояснить, отчего возникает путаница относительно названия этой специализации и изложим очку зрения каждой из сторон. Также мы поможем рекрутерам и менеджерам по найму договориться с командой относительно того, что понимать под «full-stack» и специалист с какими навыками им нужен.
Чтобы лучше понять существующие разногласия относительно термина «full-stack разработчик», мы разберемся, с чего все началось.
Рождение full-stack разработчика
Термин «full-stack разработчик» вошел в моду не так давно. Одно из самых ранних упоминаний относится к 2008 году, а первый запрос «full-stack developer» в Google появился не раньше 2010. С тех пор популярность этого запроса начала расти.
«Full-stack developer» в трендах поиска Google с 2004 года. Подъем популярности отражен для разных вариантов написания, например, «fullstack developer» и «full stack developer».
Но если такой вид деятельности в какой-то форме существовал еще в пред-интернетное время, почему мы не видим роста популярности этого термина до начала 2010-х? Оказалось, ответ на этот вопрос требует небольшого исторического экскурса.
История
Поздние 1970-е / ранние 1980-е
До интернета, до мобильной эры обычно написанием программы от начала до конца занимался один человек. Он же занимался и аппаратными средствами. Отделение чисто программистских обязанностей было скорее редкостью.
Поздние 1980-е / ранние 1990-е
В мир приходит клиент-серверная организация – группы программистов начинают сотрудничать при создании приложений. Командная работа становится новой нормой.
Поздние 1990-е / ранние 2000-е
Интернет «наступает» – технологии становятся все более специализированными, соответственно и у людей, занимающихся ими, возникает узкая специализация.
Середина 2000-х
Разработка становится очень дорогой, что связано со сложностью управления большим количеством специалистов, занятых в одном проекте. С другой стороны, web 2.0 сайты становятся все более понятными и хорошо налаженными.
Поздние 2000-е
Соответствующие технологии упрощаются до уровня, при котором многие программисты вновь могут создавать приложения и сайты от начала до конца. Официальное рождение термина «full-stack developer».
Ранние 2010-е / настоящее время
Быстрый подъем более сложных технологий привел к тому, что стэк стал более «слоистым». Разработчикам стало сложнее поддерживать знания на соответствующем уровне. Начинают появляться специалисты фронтенда и бэкенда. «Full stack» разработка приобретает новое, более широкое значение.
Согласно истории термина, «full-stack разработчик» сначала приобрел популярность в середине 2000-х, когда более простые и оптимизированные технологии позволили многим разработчикам выполнять проекты полностью. Этот подход диаметрально отличался от того, что было в поздние 1990-е и ранние 2000-е.
С течением времени смещение в сторону более сложных технологий и большего количества слоев в стэке (ранние 2010-е) привело к новому разделению ролей. Работа с бэкендом и фронтендом все более разделяется, что приводит к популяризации терминов «фронтенд-разработчик» и «бэкенд-разработчик».
В качестве ответной реакции в тот же самый период времени термин «full-stack разработчик» также приобретает популярность. Это связано с попыткой выделить разработчиков, не укладывающихся в бинарную систему фронтенд/бэкенд специалистов. Вместо этого они позиционируют себя как третий вид разработчиков, представители которого могут выполнять обязанности как по фронтенду, так и по бэкенду.
Но, конечно, с такой интерпретацией согласно не все тех-сообщество. И хотя сложно сказать, когда эти споры начались, катализатором для них выступили два события. Первым был пост бывшего инженера Facebook Карлоса Буэно от 2010 года о том, что такое full stack. Вторым событием стало услышанное Лоренсом Геллертом на конференции заявление сотрудника Facebook о том, что эта компания нанимает только «Full Stack разработчиков» (2012 год).
Что имеем в результате? Жаркие дебаты относительно терминологии все еще живут, даже спустя почти 10 лет.
Доводы против full-stack разработчика
Представители лагеря противников «full-stack разработчика» доминируют в спорах о том, из чего состоит (или не состоит) full-stack. Коротко говоря, их аргументы крутятся вокруг идеи, что full-stack разработчик это некто со «способностью легко управляться с бэкендом и фронтендом на уровне сеньора».
Хотя у этого представления есть некоторые вариации, данный лагерь считает, что full-stack разработчики должны уметь:
- Писать первоклассный код фронтенда на том же уровне, что и узкий фронтенд-специалист.
- Писать в равной степени превосходный код бэкенда на том же уровне, что и бэкенд-специалист.
- Управлять серверной инфраструктурой.
- Разбираться в не-техническом менеджменте проектов и бизнес-требованиях, на основе чего координировать свою работу с продуктом.
- Контролировать работу QA, DevOps и вопросы, связанные с безопасностью.
И хотя эта группа признает, что многие разработчики могут выполнять некоторые работы в рамках обеих дисциплин, они считают, что мало кто может делать это одинаково хорошо. Короче говоря, они считают настоящего full-stack разработчика своего рода единорогом. А люди, называющие себя full-stack разработчиками (и их слишком много), делают это, не имея соответствующей квалификации.
Претензии этого лагеря по поводу термина «full-stack разработчик» сводятся к следующим пунктам:
- Для компаний это способ выставлять нереальные требования к сотрудникам. Это позволяет им нагружать одного работника огромным количеством обязанностей, что для компании выгодно, но выгода достигается за счет работника. Компании хотят получать большой объем выполненных работ и большой опыт за низкую цену (по сравнению с наймом нескольких узких специалистов).
- Этот термин подразумевает общий уровень опыта, которого у большинства разработчиков нет. Настоящий full-stack разработчик должен обладать «двойным мастерством» – и во фронтенде, и в бэкенде – а это невозможно с учетом скорости развития технологий. Когда кто-то называет себя full-stack, имея опыт меньше упомянутого, это является необоснованным использованием термина.
- Это поощряет широкие, но поверхностные знания. Full-stack разработчик никогда не может с головой погрузиться ни в бэкенд, ни во фронтенд. Разработчик, пытающийся охватить весь стэк, это «и швец, и жнец, и на дуде игрец», причем ни в одной сфере он не достигает мастерства.
Представители этого лагеря сходятся на том, что настоящих full-stack разработчиков крайне мало. При этом они склонны считать, что люди, определяющие себя как full-stack, на самом деле являются фронтенд-разработчиками с некоторыми знаниями бэкенда (или наоборот).
Доводы в пользу full-stack разработчика
Лагерь сторонников full-stack, в свою очередь, ратует за более широкое понимание этого термина. Они отвергают идею, что full-stack разработчик должен обладать одинаковым мастерством в каждом слое стэка. Вместо этого ему нужно рабочее знание всего стэка и экспертное знание нескольких его слоев.
Определение full-stack с менее ограничивающим набором требований описывает человека, который способен:
- В определенной мере уверенно писать код и фронтенда, и бэкенда.
- Генерировать минимально жизнеспособный продукт самостоятельно или с небольшой поддержкой других людей при необходимости.
- Быть экспертом в нескольких технологиях.
- Показывать как минимум базовое понимание технологий, на которых не специализируется.
Другими словами, с этой точки зрения full-stack разработчик не должен быть экспертом во всех слоях стэка. Вместо этого он должен быть эффективным и опытным специалистом общего профиля. Это должен быть человек с широкой базой знаний, собственной специализацией и готовностью признавать отсутствие глубоких знаний в том, на чем он не специализируется.
В защиту термина «full-stack разработчик» приводится несколько ключевых соображений:
- Хороший разработчик не складирует свои знания. Большинство разработчиков занимаются либо фронтендом, либо бэкендом. Но чтобы быть хорошим специалистом в любом из этих направлений, вам нужно понимать оба. Проведение жесткого разграничения между ними охлаждает желание разработчиков изучать что-либо, выходящее за рамки собственной специализации. А ведь в каком-то смысле граница между бэкендом и фронтендом является искусственной.
- Компаниям нужны специалисты широкого профиля. Не всегда и не для всех бизнес-целей вам подойдет узкий специалист. Маленькие компании и стартапы, у которых количество людей и средств ограничено, нуждаются в разработчиках с обширным опытом и разнообразием знаний. Крупные компании более склонны поручать работу отдельным специалистам, но и они могут привлекать full-stack разработчиков в контексте менеджмента проектов.
- Full-stack разработчики наводят мосты между фротендом и бэкендом. Разработчики, специализирующиеся на каком-то одном из этих направлений, занимают свои ниши, но разработчики с full-stack знаниями помогают преодолеть пропасть между ними. Поскольку они понимают обе стороны, они могут определять проблемы и возможности, которые ускользнут от взгляда узкого специалиста.
Эти аргументы доказывают, что full-stack разработчики не заменяют, а дополняют работу специалистов по фронтенду и бэкенду. Их ценность – в способности понимать и работать со всем проектом в целом, а также использовать общие технические познания во всем, с чем они имеют дело.
Эту философию можно кратко изложить цитатой из «Программиста-прагматика»:
«Чем больше вы знаете, тем выше ваша ценность… чем больше технологий вы знаете, тем лучше сможете приспосабливаться к изменениям».
Общий знаменатель
Для тех из нас, кто среди дебатов пытается расшифровать понятие термина «full-stack разработчик», есть хорошие новости. Обе стороны сходятся во мнении, что full-stack разработчик должен понимать все слои стэка. Основное различие между дискутирующими в том, насколько глубокие знания каждого слоя должен проявлять такой разработчик.
С целью приближения к общему знаменателю, в недавно опубликованном Ассоциацией информационных систем документе был произведен анализ 5 самых общеупотребительных определений термина «full-stack разработчик». Это была попытка вывести общее определение термина. Вот, что получилось в результате:
«Full stack разработка это методология, охватывающая все слои стэка и при этом создающая полное, реализуемое решение требований бизнеса. Full stack разработчики обладают широким опытом работы во всех слоях стэка и экспертным уровнем знаний в некоторых из них. В заданном стэке они должны быть способны производить минимально жизнеспособный продукт», – «Towards a Consensus Definition of Full-Stack Development», 2018.
Если вы рекрутер или менеджер по найму и хотите направить дискуссию в конструктивное русло, вы можете предпринять следующие шаги:
- Убедитесь, что ваши запросы разумны. Никто из представителей обоих лагерей не ожидает, что full-stack разработчик сможет доставить результат, равный результату целой команды разработчиков. Если вы решаете, что для вашей команды разумно будет нанять full-stack разработчика, убедитесь, что вы не начинаете ненароком искать «единорога» и не просите одного человека сравняться по результатам со многими людьми. Самое важное: будьте готовы к тому, что может существовать больше одного набора навыков, позволяющих преуспеть в этой должности.
- Выясните, как в вашей компании налажена совместная работа разработчиков. Как члены вашей команды делят работу и кто их контролирует? Какой уровень гибкости в плане фронтенда и бэкенда они ожидают от каждого отдельного коллеги, хоть full-stack, хоть нет? Если рекрутеры и менеджеры по найму будут равняться на эту точку зрения, им будет легче понять, как должен функционировать full-stack разработчик в контексте их компании. Это поможет сделать процесс найма более эффективным.
- Ориентируйтесь на нужды своей компании. В целом, чем больше компания, тем более специализированные разработчики (и другие специалисты) могут в ней работать. Если ваша команда находится в процессе роста, учитывайте, как в ней будет работать full-stack разработчик – и не только сегодня, но и в долгосрочной перспективе, когда команда увеличится. В команде на 300 человек может быть больше места для full-stack разработчиков, чем в команде на 8 тысяч человек.
- Воспринимайте «full-stack» как примерный ориентир. Спектр мнений относительно трактовки этого термина предполагает, что full-stack разработчики могут быть очень разными. Если кандидат так себя называет, это еще не является показателем того, что он вам подходит. С другой стороны, кандидат, называющий себя фронтенд- или бэкенд-разработчиком, может иметь достаточно широкие познания, чтобы подойти на вашу full-stack позицию. Не игнорируйте терминологию, но и не слишком в нее упирайтесь, пускай навыки кандидатов говорят сами за себя.
А к какому «лагерю» относитесь вы и ваша команда? Поделитесь в комментариях!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]