Кто такой «Full Stack» разработчик?

Автор оригинала: Laurence
  • Перевод
Разумно ли ожидать, что каждый разработчик будет мастером в любом аспекте процесса разработки? Вероятнее всего нет, однако Facebook может потребовать от вас это. Будучи на конференции OSCON, работник Facebook сказал мне, что они нанимают только «Full Stack» разработчиков. Хорошо, но что это значит?

Для меня, «Full Stack» Разработчик — это кто-то, кто знаком с каждым аспектом: превосходно владеющий многими из них и проявляющий неподдельный интерес ко всем технологиям.

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

Составляющие «Full Stack»


1. Сервер, Сеть и Хостинговая Среда.

A. Включает в себя понимание того, что может сломаться и почему, ресурс принимается как должное.
B. Надлежащее использование файловой системы, облачных баз, сетевых ресурсов, а также понимание избыточности и доступности данных.
C. Как происходит масштабирование приложения при данных аппаратных ограничениях?
D. Что на счет мульти-поточности и состояние гонки? Знайте, что вы всего этого не увидите в ваших разработках, однако это может появиться и обязательно появится в реальном мире.
E. «Full stack» разработчики могут работать бок о бок с DevOps. Система должна обеспечивать осмысленные сообщения об ошибках и возможности сбора логов. DevOps увидят эти сообщения прежде вас, так что считайтесь с их мнением.

2. Моделирование Данных

A. Если модель данных некорректна, то бизнес-логика и более высокие классы начинают нуждаться в странном (безобразном) коде — костылях — для того, чтобы компенсировать исключительные случаи, которая эта модель не учитывает.
B. «Full stack» разработчики знают, как создать взвешенную реляционную модель вместе с внешними ключами, индексами, обзорами, справочными таблицами и т.д.
C. «Full stack» разработчики знакомы с концепцией не реляционных баз данных (NoSQL) и понимают, в чем они превосходят реляционные базы данных.

3. Бизнес-логика

A. Суть пользы приносимой приложением.
B. Здесь необходимы серьезные объектно-ориентированные навыки.
C. Здесь также могут понадобиться фреймворки.

4. Класс API/класс Action/MVC

A. Как взаимодействует ваша бизнес-логика и модель данных с реальным внешним миром.
B. На этом уровне, фреймворки должны быть максимально задействованы.
C. «Full stack» разработчики обладают способностью писать чисто, последовательно, просто для удобства пользователя. Меня пугает, до какой степени некоторые API бывают запутаны.

5. Пользовательский интерфейс

A. «Full stack» разработчики: а) понимают, как создавать читаемую схему, b) осознают, что нуждаются в помощи художников и графических дизайнеров. В любом случае, применение хорошего визуального конструирования — чрезвычайно важно.
B. Может включать в себя хорошее владение HTML5/CSS.
C. JavaScript — это восходящий язык будущего и большое количество захватывающей работы производится на JavaScript (node, backbone, knockout…)

6. UX

A. «Full stack» разработчики понимают, что пользователям необходимо, чтобы вещи работали просто.
B. Хорошая система не вызывает у своих пользователей кистевой туннельный синдром или раздражение глаз. «Full stack» разработчик может отстраниться и взглянуть на процесс, требующий 8 кликов и 3 шагов, а затем свести все это к одному клику.
C. «Full stack» разработчики пишут полезные сообщения об ошибках. Если что-то сломалось, извинитесь. Иногда программисты неумышленно пишут сообщения об ошибках, которые заставляют людей чувствовать себя идиотами.

7. Понимание того, что необходимо клиенту и бизнесу

A. В настоящее время область обязанностей инженера-разработчика не до конца ясна, однако это по большей части самостоятельная роль.
B. «Full stack» разработчики обладают глубоким пониманием того, что происходит, когда клиент пользуется продуктом. Они также обладают пониманием как устроен бизнес.

Другие составляющие головоломки:

1. Способность писать качественные юнит-тесты. К слову сказать, сегодня они могут писаться даже под JavaScript.
2. Понимание повторяющихся автоматических процессов, необходимых для построения приложения, его тестирование, предоставление документации, а также его масштабирование.
3. Важна информированность в вопросах безопасности, так как каждый класс по-своему уязвим.

Заключительные мысли

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

Технологические стартапы нуждаются в «full stack» разработчиках из-за их универсальности! Однако, с ростом организации, ей требуются все более и более специализированные навыки.

