В последнее время словосочетание 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
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.