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

Когда я вижу такое утверждение в резюме или слышу, как кто-то называет себя полным стеком, на ум приходит ряд вопросов:

• Что вы подразумеваете под разработкой полного стека?
• Над каким стеком вы претендуете на господство?
• Насколько обширны ваши знания по каждому из элементов? Насколько полным он должен быть?

• Full-stack разработчик — это реально? Они действительно существуют?
• Если они существуют, почему они полезны?
• Является ли полный стек еще одним способом сказать «Мастер на все руки, мастер ни в чем»?

Задний план

Прежде чем мы углубимся в детали, стоит определить, что мы стремимся разработать и предоставить.

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

Если мы определим решение как производственную систему, обрабатывающую оперативные данные о клиентах и ​​производящую информацию/данные, способствующие созданию ценности для бизнеса, ситуация будет другой, и влияние ошибок кодирования или неэффективных практик будет намного выше.

Для целей этого поста мы рассмотрим систему, обрабатывающую большие объемы (10 ГБ в день) реальных данных о клиентах (включая PII) и предоставляющую ключевые бизнес-услуги с доступностью не менее 2,9 секунд.

Чем ценны full-stack разработчики?

Если отбросить в сторону существование таких людей, преимущества, которые они приносят, очевидны. Они могут проектировать, создавать и запускать решение без какой-либо внешней поддержки; это означает, что все эти трудоемкие и подверженные ошибкам семинары по проектированию, интеграции компонентов, циклам тестирования и передаче операций в значительной степени исключаются. Нет необходимости планировать встречу или, что еще хуже, серию встреч между службой безопасности, платформой, базой данных, операторами и т. д. SME, потому что вы можете спроектировать, построить и запустить решение. Небольшое количество таких богоподобных (маленьких g) разработчиков может выполнять работу большой кросс-функциональной команды, а благодаря устранению накладных расходов на передачу продукта доставка становится намного быстрее и менее подвержена ошибкам.

Итак, основываясь на этих явных преимуществах, почему во всех ИТ-организациях меньше команд, состоящих из этих людей? Почему компании не занимаются активным набором и обучением для создания таких команд ниндзя? Это потому, что эквивалентов Бэтмена или Тони Старка в разработке на самом деле не существует?

Чтобы ответить на эти вопросы, нам нужно посмотреть, как выглядит (очень) упрощенный стек.

Упрощенный стек

Я опускаю инфраструктуру платформы для упрощения.

Глядя на вышеперечисленные элементы, становится очевидным, что быть экспертом в каждом слое будет непросто. Однако, предполагая, что мне не нужно знать ВСЕ на каждом уровне, могу ли я уменьшить требуемые знания и по-прежнему считаться полным стеком? Взяв интерфейсное приложение в качестве примера домена, мы могли бы легко удалить Android и iOS и сосредоточиться только на веб-канале и, возможно, еще больше уточнить и сказать, что оно ограничено React, как это поможет?

Что мне нужно знать о веб-приложениях React, основываясь на нашей сокращенной области?

Ну, во-первых, вам нужно понять, как работают одностраничные приложения, особенно основные принципы, необходимые для создания, отладки и запуска веб-приложения, а также связанные инструменты, например, npm, webpack, управление контентом, реактивные инструменты разработки, рекомендации по UX,…

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

Как насчет производительности, например, времени до первой отрисовки контента, времени до интерактивного взаимодействия, времени блокировки… Должен ли я внедрять прогрессивную архитектуру веб-приложений и/или сервисных работников, чтобы помочь? Вам нужно будет понять факторы производительности и то, как различные основные шаблоны могут помочь в использовании инструментов для поддержки анализа, например, React DevTools или Lighthouse.

Доступность является обязательной для всех приложений, независимо от того, доставляется ли приложение внутри или снаружи. Как обеспечить соблюдение рекомендаций WCAG?

Таким образом, только на уровне Front-End нужно много знать, и, возможно, это делает его легким. Остальные слои ничем не отличаются, и во многих случаях их сложность возрастает. И что еще хуже, архитектурные шаблоны и принципы, лучшие практики и фреймворки НЕ ПЕРЕКРЫВАЮТСЯ .

Итак, если предположить, что мне удалось втиснуть шаблоны, стандарты, лучшие практики и практические навыки для каждого слоя в мою голову без взрыва, что еще мне нужно знать? Требуются ли какие-либо вспомогательные возможности?

Поддерживающие возможности

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

Архитектура и разработка программного обеспечения

Базовый набор навыков для поддержки архитектурного проектирования на всех уровнях, создание хорошей реализации на любом языке/фреймворке.

• SOLID (единичная ответственность, открытая/закрытая, замена, разделение интерфейсов, инверсия зависимостей)
• повторное использование, ремонтопригодность, переносимость, расширяемость, …
• Горизонтальное и вертикальное масштабирование
• Структура кодирования
• логирование
• Обзоры кода
• …

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

• API : TLS, DDoS, аутентификация и авторизация, COR, политика безопасности контента, …
• Микросервисы : TLS (включая MA), контроль доступа, управление секретами, проверка пользовательского ввода,…
• Данные : управление доступом, шифрование в состоянии покоя, управление ключами, группы безопасности сети и подсети, …
• Платформа (дополнительно) : сетевая безопасность, фиксированные конфигурации компонентов, например ChefInspec

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

Понимание и умение применять различные типы и этапы тестирования (без выставления оценок за домашнее задание):

• Функциональные и нефункциональные
• Черный ящик против белого ящика
• Модуль, интеграция, система, принятие пользователем, регрессия, дым, …

Разработка и поддержка конвейеров непрерывной интеграции и непрерывного развертывания

Основные инструменты для CICD часто создаются централизованной/выделенной командой, но каждый должен иметь возможность как минимум обновлять и поддерживать конвейеры. (Да, я знаю; если у вас есть команда DevOps, вы не занимаетесь DevOps, но многие организации этим занимаются)

Использование таких инструментов, как:

• Дженкинс, TravisCI, Spinnaker
• Гитхаб, Битбакет
• Сонаркуб
• Запрокси
• Веракод, Сник
• Докер, Якорь, Гавань
• …

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

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

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

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

Заключение

Я считаю, что истинный разработчик с полным стеком - это миф (в значительной степени), и он был им с тех пор, как стек вышел за рамки запуска ассемблера на 6502 в 1980-х годах. Не обманывайте себя, думая, что создание внешнего интерфейса и работа с несколькими API-интерфейсами, написанными на узле, работающем на узле K8, означает, что вы являетесь разработчиком полного стека.

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

Кроме того, эти люди, как правило, будут просить больше денег, чем большинство ИТ-организаций могут позволить себе заплатить им, но если они действительно работают с полным стеком, они того стоят — как гласит реклама.

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

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

Бонусный комментарий:

Что вам нужно знать, чтобы быть «более» успешным в качестве разработчика данных (обратите внимание на использование слова «разработчик» вместо термина «ученый данных» — я предполагаю, что вы уже хороший специалист по данным? А если нет, я тут ничем не поможешь!). Если мы определим этого разработчика как человека, который может развиваться в каждой из этих областей, но является экспертом в части науки о данных *, то есть моей сокращенной цели выше, индустриализация более широкого стека — это то, что сделал бы инженер по машинному обучению … но это обсуждение в другой раз.

* в нашем упрощенном стеке мы можем сказать, что модель немного связана с микросервисами… вроде