Я не уверен, можете ли вы называть себя «full stack» разработчиком, пока вы не поработаете на различных языках, платформах, отраслях промышленности. «Full stack» выходит за рамки «старшего программиста», это своего рода программист-полиглот, обладающий более широким видением всех составляющих. Заметьте, что в моем списке, к написанию кода относятся только 3-5 пункты.

Перевод выполнен в рамках летней школы стартапов Tolstoy Summer Camp.

Средняя зарплата в IT

110 500 ₽/мес.
Средняя зарплата по всем IT-специализациям на основании 6 970 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 79

    +12
    Если разработчик знает много всего и умеет это применять на практике это конечно очень круто, спору нет.

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

    Да и глубокое понимание технологий приходит именно на практике.
      0
      Да, но в таком случае где они находят таких специалистов?
      Получается, что это могут быть, либо молодые стартаперы, которые сами полностью подымали большой проект, где сталкивались со всеми этими вопросами. Либо это «супергуру», которые участвовали в средних или больших проектах. Причем не просто разработчиками, а принимали участие во всех аспектах разработки, и соответственно набрались опыта. Ну или это обычный программист работавший в обычной конторе, но кроме этого у него есть свой раскрученный сайт, есть несколько своих приложений под разные платформы, и еще у него большой опыт работы с базами данных.
      Много ли таких людей, и сколько тогда им платят?
        0
        Если б я знал где они их находят, если находят, я б тут не сидел))
          0
          а где бы сидели?
          +3
          Вы усугубляете. Важно понимать, что знание — это не «помнить наизусть», а действительно уметь искать и знать что можно найти. С последним очень помогает принцип «ничего невозможного не бывает».

          Далее, для примера, лично мой опыт, но не думаю, что я прямо-таки особенный.
          На первом месте я за три года:

          Погрузился в сети, достаточно неплохо выучил стек TCP/IP, очень глубоко HTTP (писал собственный сервер), более-менее UDP/ICMP и прочее около-вебовое.

          Набил руку на автоматах (собственные шаблонизаторы).

          Освоил *nix, без проблем могу проадминить удаленный веб-сервер (не уведя его в ребут с выключенным ssh :) ).

          Глубоко познал СУБД (в моем случае на примере MSSQL), спокойно в уме прикидываю узкие места запросов, нет проблем с индексами и прочими оптимизациями. Могу поднять partitioning и кластер.

          С головой погрузился в .NET, научился в уме просчитывать, во что транслируется тот или иной код (в плане CLR => Native), запомнил основные правила работы GC, на уровне моторики применяю всякие микрооптимизации. В свою очередь это потащило за собой WinForms, WPF, ASP.NET с одной стороны, и WinAPI и, в частности, GDI — с другой.

          ASP + п. 1 сильно упростил дальнейшее понимание веб-фрейморков вообще, так что изучение всяческих PHP, RoR, питонов не составило труда (прим.: тут технически некорректное предложение — имеются ввиду веб-решения). Причем, например, питон я теперь знаю очень глубоко — пришлось писать полностью свой веб-стек.

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

          Про JS я вообще молчу, в веб-разработке это must-have для client-side, что, естественно, заставляет интересоваться и node.js.

          Плюс куча всякой мелочи и эзотерики — разметка, css, erlang, haskell, flash, создание CDN, работа с соц. сервисами, UX и т.д.

          Итого: на данный момент практически по любой мейнстримовой технологии в области веба я в короткие сроки могу найти нужную информацию или вовсе вывести из головы как оно должно работать — и совпаcть в мнении с разработчиками этой самой технологии.
          Напоминаю — все это за три года.

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

          По поводу «сколько им платят»: да столько же, в общем, ну может быть процентов на десять больше в среднем. Слишком широкие специалисты, как и слишком узкие, нужны редко и мало где.
          Так что вакансии все те же, а разница з/п не такая сильная, чтобы играть сколько-нибудь значительную роль. Это скорее самому специалисту плюс, посколько позволяет тратить меньше времени/усилий/нервов на решение каких-то побочных задач (например, иногда проще самому исправить верстку, чем согласовывать задачу верстальщику и ждать от него результатов).
            0
            Толку в этих навыках? Я 13 лет с компьютерами, могу настраивать операционки от Novell Netware, Windows NT до Linux/BSD, работал с серверами различных размеров от подборки железа до сборки настройки профилактики. Протоколы писал на ассемблере, а винду облазил с софтайсом. Реализовывал прокси, http/ftp/smtp/pop3 сервера на ассемблере, парсеры сайтов на C#, понимаю «от ядра», как написать большую CMS, в разработке каковой участвовал и сделал пользовательский интерфейc. Писал программы под микрокалькуляторы, на бейсике, паскале, делфи, питоне, ассемблере, с. Работал в БД MySQL, MS SQL, Oracle.Сейчас же пишу на джаваскрипте под фреймворк ExtJs, понимаю верстку, но верстать могу только с дизайнером и по большей части с гуглом.
            Работал в таких критических ситуациях, что врагу не посоветуешь, всегда брал на себя ответственность за свою работу и свои ошибки. И что? Нормальную работу найти не могу, ибо все знания поверхностны, а углубляюсь в область только при необходимости технологии под конкретную задачу. + Теряюсь на собеседованиях напрочь. Итог — приходит товарищ, у которого в резюме охеренный опыт. А ничего углубленного ответить не могет. Вобщем…
            Хрен знает, мне кажется, чтобы реально хорошо знать ВСЕ эти технологии надо быть гением как минимум и иметь знания на уровне великого Онотоле.
            +3
            Было дело с фейсбуком. Не знаю откуда это информация, но проходил собеседование на Android разработчика. Их интересует не «full stack» кто бы это не был, а интересует человек знающий как решать олимпиадные задачки, сложность алгоритмов Big(O) ну и конечно же дизайн и полное понимание Android SDK.

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

            p.s.s. «знать где копать», как выразились ниже, никого не интересует. Показать свою работу — 2 месяца создал лаунчер, удивило и поразило их, меня конечно же проверили что это я сделал, кучей вопросов. Но всеравно отказ. Грубо говворя перед вами маркер, доска и 30 минут. Но было весело.
            +2
            За частую, важно лишь знать, что данная реализация задачи возможна и известно, где «копать» дальше.
              0
              Нет ничего невозможного. Это только вопрос времени.
            +4
            Не важно знать все, важно знать где найти информацию, за максимально короткий срок.
              +11
              Не всегда. Иногда ты не можешь найти информацию за короткий срок, потому что просто не знаешь о существовании той области, информация о которой тебе нужна.
                +1
                Тогда ты ищешь информацию о той предметной области, которая тебе необходима, а если это не получается, то врятли ты программист.
                0
                Важно не знать, а применять знания на практике.
                  +6
                  Что применять, если знаний нет?
                    +2
                    Что применять, если знаний нет?

                    Какой прок от этих знаний, если человек их не может применить?

                    Я не говорил, что знания не нужны, а лишь намекнул, что вы однобоко смотрите на вещи. Даже если человек мастер поиска, какой в нём толк, если он эти знания применить не может?
                      –5
                      Я как раз обобщенно смотрю на вещи, если человек не может найти информацию, то и применить он ее точно не сможет, а если хотя бы умеет добыть инфу, то хотя бы сможет ее применить, по крайней мере попытаться.
                      Full Stack — это человек, который может написать в резюме: «При наличие гугла — богоподобен».
                        +7
                        Тех, кто такое напишет, надо обходить дальней дорогой.
                          –2
                          Ага! И не забудьте перекреститься.
                            0
                            Если вы встречали Full Stack программиста, то не забудьте перекреститься тоже, их не существует. Равносильно обсуждать утопические взгляды.
                              +1
                              Наивное мнение. Никакого rocket science в указанных навыках нет, оно вполне естественно может получаться при эволюции разработчика.
                                +1
                                Проблема в том, что навык, который этот разработчик осваивал на заре своей карьеры, лет 10-50 назад, с тех пор успел несколько устареть. Чтобы соответствовать времени, он должен постоянно апгрейдить весь свой стек навыков (по крайней мере, тех, что ещё актуальны).
                                • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            простите почему еще?
                              +1
                              Простая психология и наблюдения на практике. Те кто о себе так пишут… почти никогда не имеют основания для этого. Хуже всего то, что такой человек не, имея адекватной оценки себя, нередко списывает свои огрехи на других раздувая из них большую проблему… В общем некомфортно с такими работать. Впрочем опыт из несколько иной, нежели программирования, среды, поэтому может несколько/сильно не соответствовать действительности, поэтому такое отношение остаётся моим личным мнением (с которым другие могут быть согласны, не со всем согласны, либо совсем не согласны) и не больше.
                                0
                                Да, ещё небольшое уточнение: настоящий full stack подразумевает под собой настолько широкий набор технологий и сфер знаний, что просто тяжело быть грамотным везде. Без грамотного понимания поисковик бесполезен — результат в лучшем случае будет далёк от идеала, о худшем даже говорить не хочется.
                                  +2
                                  Как же называется этот принцип?.. забыл.
                                  Суть в том что не имея достаточного уровня понимания, человек не может извлекать уроки из своих ошибок. Это порождает уверенность.
                                  С другой стороны, умный человек видит свои ошибки, поэтому сомневается — в частности, в собственных скиллах и возможностях.
                                  В результате, люди с низкой квалификацией часто обладают необоснованной уверенностью (Гомер Симпсон), а человек умный — неуверенностью и жёсткой самокритикой (Перельман).
                            +2
                            «При наличие гугла — богоподобен»

                            Звучит как «нет опыта» )
                              0
                              В каждой шутке есть доля шутки.)
                            • НЛО прилетело и опубликовало эту надпись здесь
                        +2
                        Не согласен. Если выходить на знания с большем уровнем абстракции, чем например написание библиотеки для чтения файла или как установить nginx под debian то уже не работает эта схема.

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

                        PS Я не говорю о том что надо знать все мануалы наизусть
                          0
                          Естественно, без опыта никуда, важно знать основные понятия и механизмы, а тонкости — частности.
                          0
                          Сильно зависит от задач и области ответственности. Для типовых и мелких задач это справедливо. Риски не так велики. Для сложных, комплексных — уже нет. Слишком много переменных. Без реального опыта искать придется долго, зачастую безрезультатно, придется наступать на грабли не раз и не два. Без хоть каких-то знаний вообще в предметной области, технологиях и инструментах искать становится просто бессмысленно.
                          +1
                          Неплохой набор знаний. 80% владельцев интернет-магазинов не отказались бы от такого работника. А, ну да, это же из сказки Пушкина.
                            0
                            Толстого, написано же
                            +2
                            надо было 8й пункт и название «Full stack» разработчика не существует =)
                            нет, я искренне верю, что такие люди есть, но их единицы, которые понимают весь процесс целиком. Уверен, что в том же Facebook'е таких людей много меньше общего числа разработчиков
                              +1
                              Смущает «перевод» — и фото Онотоле. Он уже в FB работает?
                                +2
                                FB на него работает.
                                  +2
                                  FB _на нём_ работает!
                                +5
                                У нас в компании тоже все разработчики взаимозаменимы. Но само собой у каждого есть своя специализация.
                                Например, любой бекэнд разработчик может сеть писать фронтенд часть, как и наоборот, но это будет медленнее и код будет чуть хуже. В итоге, если кто-то, например, заболел — проект не останавливается, он просто разрабатывается чуть медленнее.
                                  0
                                  Кстати, это часто повышает качество готового продукта/решения. Раз человек понимает, как должны (а не могут) взаимодействовать серверная часть и фронт-енд. Ну и подстраховка, конечно, тоже.
                                  +14
                                  Вообще у full-stack разработчиков, или ещё можно их назвать «человек-оркестр» есть проблема: всё делается медленнее (читай — дороже). Программист быстрее напишет код, а дизайнер быстрее сделает макет. И с поиском работы тоже проблема — ты и не кодер, и не верстальщик и не копирайтер… Это я по себе сужу.
                                    +1
                                    Зато гораздо меньше времени на общение и согласования, централизована ответственность, нет необходимости гнать человека в офис каждый день. Удобно и нанимателю и разработчику.
                                      0
                                      Зато всё больше времени уходит на переключение контекста между разными уровнями проекта: если сегодня тебя просят добавить ещё один канал данных в поток вывода бортового процессора, завтра — обработать этот канал в программе, послезавтра — использовать результат обработки для улучшения какого-нибудь алгоритма распознавания образов, а через неделю — добавить в пользовательское приложение панель управления этим каналом, то просто не хватает времени вспомнить все необходимые факты про очередной уровень. На документацию полагаться нельзя: на неё нет спроса (ведь общение не требуется), а следовательно, и времени :(
                                        0
                                        Мне кажется, что уровни проекта достаточно гармонично друг с другом перекликаются. А вот переключать контекст между различным функционалом — это действительно неприятно. Сегодня пишешь табеля, завтра — расчёт з/п, а послезавтра — вообще в ККМ лезешь. Когда же работаешь над, скажем, расчётом з/п, то хорошо понимаешь и бизнес-логику, и модель данных, и как нужно UI правильно для этого построить.
                                          0
                                          Да, но это если речь о громадных правках в разных местах. А так — круто за 5 минут уметь пофиксить баг в верстке и прислать человеку, который за нее отвечает, очевидный дифф вместо того, чтобы полдня объяснять где, что, при каких условиях воспроизводится.

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

                                          Ну и тому же пресловутому верстальщику тоже, думаю, иногда полезно посмотреть в базу данных, написать dummy-версию сервиса и уметь tcpdump-ить сетевое взаимодействие.

                                          ИМХО тут важно, что говорится именно о навыках, роль при этом у меня может быть вполне конкретная.
                                        +2
                                        full-stack разработчик не будет делать дизайн :-) Он всё-таки разработчик, пусть и многопрофильный, а не дизайнер и не художник, и даже не специалист по юзабилити. Впрочем, последнее он тоже может понимать достаточно неплохо, чтобы не отвлекать юзабелиста по мелочам.

                                        Насчёт «медленнее». Может, отдельную вещь он будет делать дольше. Однако, хорошо себе представляя цели проекта, характер взаимодействия между слоями/звеньями, он не будет постоянно переделывать из-за косяков во взаимодействии разработчиков, или ждать, пока бэкэнд-разработчики реализуют интерфейс или аналитик подправит ТЗ.
                                          0
                                          Ок, пусть я не full-stack ;-) Но как «оркестр» я часто делаю дизайн, не тот, «чтобы красиво», а тот, чтобы работал. А время приходится экономить путём более редкого переключения между задачами. Вот даже ответ Вам пишу после всех дел.
                                          0
                                          Здесь подразумевается всё же full-stack разработчик а не человек-оркестр. Разница в том, что он не верстальщик и уж точно не дизайнер. Такой человек может к примеру, утром написать патч к nginx, вечером захотфиксить пару багов в алгоритмах backend-а, а на следующий день запилить прикольный фронтенд на bootstrap + ajax для какой-нибудь внутренней утилиты.
                                            +1
                                            Мне, честно говоря, иногда сложно разделить, где заканчивается кодинг и начинается дизайн. В интерфейсах они часто переплетены. Когда я предлагаю вместо стандартного контрола взять select2, при этом чуть поправив заточив внешний вид и встроив в общую конву сайта — я выступил как верстальщик, программер или дизайнер. Короче — я запутался.
                                            0
                                            А у нас в конторе их называют не «человек-оркестр», а «слесарь-многостаночник»
                                            +29
                                            В немецком языке есть замечательное выражение «Eierlegende Wollmilchsau», дословно «яйценосная длинношерстная молочная свинья».

                                            Соответственно под спойлером портрет такого разработчика:
                                            Скрытый текст

                                              –2
                                              Пойду скину им резюме =)
                                                0
                                                Осталось найти компании которые готовы платить адекватное вознаграждение таким специалистам. А то даже facebook немного выше среднего по Долине.
                                                  +2
                                                  Для того чтобы обладать всеми перечисленными навыками нужно быть нехилым таким комбайном. Но мне вот думается что посадить подобного разработчика за рутину (любую) — уже не получится, он будет рваться на свободу. Кроме того, подобное широкое по охвату развитие возможно только если предметная область или стек технологий относительно стабильны — иначе всё время уйдёт на погружение в то и другое.
                                                    0
                                                    Насторожили слова понимание, надлежащее, знакомы, суть пользы и так далее. Все они подразумевают наличие судьи, а от компании к компании уровень судей значительно меняется.

                                                    Например знаком может варьироваться от читал и могу бустро разобраться до уже сделал небольшой проект.
                                                      0
                                                      Поп ему в ответ: «Нужен мне работник:
                                                      Повар, конюх и плотник.
                                                      А где найти мне такого
                                                      Служителя не слишком дорогого?»

                                                      мне кажется нужно просто чаще общаться с разными людьми/коллегами и обсуждать проблемы, как ваши, так и их. Зачастую решение находится именно на таких кофеболтологических посиделках. А иметь под боком человека, который знает все и всем владеет, удобно, но редко встречается. Да и как правило,
                                                      такие люди заняты выши крыши.
                                                        +1
                                                        Идеальный многорукий шива.
                                                          0
                                                          Человек оркестр знает 10 технологий и работает с ними 5 лет. 10 узкоориентированных специалистов знают по одной технологии и работают с ней 5 лет. Кто круче? 10 оркестров или 10 узких спецов? Я как классический пример оркестра сейчас понимаю что лучше б я 5 лет работал над чемто одним и прогрессировал.

                                                          Кто меня в ФБ возмет?
                                                            +10
                                                            Хм, интересно почему так негативно отреагировали почти все комментирующие. Кажется, это из-за недопонимания сути самого термина.

                                                            Не стоит представлять под «full stack» разработчиком некоего Васю, который делает сайты на Wordpress-е с подправленной, бесплатной темой.

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

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

                                                            Если взять за пример среднестатистического программиста с 10-летним опытом и предположить, что он работал над десятью проектами по году каждый, то полностью реальным видится достаточный для «фулл стека» опыт в фронтенде, серверах, базах данных, UX и архитектуре.
                                                              +2
                                                              +1. Правда, аутсорсинг там, где я его видел, к сожалению, не даёт знаний и навыков для действительно крупных распределённых систем (и, как следствие, понимания архитектуры для хайлоада — все эти блокировки и прочие шардинги). А так, при желании и способности разобраться во всём этом ничего сложного нет — объём вышеуказанных знаний для «full stack» и правда небольшой и «типичный».
                                                                +7
                                                                Я бы плюсанул если бы мог :)

                                                                Как-то все превратно понимают данное понятие. Человек может увлекаться множеством вещей в своей жизни и таковые совмещать.
                                                                Вместе со мной работал человек, который прикрасно разбирается в ассемблере, программирует на С++, пишет под Direct3D и OpenGL (ну хобби у него такое), при всем при этом знает РНР и писал для него плагины (реализация некоторых вещей на нативном С++ через библиотечные вызовы из РНР работает намного быстрее чем реализация того же самого на языке интерпретатора — минус в том, что надо было тащить этот свой модуль).

                                                                Обычная беда таких людей, что им очень трудно становится в жизни искать работу — когда читают такое обширное резюме, большинство работодателей начинают подкалывать — «а дворником и водителем трамвая не работали?»
                                                                Невдомек нынешним HR, что если инженер от природы имеет пытливый ум, то ему не сложно разобраться в сути любой технологии, а также понять механизмы и приемы работы с этой технологией.
                                                                Стандартное заблуждение — что если человек много умеет, то уровень его умений не будет высоким.
                                                                Желаю всем расстаться с этим заблуждением и почаще пробовать что-то новое! Разносторонний опыт никогда никому не шел во вред!
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                    0
                                                                    Где-то крутой совет читал: разделять в резюме навыки на активные (например «пользуюсь раз в неделю») и пассивные («раз в месяц» или «писал много, но с того момента прошло 2 года»).

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

                                                                    Еще совет читал из той же серии: писать только важное и главное, понимая, что резюме должно заинтересовать за первые 15 секунд прочтения. Я конечно, сам не суперспец по написанию резюме и не всех кадровиков готов оправдать (один раз мне дали лист 3-4-буквенных аббревиатур и спросили что из этого я «узнаю»). Но что-то в этом «умении себя подать» правильное и здравое есть.
                                                                  +1
                                                                  Вот откуда берётся fullstack. Допустим, есть у нас предметная область, мы тут же садимся и пишем бизнес-логику и на неё — юнит-тесты. Далее, когда не задумываясь, навешиваем на свои entity-классы JPA-аннотации (ну или не в Java — своими инструментами обходимся), оказывается, что приложение тормозит. Поэтому надо понимать реляционную модель. Либо иметь DBA, который понимает ещё и DDD. Далее, у того же Фаулера описано, какие могут возникать проблемы с распределённой системой (а таковой она становится, если клиент и сервер находятся на разных машинах), и проблемы с разграничением транзакций, тут же появляются remote facade, DTO. Ну а тут и до UI недалеко. Да и в том же DDD люди касаются вопросов построения UI, чтобы получился не банальный CRUD, а приложение, всё так же отражающее логику.

                                                                  Так вот. Между каждым из слоёв возникают нечёткие переходы. Поэтому нужно, чтобы разработчики как минимум понимали не только «свою» область, но и близлежающую. Иначе начнутся интересные вещи, когда либо апологет DDD пойдёт грузить entity миллионами на транзакцию, либо DBA сделает систему, «пляшущую» от данных, и потому несколько запутанную, либо UI-ник напишет фронтэнд, который будет гонять данные между клиентом и сервером в синхронном режиме тысячами мелких запросов. В нетривиальных вопросах каждого из уровней отдельный человек может разбираться лучше, но эти нетривиальные вопросы возникают не так часто, а в повседневности как раз нужно просто неплохо владеть пониманием, как всё устроено.
                                                                    +2
                                                                    Да-да, мне тоже пришла в голову первая мысль, что fullstack специалисты лучше справляются с протекающими абстракциями на стыках областей.
                                                                      0
                                                                      Но тут есть встречная опасность. Такому специалисту ничего не стоит при случае написать вызов или даже прямое обращение к полю объекта, пробивающее три-четыре слоя абстракций — просто потому, что сейчас это надо, а времени сделать всё правильно (и разобраться, а почему собственно такой вызов понадобился и не получается), как всегда, нет. Хорошо, если найдётся возможность глобального рефакторинга проекта. Но вероятность этого даже меньше, чем найти ещё одного подходящего full-stack разработчика в команду.
                                                                    0
                                                                    Таких людей не так уж и мало. Но тут как везде, есть крайности: на одной стороне действительно хорошие специалисты с широким кругозором, с другой стороны, как их любит называть мой отец, специалисты широкого профиля с узким захватом знаний. И первых, как и везде, меньшинство.

                                                                    Только вот таким людям оркестрам очень тяжело искать работу действительно по своему профилю. Чаще нужны либо эникейщики, либо специалисты с определенным узким профилем. Знаю очень хорошо, так как у самого очень обширный кругозор за пределами чистого программирования, и имею определенные трудности с удовлетворением потребности в использовании всего своего профиля знаний и умений.
                                                                      +2
                                                                      Судя по опыту, full stack developer, — обычно кандидат в techlead.
                                                                        0
                                                                        Ну тут же еще нужна любовь (желательно вместе с умением) к управлению. Один мой товарищ, когда вынужденно стал тимлидом, взвыл от необходимости гораздо более формально планировать и отчитываться о своей работе. Ну и куча народу есть, которая митинги всякие не любит, а тут уже не отмажешься.
                                                                          0
                                                                          В некоторых организациях должности techlead и teamlead различаются.
                                                                          P.S. Картинку умыкнул с javarush.ru

                                                                            0
                                                                            Ну я верю, что там побольше измерений будет на самом деле. Но не суть, просто обычно чем выше по иерархии, тем больше отчитываться и формальностей вообще, это не связано с full-stack-овостью. Например, если техлид — это почти архитектор, значит, вероятно, ему нужно как минимум с кучей народу согласовывать то, что он напридумывал.
                                                                        0
                                                                        Дожились. Продвинутые разработчики не знают, что обозначают термины full stack, empty stack. Терминам уж лет 30 точно.
                                                                          0
                                                                          Это перевод вот этого поста, который в оригинале я бы и читать не стал.

                                                                            +3
                                                                            Будучи на конференции OSCON, работник Facebook сказал мне, что они нанимают только «Full Stack» разработчиков.

                                                                            так вот почему в FB такой говно-UI, непредсказуемая новостная лента и куча багов
                                                                              0
                                                                              Попытаюсь выразить свои мысли таким примером:

                                                                              Зачем нам брать готовый и дорогой высокопроизводительный фабричный процессор «Мастодонт» который умеет выполнять миллион задач, когда можно спроектировать свой маленький процессор под одну конкретную задачу, который будет выполнять ее во много раз быстрее, чем процессор «Мастодонт» под миллион задач.
                                                                                0
                                                                                Я так понимаю оверхед на проектирование своего процессора, запуск его в производство, а также временные издержки покрывают с лихвой покупку процессора «Мастодонт»?
                                                                                  –1
                                                                                  В конечном итоге да — когда тираж изделия превысит миллион. За счёт большей производительности и функциональности спрос на продукцию будет выше, чем у конкурентов.
                                                                                    0
                                                                                    telteron, спасибо, что подкинули мне пищу для размышления. Я об этом даже и не думал. Но вот теперь стал задумываться.

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

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

                                                                                    P.S. Хорошая тема для статьи — Разработка единичного экземпляра vs. разработка для серийного производства — подходы, способы и методики.

                                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                Самое читаемое