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

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

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

Есть также ряд более общих вопросов, которые стоит задать:

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

Вот некоторые из моих мыслей об этом термине и вопросы, которые я поднял выше.

Фон

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • S.O.L.I.D (единичная ответственность, открытая/закрытая, замена, разделение интерфейса, инверсия зависимостей)
  • повторное использование, ремонтопригодность, переносимость, расширяемость, …
  • Горизонтальное и вертикальное масштабирование
  • Структура кодирования
  • Ведение журнала
  • Обзоры кода
  • …

Безопасность

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

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

Тестирование

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

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

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

CICD

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

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

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

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

Операции

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

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

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

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

Заключение

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

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

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

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

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

Дополнительный комментарий:

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

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