company_banner

Профессия: бэкенд-разработчик

    Для остановки нет причин — 
    Иду, скользя.
    И в мире нет таких вершин,
    Что взять нельзя.
    В. Высоцкий


    Если бы эта статья вышла не на Хабре, а в образовательном журнале, я бы начал её так: «Вспомните сайты, которые вам нравятся, на которых удобная навигация и приятный интерфейс. А знаете ли вы, что это только верхушка айсберга…». Но на Хабре это знают, пожалуй все, поэтому никакой лирики. Бэкенд любого веб-проекта — это сложная система, которая позволяет приложению быстро работать, качественно искать, шустро отдавать информацию пользователю, надёжно и безопасно хранить данные и при необходимости работать с другими внешними системами. Это как швейцарские часы: покупают их за стиль и шильдик, но ценители знают, что под сдержанным циферблатом кроется волшебный мир часового механизма. И бэкенд-разработчики — это маги механизмов, организмов, кишочек, внутренностей или как вы ещё это называете у веб-приложений. Эх, без лирики не удалось! 

    Короче, сегодня разбираем очередную профессию в серии «Профессия…». Итак, а что, если пойти в бэкенд-разработчики? 


    Бэкенд это всегда немного боль

    Кто это?


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

    Бэкенд-разработчик создаёт компоненты и функции, которые доступны пользователю приложения или сайта через интерфейс. Проще говоря, бэкендеры — это программисты, которые разрабатывают всё то, что не видит и напрямую не трогает пользователь. То есть красивая форма ввода данных или корзина интернет-магазина — это фронтенд, а хранение данных в СУБД, связка полей формы регистрации и корзины, интеграция с платёжным шлюзом, автоматические письма, подгрузка и обновление контента — это всё бэкенд. Поэтому, если форма регистрации стала отдавать ошибку базы, виноват… тестировщик :-) (почему— мы тоже расскажем в очередной серии).

    За что отвечает бэкенд-разработчик:

    • обеспечение корректной работы всех функций сайта и его вычислительной логики;
    • организация и работа с базами данных посредством СУБД;
    • разработка базовой логики и алгоритмов работы приложения;
    • API;
    • необходимые интеграции с внешними сервисами;
    • тестирование и отладка приложения и отдельных компонентов.

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


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


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

    Где нужен?


    Как и в случае с фронтенд-разработкой, абсолютно везде, где есть сайт или приложение, которое в вебе взаимодействует с пользователем. Другое дело, что всем нужны бэкендеры разного уровня: в офисе условной социальной сети или крупного сайта объявлений бэкенд-разработчик обязан не просто иметь базовые навыки, но и работать с высокими нагрузками, микросервисной архитектурой и контейнеризацией (Docker, Kubernetes), знать системы мониторинга (типа Zabbix, Grafana), иметь навыки Scrum (опционально для конкретных компаний). А для небольшого интернет-магазина вполне достаточно связки PHP-Ajax-нужная СУБД-немного HTML, иногда и того меньше. Понятно, что и оплата труда, и требования к опыту также совершенно разные. 

    Традиционно на «Хабр Карьере» мы нашли 444 вакансии бэкенд-разработчика, что без малого в 2 раза больше, чем во фронтенде. На hh.ru — около 1800. В общем, на рабочих местах вас уже ждут фронтендеры, у которых поиск по сайту отрабатывает два часа :-) А если серьёзно, в компании может быть 2-3 бэкенд-разработчика на одного фронтенда, особенно если речь идёт о приложениях со сложной внутренней логикой и бизнес-логикой (интернет-магазин, CRM-ERP, корпоративный портал и т.д.).

    Средняя заработная плата


    Заработную плату будем смотреть тоже на «Хабр Карьере». Возьмём данные за второе полугодие 2019 года, вне зависимости от владения тем или иным стеком. 
    Уровень специалиста
    Средняя заработная плата
    Стажёр (Intern)
    35 345 руб.
    Младший (Junior)
    55 241 руб.
    Средний (Middle)
    105 048 руб.
    Старший (Senior)
    168 350 руб.
    Ведущий (Lead)
    185 335 руб.

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

    Базовые требования к профессионалу


    Требования к бэкендеру ещё более чувствительны к особенностям компании и её бизнес-процессам, чем у фронтендера. Иногда это могут быть весьма странные на первый взгляд вещи такие как «понимание принципов работы рыбного холодильника как предприятия», «знание основ продаж или опыт в продажах», «блестящее знание JavaScript, CSS и HTML». Но это выглядит безумно и отталкивающе только при первом подходе. На самом деле, бэкенд-разработчик действительно больше погружён в бизнес-процессы, должен не только разрабатывать код в соответствие с ними, но и подстраивать какие-то вещи под конкретные задачи, понимать, как оно работает изнутри. Если вы никогда не видели воронку продаж и не понимаете, чё это за фигня, вы никогда не сможете разработать её логику вместе с фильтрами, срезами и переходами (даже если у вас будет отличное ТЗ, разобраться сложно). Ну а в примере с «блестящее знание JavaScript, CSS и HTML» всё просто: вероятно, руководитель не очень-то доверяет своему другому разработчику и готов пересмотреть подход к разработке. Такое нередко случается в небольших компаниях. 

    Но есть и базовый набор требований, который бэкенд-разработчик увидит практически в любой вакансии.

    • Знание хотя бы одного «серверного» языка программирования: PHP, Go, ASP.NET, C/C++, Python, Ruby, Java. В некоторых случаях достаточно знания JavaScript для бэкенда (Node.js), но это скорее как плюс, чем как пункт.
    • Знание API (REST, SOAP — всё реже).
    • Понимание принципов работы серверов Apache, NGINX, IIS и проч.
    • Навыки написания юнит-тестов и покрытия кода тестами.
    • Основы сетевой безопасности и знание инструментов её обеспечения.
    • Знание популярных веб-фрейморков, которые способны решать задачи разработки конкретного приложения.
    • Навыки написания запросов к БД и проектирования баз данных.
    • Знание основ фронтенда — и это не плюс, а обязательный пункт, иначе вам придётся крайне непросто проектировать и писать приложение.

    Огромным плюсом как к резюме, так и к вашей реальной работе будет ещё один набор знаний.

    • Администрирование UNIX или знание Linux (можно любого одного дистрибутива).
    • Знание принципов работы HTTP (кэширование, авторизация, структура сообщений, заголовки, коды ответов и проч.)
    • Модель OSI. 
    • Навыки составления и оценки технического задания (ТЗ) — очень важный навык, который необходим для сбора самой точной информации о требованиях к ПО. 

    «Да офигеть!» — скажете вы и будете правы. Однако у меня есть хорошие новости: средства разработки бэкенда меняются гораздо медленнее, чем фронтенда, равно как и требования устаревают долго. Так что один раз освоил — и почитывай дайджесты, чтобы в целом быть в курсе дел, но особенно не кипишить из-за того, что флэт-дизайн вошёл в моду, а карточка товара на твоём сайте уже два дня как не в тренде :)

    Кстати сказать, среди бэкендеров много хороших, крепких математиков, потому что бэкенд-разработка — наука точная, и качество результата сильно зависит от того, насколько выверены будут выбранные вами и применённые алгоритмы, паттерны, циклы, функции и т.д.
    Стажёр (Intern)
    Младший (Junior)
    Средний (Middle)
    Старший (Senior)
    Ведущий (Lead)
    1. C++
    2. C#
    3. Golang
    4. SQL
    5. .NET

    1. PHP
    2. Python
    3. Java
    4. Java spring framework
    5. PostgreSQL

    1. PHP
    2. Python
    3. Java
    4. PostgreSQL
    5. Java spring framework

    1. PHP
    2. Java
    3. Python
    4. PostgreSQL
    5. Java spring framework

    1. PHP
    2. Java
    3. MySQL
    4. PostgreSQL
    5. Высоконагруженные системы

    — 
    + ООП, фреймворки

    + ООП, фреймворки, Docker
    + высоконагруженные системы, ООП, фреймворки, Docker
    + Linux, ООП, фреймворки, Docker
    Топ-5 востребованных технологий у специалистов по данным «Хабр Карьера», 2 полугодие 2019 года, нижняя строка — «дополнительные» скиллы.

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

    Как видите, компании готовы брать стажёров с базовыми вузовскими C, C++ и C#, но в дальнейшем предпочитают специалистов с «рабочим набором» бэкендера. Обратите внимание на интерес к контейнеризации и высоконагруженным системам. 

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


    Важные личные качества


    Бэкендеру хорошо, он может быть интровертом :) Его зона работы с пользователями сведена до минимума, в основном, все рабочие контакты с менеджерами или коллегами. Эти ребята нередко работают по ТЗ и делают всё так, как это прописано в документе либо так, чтобы получить состояние, максимально близкое к целевому (ТЗ, знаете ли, тоже бывают несовершенны, а то и совершенно не…).

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

    • Ответственность. Действительно, на бэкендере лежит ответственность буквально за всё: чтобы данные сохранились, чтобы реляционные таблицы работали как надо, чтобы временные пояса учитывались, чтобы сайт был шустрым и т.д. И если кривая навигация от фронтендера приведёт к паре злобных вскриков пользователей, то ошибка бэкендера может стоить очень дорого — в прямом смысле (например, если бизнес-данные по какой-то причине перестанут сохраняться или не сработает разделение прав доступа в какой-нибудь CRM-системе).
    • Внимательность и внимание к мелочам. Опять же, мелочей в бэкенде не бывает, поэтому необходимо тщательно проектировать связность работы всех компонент и не упустить ничего.
    • Трудоспособность. Прокрастинация — опасный враг бэкендера, он должен уметь сосредоточенно работать, иногда в крайне сжатые сроки, поэтому «пилить код с ленцой» это, пожалуйста, в пет-проект или уже в состоянии тимлида (там других задач хватает).
    • Логическое мышление и аналитический склад ума. Оно и понятно.
    • Умение доводить дело до конца, нацеленность на результат. В бэкенде важен результат — корректно и ожидаемо работающее приложение.
    • Способность переключаться на макрозадачах. Нередко бывает, что нужно оставить код одной части проекта и реализовать довольно крупную функцию. Это непросто, потому что программист уже погружён в архитектуру и логику. Способность переключаться без особых проблем для задач — практически джедайская. 
    • Навыки планирования и исполнения плана. Бэкенд любого проекта — это сборник разноплановых задач. И если вы единственный бэкендер проекта или у вас с коллегами слабо реализовано разделение труда, только планирование и спасёт от авралов, факапов и срыва дедлайнов. Жёсткое к себе и времени планирование — залог спокойной работы практически без переработок (которые у бэкендеров случаются чаще остальных).
    • Умение работать в команде. Вам нужно будет взаимодействовать с единой командой разработки единого же приложения, а значит, дискуссии, но не конфликты, рефакторинг, но не оскорбления, отстаивание своей позиции, но не бойкоты. Если злой интровертный бэкендер отлично сделает свою работу, закоммитит и умоет руки, его труд пользователи ещё долго не смогут оценить — потому что нужно «собирать» проект в составе всей команды, а не отгораживаться по принципу «к фронтенду ни ногой».

    Необходимость знания иностранных языков


    Вот что было написано для фронтенд-разработчика.

    Для любого программиста крайне желателен английский язык не ниже upper-intermediate с уклоном в технический английский. Так вы сможете читать в оригинале многочисленные рекомендации Google и других компаний для оптимальной разработки (очень много полезной документации!), самообучаться с помощью зарубежных лекций, общаться с коллегами на форумах, задавать вопросы, а также читать книги по юзабилити и дизайну, среди которых очень много крутых англоязычных и пока не переведённых изданий. 

    Это же справедливо и для бэкендера, даже в большей мере. В комментариях к предыдущей статье заметили, что уровень upper-intermediate великоват для айтишника, достаточно и ниже. Я сужу по себе и по уровню учебников. Скажем так, от intermediate до upper-intermediate шаг не выглядит пропастью и уровень «на поболтать» берётся легко. А вот от upper до advanced — пропасть и по сложности, и по лексике. Впрочем, если вам норм читать и понимать, что читаете при другом уровне, никто вас экзамен сдавать не заставит, пользуйтесь. 

    Где учиться


    В принципе, те же технические вузы, курсы, самообразование и корпоративные университеты. Но есть важные нюансы.

    • Если фронтент-разработчиком можно стать и после непрофильного вуза (строительство, дизайн, экономика и проч.), то бэкендером гораздо сложнее. Идеальная образовательная основа для бэкенд-разработчика — математическое, физическое и собственно ИТ образование. Именно они дают отличную базу для понимания алгоритмов, функций, паттернов, вычислительных процессов и т.д. 
    • С курсами дело обстоит тоже печальнее — вы можете начать изучать какой-то язык (например, PHP или Java) и даже сделать какой-то фуллстековый мини-проект, но только опыт реальной работы даст полное понимание функционирования и взаимодействия всех компонентов, потому что у бэкенда слишком много деталей и подводных камней (даже несмотря на крутые инструменты разработки).
    • Именно для бэкенда лучшим образовательным путём мне видится изучение основ серверного языка и путь от стажёра в компании, где есть наставник/ментор по специальности. На реальном проекте и узких задачах вы быстрее поймёте, что к чему.
    • Никто не отменяет небольшие open source проекты, в которые можно коммитить.
    • И, конечно, должен быть свой сайт (пет-проект), который станет главным тренировочным плацдармом. Путь предстоит не самый простой, поэтому выбирайте ту тематику, которую, кроме самой разработки, вам будет интересно развивать. Например, если вы увлекаетесь спортом и здоровым образом жизни, разработайте приложение-дневник со счётчиками, коннекторами к каким-нибудь датчикам, ачивками и т.д. Это будет полезно и увлекательно (а иногда из таких сайд/пет проектов вырастают коммерчески успешные стартапы). 


    Лучшие книги и средства обучения


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

    • Базовая книга по вашему языку программирования — мне нравятся издания O’Reilly, многие переведены издательством «Питер». 
    • Аналогично базовые книги по вашему стеку. 
    • Кукбуки (cookbook) по языкам и рекомендации корпораций, статьи в блогах и т.д.
    • Бек Кент, Экстремальное программирование. Разработка через тестирование — отличная книга для любого разработчика в принципе, но особенно для бэкендера. Проникнуться философией TDD дорого стоит.
    • Джоэл Х. Спольски — можно читать его блог, можно ещё на просторах Рунета найти электронную книгу «Джоэл о программировании» — сборник постов из блога на русском.
    • Роберт Мартин «Идеальный программист», «Чистый код» — переводная книга от «Питера» хороша, но в оригинале стиль и шутки вообще бесподобны.
    • Мартин Фаулер и коллектив авторов «Шаблоны корпоративных приложений» — «взрослая» книга для джавистов, но не помешает ни для одного серверного языка как сборник инсайтов и крутых находок.
    • Бесплатные курсы и видео, которых бесконечно много на Youtube на русском и английском языках. Просто слушайте, повторяйте, систематизируйте знания. Для начала подойдут любые, очень скоро вы научитесь отличать крутые вещи от дилетантских. 
    • webref.ru — очень классный сайт для разработчиков веба, разбирайтесь, обучайтесь. 
    • codecademy.com — интерактивный сайт для обучения разработке на разных языках программирования на английском, с самого низкого, нулевого, уровня. 
    • ITc | сообщество программистов — вагон организованной информации с курсами, лекциями и чем угодно. Читайте комментарии, легко определяйте лучшее для обучения.
    • Библиотека программиста — куча книг по любой айти-тематике.

    Почему я делаю упор на книги? Во-первых, они профессиональны, во-вторых, их можно удобно держать под рукой, делать пометки и клеить стикеры, быстро возвращаться к нужной информации. Это удобный и доступный для мозга формат подачи информации. Если на себе не проверяли, обязательно попробуйте, получите удовольствие!

    Будущее бэкендера


    Будущее бэкендера прорисовывается довольно чётко и перспективно.

    • Стандартный путь внутри своего стека: junior с односложными задачами и запросами, middle с глубокими навыками программирования и отличным владением стеком, senior с проектированием, архитектурами, высокими нагрузками и прочим кубернетесом, team lead с управленческими навыками т.д. Это хороший корпоративный путь, внутри которого можно менять компании, проекты, отрасли, расти и быть востребованным.
    • Переход на другой стек и выход из веба: нередко именно бэкенд-разработчики осваивают Java, С/С++ и уходят в «кровавый энтерпрайз», десктопные приложения, разработку средств разработки, нейросети, компьютерное зрение и т.д. Действительно, бэкендеру проще осваивать эти трудные технологии и ЯП.
    • Переход в фуллстек-разработку: бэкендер ближе к фуллстеку и совершить такую трансформацию можно совершенно незаметно.
    • Переход в DevOps, DevSecOps, информационную безопасность — когда знаешь веб-приложения изнутри как свои пять пальцев, этот путь оказывается логичным и весьма доходным.
    • Переход на менеджерские позиции, если есть желание и склонность к управленческим задачам. 
    • Фриланс и своё программное агентство — для смелых и в меру азартных ребят. Можно неплохо зарабатывать на аутсорс-разработке (особенно если идти в сторону фуллстек-разработки).

    Я вам больше скажу: если в 2020-2022 вы освоите SQL и любой «бэкендовый» язык программирования, вам будет хорошо и в 2032. И дело здесь не в поддержке легаси, а в том, что пока нет достойной альтернативы вебу, а если она и появится, у бэкендера гораздо больше шансов на то, что его стек придётся к месту.

    Главное, что у вас не выйдет — это быть плохим разработчиком и при этом рассчитывать на что-то интересное. Дело в том, что каждая компания ждёт от бэкендера ответственности (представьте себе ошибки в коде банковского приложения, какой-нибудь критически важной ГИС или системы онлайн-мониторинга — сразу поседеть можно) и здравого подхода к работе. Филонить или говорить «так задумано» вряд ли получится — при всей внешней незаметности работы бэкенда сбой в ней заметнее всего.

    Мифы профессии


    ▍Бэкенд — это очень сложно


    Спорный вопрос. Часть разработчиков утверждают, что он проще благодаря средствам разработки, бесчисленным библиотекам и низкому уровню динамичности, другая часть боится подойти к бэкенду в принципе. Правда, как всегда, посередине: скорее, стэк бэкенд-разработчика многообразен и имеет разнородные компоненты, но, во-первых, не всё нужно в проекте, во-вторых, стоит понять что-то одно, и вот уже все взаимосвязи очевидны, знания нанизываются на единый стержень. В любом случае попробовать себя в бэкенде нужно — даже если вы развернётесь и выберете другой тип разработки, полученные знания помогут вам в работе.


    ▍Бэкенд-разработчик получает миллионы


    Это вообще общий миф про программирование. Самая большая реальная заработная плата у российского разработчика, которую мне приходилось видеть своими глазами — это 540 тыс. руб. в месяц (С/С++, зарубежный проект, системы компьютерного зрения, кандидат наук, удалёнка), вторая от него — 400 тыс. руб. (Delphi, удалёнка, зарубежный энтерпрайз, немецкий язык как нативный). Остальные очень похожи на те цифры, которые я взял с «Хабр Карьеры» для своих табличек. Миллионы получать вы будете только в том случае, если сойдётся: блестящее знание языка + талант + опыт и уникальные навыки в узкой сфере + проект, готовый столько платить. Таких ребят единицы и я не скажу, что их участь прекрасна: 99% их жизни работа, 1% — сон. Поэтому важно осознать другой тезис: бэкенд-разработчики востребованы и хорошо зарабатывают, лучше многих специалистов. Значит, стоит постараться.

    ▍PHP — г@вно, PHP мёртв, PHP must die


    Обожаю этот холивар! Но при этом знаю, как его пугаются новички и стремятся обойти этот мощный и во многом удобный язык и его фреймворки. Дело в том, что в начале 2000-х-2010-х PHP был крайне популярным языком программирования у фрилансеров и прочих джентльменов удачи от ИТ. На нём написано море плохих дилетантских сайтов и приложений — но не потому что язык плохой, а потому что эти ребята не были способны использовать его изящно и грамотно. Оттуда и пошли эти мифы про «плохость».

    Конечно же, PHP прост в изучении, живее всех живых, на нём написаны и поддерживаются сотни тысяч проектов, проектищ и проектиков и жить ему ещё довольно долго. Согласно Stackoverflow PHP выбирают 25.8% профессиональных разработчиков. Да и по Octoverse GitHub язык довольно стабилен по количеству проектов:


    К слову, по-настоящему хорошие программисты PHP высоко ценятся во всех смыслах этого слова.

    Главный совет


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

    Ну что, есть среди читателей опытные бэкендеры? Как оно? Почему выбрали именно эту сторону разработки?



    Ах, да:

    Профессия: фронтенд-разработчик
    Профессия: системный администратор
    RUVDS.com
    RUVDS – хостинг VDS/VPS серверов

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

      +10
      Как-то давно дали мне задание сделать простенькую страничку (на основе другой). Что-то там накопипастил и получил результат. И мне говорят что в другом браузере работает неверно. В тот день я окончательно понял что фронтенд совсем не для меня.

      Вот так я и стал бэкендером.
        0

        Сегодня таких проблем радикально меньше.
        Тем более что на беке свои танцы с бубном.
        А где интереснее/сложнее/больше платят зависит от проекта.
        Я бы весы, в среднем сдвинул в сторону бека, но в конечном итоге все зависит от человека и его умения договариваться искать правильный проект.
        P.S.
        Тем более сегодня клиентское ПО сильно усложняется и уже 50% вакансий это разделение верстки и программирование на JS.

        0

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

          0
          И на фронте и на бэке свои плюшки. У фронтов постоянные проблемы типа «а на моем телефоне не работает».
          На бэке — сопровождение «поставку не согласуем т.к. фукнция xxx жрет 30% процссорных ресурсов выделенных заданию что недопустимо».

          Или как недавно было — все тесты прошли, включая нагрузку, а на проме упало. По джоблогам и дампам примерно понятна проблема, но воспроизвести не удается никак и нигде. Соответственно, подозрительный участок кода переписан, но внедряться страшно т.к. проверить что помогло не получается.

          А модуль работает в таком участке, где лажать нельзя — прокол может обернуться штрафом со многими нулями от регулятора (в лучшем случае).
            0
            интровертам в бэке комфортнее: никто не пристает с «поехавшим дизайном в браузере ХХХ» и можно спокойно вылизывать свой код (в идеале, конечно).

            Ну…
            Мне например приходится время от времени вступать в дискуссии с project owner потому что он считает, что всю работу в бекенде можно сделать быстро и дёшево и уже вчера. А я просто цену себе набиваю.
            Не видя визуальной части, он считает, что тут на бэкенде как бы ничего и не делается.
            Фронтендеру-интраверту, имхо, проще — ничего объяснять не нужно, всё видно.
              0
              Тут скорее проблема в конкретном project owner'е. Если менеджер действительно толковый, то таких проблем не возникнет… Ну или у данного товарища в голове есть мысль о том, что раз бэкендеры интроверты — можно и нужно их давить своим менеджерским авторитетом как по цене, так и по срокам
            +3
            Всегда скучно было рисовать интерфейсы. Ну не мое это. А вот колупаться в потрохах, системных API, быть близко к железу, в том числе и нестандартному, это нравилось и нравится.

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

            Хотя к вебу никакого отношения не имею и не имел. Долгое время занимался разработкой системы мониторинга инженерного оборудования зданий. Система была гетерогенной, распределенной, построенной на микроядре. Т.е. в центре некое ядро, к нему цепляются и через него общаются удаленные микроконтроллеры (IP-шлюзы, за которыми уже на 485-м интерфейсе висели контроллеры нижнего уровня) и удаленные же интерфейсные клиенты (различной тематической направленности). Там занимался тем самым микроядром — архитектура, протоколы обмена и все прочее.

            Сейчас банк. Ядровые функции автоматизированной банковской системы. То, что работает на мейнфрейме IBM i. В общем случае все, что работает на фронтах, общается с АБС через вебсервисы. Которые вызывают некие универсальные процедуры на мейнфрейме, а те уже дергают различные обработчики — вот их и пилим.
              0

              как тесен мир!
              это я про веб-сервисы, которые дергают EQ :)

                0
                Так понимаю, тоже там? :-)
                0
                Можно узнать, а какой стек на IBM i?
                  0
                  Это бывшая AS/400 со всеми вытекающими. ILE, включающая в себя CL, RPG, COBOL, C/C++ (компиляторы встроенные, любой программный объект может содержать несколько модулей на разных языках, главное правилтно интерфейсы прописать, функции сишной RTL можно высывать, например, из программ на RPG). Отладчик встроенный, БД встроенная, DB2.
                  Пишем в основном на RPG, но бывает и на С, если это удобнее. Достаточно много сервисных программ написано на С/С++.

                  Средства разработки — RDi (IDE на базе эклипса, заточенная на работу с ас-кой. Т.е. пишешь на обычном компе, потом оно все забрасывает на сервер и там собирает. Для пущего удобства приручен gradle — пишутся сборочные скрипты, которые обрабатываются плагином.

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

                  В целом как везде — есть типовые задачи, а есть такие, над которыми думать надо.
                    0
                    Интересно, спасибо.
                      0
                      Да не за что. Система очень мощная не похожая ни на что другое (концептуально она объекно-ориентированная — «все есть объект»). И самодостаточная. Т.е. в ней сразу есть все что надо. И компиляторы и отладчик и БД и инструменты администрирования.

                      Если кому интересно — книга одного из отцов-основателей: Френк Солтис «Основы AS/400». От истории создания до внутреннего устройства весьма доходчивым языком.

                      От ILE (Integrated Language Environment) просто в восторге. Поскольку до этого без малого 30 на С/С++, то возможность часть задачи, там где это удобнее, писать на С, а часть на RPG очень радует. В целом работа с таблицами, строками, экранными и принтерными формами на RPG удобнее, а вот всякие системные вещи типа организации распараллеливания с межпроцессным взаимодействием через сокеты, динамические массивы и списки — это удобнее на С/С++.

                      Пишешь кусок кода на RPG, кусок на C/C++. Потом каждый кусок компилится в отдельный модуль (аналог объектного файла) и потом уже все модули собираются в единый программный объект.
                        0
                        Я относительно неплохо был знаком с System/370 (MVS, VM), но AS/400 уже не застал, потрогать руками не довелось. Знаю только, что принципиально отличается во всём, совершенно другая система. Поэтому было интересно в общих чертах узнать. :)
                          0
                          Собственно это система, которую все хотят создать — но ни у кого не получается. Потому что, как бы, даже здесь видно: всё зашибись, классно, «в ней сразу есть все что надо»… вот только среда разработки… оп-па — на базе Eclipse на совсем другой операционке.

                          То есть уже видно, что оно нифига не самодостаточное — вот те задачи, которые решили на нём поддержать разработчики — те и нормально отрабатываются. А что «не шмогли» (или не захотели) — того и нету вообще.

                          А вот для персоналок (или смартфонов) — такой подход не прокатывает. Так как они зачастую — единственная железяка, которая у пользователя есть. Соответственно если что-то на вашей платформе нельзя сделать, а на платформе конкурента можно… так и всё, собственно. Вы проиграли.
                            +1
                            Система самодостаточна в рамках своего предназначения — высокопроизводительные коммерческие серверы.
                            Саодостаточность в том, что в нее все необходимое уже интегрировано на уровне самой системы. Т.е. таблица БД это не просто файл, но системный объект.

                            Там сразу будет и БД и компиляторы и отладчик. И да, есть SEU — редактор для написания кода. Есть интерактивный SQL.
                            Но это сервер. У него нет монитора, нет клавиатуры. Общение с ним идет черех удаленный терминал IBM5250 или его программный эмулятор. Там все хардкорно — текстовые менюшки и команды языка CL.
                            Понятно, что через RDi работать удобнее. Хотя можно пользоваться любой средой, есть любители Visual Code, кто-то вообще в Notepad++ пишет. Без разницы, если настроишь гредл.
                            Есть проект, в нем исходники плюс скрипты под гредл плагин. Написал, потом gradle as400syncdeploy и оно само сгенерируе программу инсталлятор, забросит все на сервер, скомпилирует и запустит там инсталлятор.
                            Просто в RDi это делается нажатием кнопки, а к другой среде или прикручивать в инструменты или просто запустить из командной строки.
                            Это нормальная кроссплатформенная разработка. Это свой мир со своими порядками.
                              +1
                              … оп-па — на базе Eclipse на совсем другой операционке.


                              А что не так?
                              Почему вы считаете минусом, что система, где установлено ПО разработки отличается от целевой системы?

                              Например, чтобы разрабатывать на целевую ОС Android удобно запускать среду разработки вовсе не на смартфоне.

                              Или для микроконтроллеров — вы бы тоже предпочли IDE на микроконтоллере самом запускать? Через маленький индикатор, подключенный к микроконтролеру, смотреть свой код и 3-мя кнопками управлять этой IDE?
                                +1
                                Там, кстати, очень много софта идет в комплекте именно для кроссплатформенной разработки.

                                Ставится IBM Installation Manager, а потом уже через него много чего можно поставить. WAS для запуска вебсервисов, которые будут работать с аской, RAD — тоже на базе эклипса, но заточена под разработку вебсервисов.

                                Access i Client Solution — пакет где эмулятор терминала, интерактивный sql, средство для просмотра спулов (вывод на принтер), средство для работы и файлами бд…

                                Там очень много софта, позволяющего работать с сервером. А сам сервер… Такая дура размером с большой холодильник. Ниимонитора ни клавиатуры там нет.
                                  0
                                  А что не так?
                                  Почему вы считаете минусом, что система, где установлено ПО разработки отличается от целевой системы?
                                  А где я сказал, что это плохо?

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

                                  Например, чтобы разрабатывать на целевую ОС Android удобно запускать среду разработки вовсе не на смартфоне.
                                  Тем не менее среды разработки, работающие на смартфонах тоже существуют — и именно этот факт «развёл» в своё время BlackBerry, Windows Phone — и Андроид.

                                  Или для микроконтроллеров — вы бы тоже предпочли IDE на микроконтоллере самом запускать? Через маленький индикатор, подключенный к микроконтролеру, смотреть свой код и 3-мя кнопками управлять этой IDE?
                                  А что — кто-то где-то когда-то позиционировал микроконтроллер как нечто самодостаточное?!
                                    0
                                    Вы, наверное, не так поняли.

                                    RDi здесь поставляется всего лишь как IDE для более комфотной разработки. Никто не мешает писать текст прямо на сервере, пользуясь встроенным редактором SEU. Сборка программы в любом случае происходит на сервере. Вне зависимости от того, где пишется ее текст. Если работаем в RDi, то пишем текст, забрасываем его на сервер и там запускаем компилятор.

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

                                    БД там является неотъемлемой частью системы. Те же транзакции поддерживаются на уровне ОС. Любая программа может быть использована в качестве встроенной функции БД.

                                    Аналогично с компиляторами — они не поставляются как-то отдельно, они есть в составе ОС.
                                      0
                                      Вы, наверное, не так поняли.
                                      А мне кажется вы меня как-то не поняли.

                                      Самодостаточность — это значит, что покупая сервер мы сразу получаем и железо и ОС, в которую интегрирована и БД и компиляторы и все средства администрирования. Ничего другого для работы нам уже не надо.
                                      Ну как же не надо-то. Вы же сами пишите:
                                      RDi здесь поставляется всего лишь как IDE для более комфотной разработки.
                                      Так что таки вам надо что-то ещё: ещё один компьютер, дополнительная операционка и куча всего ещё.

                                      Никто не мешает писать текст прямо на сервере, пользуясь встроенным редактором SEU.
                                      Ну так и на микроконтроллере можно, если приловчиться, программу вбивать кнопочками — прямо в машинных кодах. Когда-то давно, полвека назад, так, собственно и делали. Вы говорите, что SEU достаточно… возможно — но какой процент пользуется RDi, а какой — редактором SEU?

                                      БД там является неотъемлемой частью системы. Те же транзакции поддерживаются на уровне ОС. Любая программа может быть использована в качестве встроенной функции БД.
                                      Всё это прекрасно. Но заметьте, что удалось всю эту красоту наладить только и исключительно за счёт сознательного отказа от поддержки массы выщей.

                                      GUI у нас системой не поддерживается, рассчитать 3D-ролик мы не можем, подключить TPU — тоже никак… всё заточено под некоторую вполне определённую нишу… и туда даже не вошла среда разработки (хотя вошли компиляторы)!

                                      Я, собственно, о том, что ни о какой «самодостаточности» тут нет и речи. Даже и близко. Это как говорить о «самодостаточном» двигателе для автомобиля. Да, двигатель многое определяет и недавром даже в названиях команд формулы-1 производитель двигателя явно фигурирует… но сам по себе он никому нафиг не нужен.

                                      Вот то же самое и с AS/400 — оно, конечно, может являться ядром IT-системы фирмы… но само по себе оно неспособно ни на что вообще. Ну вот совсем ни на что. Ни платёжку распечатать, ни сеточку нейронную насчитать.

                                      Потому и удалось сделать такую красивую архитектуру, что все задачи, которые в неё не вписываются — «вынесли за скобки». Перенесли на другие, сопряжённые системы. А это, в некотором смысле антипод самодостаточности…

                                      Я вот именно о месте AS/400 в мире, а не о том, как оно устроено внутри.
                                0
                                У IBM параллельно есть еще платформа IBM z, про нее ничего не знаю, видел доки на их сайте. Она, вроде, есть развитие 370-390.
                                  0
                                  Да, всё так.
                      +2
                      Таблица востребованности:
                      — Так так, C#, .net ну хорошо, в качестве джуниора мы Вас возьмем.
                      — Начинайте изучать PHP
                        0

                        может быть там подразумевается "а теперь переводите это на net core"?
                        ну, я надеюсь, во всяком случае: видимый мною "кровавый энтерпрайз" выбирает либо java либо dotnet. php запретили на уровне архитекторов. но у меня субъективное видение, конечно: в пределах организации.

                          0
                          Node.js в кровавом интерпрайзе я тоже не встречал, разве что в качестве сервера моков.
                            0

                            он там (у нас) только в качестве вспомогательного инструмента: сборка фронта и всякие внутренние (неофициальные) мелкие поделки (геймификация, запись в спортзал).

                              0

                              Нуу, компания Hola с вами не согласится) Несколько мне известно, там и бэк и фронт на JS. И на бэке Node.js)

                                0
                                У них серверная часть vpn на node.js? Хотелось бы верить но верится с трудом…
                                  0
                                  Ну верить или нет — ваше личное дело) у меня там бывший коллега работает. Он на js и фронт и бэк пишет. Он и рассказал) впн они там пишут на ноде или внутреннюю админку — этого к сожалению сказать не могу. Но это по-любому уже не сервер моков)
                                    0
                                    Ну сайт визитка, с функциями регистрации и оплаты это все-таки не кровавый интерпрайз. Вот если VPN, тогда соглашусь, что это хороший пример, но скорее исключение подтверждающее правило. В моем представление кровавый интерпрайз это необходимость в постоянной поддержке и актуализации софта например под требования ФНС, а не просто разработал фичу поправил баги и пусть живет.
                                      0

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

                          +2
                          Вы меня извините, но статья ни по теме, ни по стилистике, ни по содержанию для Хабра совсем не годится. Это в Яндекс.Дзен лучше отправить. Потому что статью «Кто такой бэкенд разработчик с точки зрения домохозяйки» лучше адресовать домохозяйкам, а не бэкенд разработчикам.
                          Intern: C++, C#, Golang
                          Lead: PHP

                          И выше вилка с зарплатами.
                          Вот только ничего, что согласно исследованиям Хабр-Карьеры, Go — один из самых высокооплачиваемых языков, а PHP — наоборот habr.com/ru/company/habr_career/blog/478880?
                            0
                            Вы меня извините, но статья ни по теме, ни по стилистике, ни по содержанию для Хабра совсем не годится. Это в Яндекс.Дзен лучше отправить. Потому что статью «Кто такой бэкенд разработчик с точки зрения домохозяйки» лучше адресовать домохозяйкам, а не бэкенд разработчикам.


                            Хабр объявил смену политики контента. Количество рекламных постов увеличилось втрое. **звук из третьих героев**
                              +2
                              Приветствую. У меня тоже сегодня настроение не очень, понимаю вас ;-) Если что, опыт в фуллстек-разработке — 4 года, управления и подбора — 12 лет. Но как бы хотелось быть домохозяином, а ещё лучше — домовладельцем в небольшом посёлке. Эх… ваши бы слова!

                              Коллега, никто не говорил об оплачиваемости конкретного навыка. Тот список, который вы видите, это основные навыки, которые указали те, кто закинул свою зарплату в статистику. Логично, что молодые ребята уже стартуют с более актуального Golang, а у остальных — старый добрый PHP. Это говорит лишь о популярных навыках, которые могут пригодится и которые примут к сведению.
                                –1

                                Тогда непонятно, зачем вы пишете статью на таком низком техническом уровне детализации на техническом ресурсе.


                                Да, вы прямо не говорите о связи этих таблиц, но человек, не искушённый в статистике, не видя исходных данных, сделает вывод о связи php -> lead -> высокие зарплаты, это напрашивается. Это если не прямой обман, то грязный трюк.

                                  0
                                  вы прямо не говорите о связи этих таблиц, но человек, не искушённый в статистике, не видя исходных данных, сделает вывод о связи php -> lead -> высокие зарплаты, это напрашивается. Это если не прямой обман, то грязный трюк.
                                  Грязный трюк — чтобы что? Чтобы продвинуть PHP в массы? :-) Я прислушался к вашему совету и под таблицей написал, что это за скиллы, чтобы сомнений не осталось.

                                  зачем вы пишете статью на таком низком техническом уровне детализации на техническом ресурсе
                                  Цель серии о профессиях — написать о том, что может ждать при выборе специальности. Это материалы для тех, кто ещё не выбрал или думает «перескочить» и, может быть, даже для их преподавателей, родителей и работодателей. Если я насую в статью кучу инфы из своей головы о шардировании, партиционировании, паттернах, нереляционных СУБД, синтаксисе, горутинах — кому нафиг будет полезна эта статья? Бэкендерам, которые уже в деле? Незачем. Нужно думать о целях и каких-то задачах. Тем более, что в статье ничего не продаётся и не продвигается (не считая стандартного баннера) — она именно для полезноты.
                                    0
                                    Ну не знаю… Долгое время вообще не задумывался. Фронт, бэк… Нужно было делать интерфейсы — делал интерфейсы. С нуля. Т.е. сам придумывал, проектировал, писал. Потом понял что мне больше нравится колупаться в поторохах. Алгоритмы обработки данных, протоколы обмена, использование системных API для получения максимальной функциональности и эффективности…

                                    Когда менял работу, тоже особо не задумывался. Но сложилось удачно — попал в самы глубокий бэк, команда ядровых функций АБС. Что идет от вебсервисов из мобильного клиента, интернет банка, из Пеги, попадает к нам. Ну и то, что работает в фоне — обработчики очереди сообщений, журнальные мониторы, репликаторы, регулярные отчеты…

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

                                      Спасибо, так гораздо лучше.
                                      Цель серии о профессиях — написать о том, что может ждать при выборе специальности

                                      Возможно, у меня просто припекает от того, что Хабр уже не тот. Не берите в голову.
                                  +1
                                  И выше вилка с зарплатами.
                                  Вот только ничего, что согласно исследованиям Хабр-Карьеры, Go — один из самых высокооплачиваемых языков, а PHP — наоборот habr.com/ru/company/habr_career/blog/478880?


                                  Эта средняя температура по больнице. Кто-то с жаром, а кто-то в холодильнике в морге.

                                  На PHP полным-полно массовых недорогих систем, полным полно программистов, что пашут за копейки над этими массовыми «сайтами-визитками». Поэтому средняя цена PHP-шника ниже.

                                  Но это не имеет никакого отношения к тем разработчикам, что на PHP делают сложные системы.

                                  Просто сайты-визитки на Go не делают. На Go меньше дешевых и простых работ. Поэтому среднее по больнице сдвинуто в высокие зарплаты.

                                  Но:

                                  1) Для вас лично имеет значение не средняя планка по больнице, а то, что лично вы разрабатываете, где лично вы работаете.

                                  2) Если уж вы считаете, что весь ключ именно в языке программирования, то просто смените его. Переход с одного языка на другой — легок и прост, если вы уже опытный разработчик. Автор этих строк изучил Go за 2 дня (по 3-4 часа в день). Go был у меня 15-м языком.

                                  +1
                                  Опять статья вышла очень интересной. Я успел полюбить этот формат!

                                  Но я просто умиляюсь тому, что разница зарплаты между junior и middle разработчиком равна пятидесяти тысячам рублей, но...
                                  Если сравнить с заработной платой фронтендеров, то рост незначительный
                                    +2
                                    Спасибо за отзыв, он вдохновляет! Осталось как минимум 3 серии в «Профессии», причём одну идею подкинули сами читатели — написать про мобильных разработчиков как отдельный вид. И действительно, опыт с этими ребятами был интересным и не без находок.

                                    Что касается зарплатных ножниц, это же примерная статистика на относительно небольшой (в статистическом понимании!) выборке «Карьеры». Я бы назвал это тенденцией, трендом, но, конечно, не фактом. На практике бывает всякое: можно остаться в компании и через 2 года перейти на новый уровень с +5 тыс. руб., можно перейти в новую компанию и сделать гап чуть ли не на 40-50 тыс. руб., а можно и наоборот. Это очень дискуссионный момент и сильно зависит от отношения компании к сотруднику и сотрудника к проекту.
                                    +2
                                    У нее другие корни, насколько знаю.

                                    System/3 — System/36 — System/38 — AS/400 (Advansed System/400).

                                    Абсолютно ничего общего с win и *nix Это принципиально иная школа осостроения. Одни TIMI (Technology Independant Machine Instructions) чего стоит. Там принципиальнотнет ассемблера. Есть эти самые MI. Каждая из которых работает с объектом (все есть объект). Вся система состоит из объектов. У каждого объекта имя и тип. Файлов как таковых тожеинет — объекты.

                                    Программный объект кроме исполняемого кода содержит еще timi код. И при каждом запуске проверяется — собран ли этот программный побъект под данную архитектуру или нет. Если нет, то исполняемый код автоматически перегенерируется из timi.

                                    Вот заменили у нас сервер с powers 824 на powers 924 (тестовый сервер для разработки). После этого все pgm при первом запуске на новом проце автоматически перегенерировались под него. С оптимизацией под данный конкретный проц.

                                    Де модели памяти — одноуровневая singlelevel и terraspace (ее не разрешают нам). В одноуровневой сквозная адресация памяти и диска. Вот есть такой объект userspace — что-то типа двоичного файла в других ос. На него можно получить указатель и работать с ним как с областью памяти.

                                    Размер указателей, кстати, 16 байт :-)

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

                                    Глобальные и статические переменные будут сохранять свое значение пока группа активации не закроется. Т.е. можно в рамках одной задачи запускать одну программу несколько раз и глобалы и статики будут сохранять свои значения с прошлого запуска…
                                      –1
                                      ru_vds Возможная реакция Кента Бека когда в статье на Хабре его фамилию и имя путают местами :)
                                        0

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

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

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