Бэкенд с чего начать

По пунктам: что нужно знать о бэкенде новичку в веб-разработке

Рассказывает Эмит Ирэндол, full-stack разработчик

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

1. Аутентификация

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

Можно выделить два основных типа аутентификации:

Есть и более продвинутый сценарий — многофакторная аутентификация. Она повышает безопасность приложения, добавляя дополнительные уровни защиты к логину и паролю. Хорошие примеры реализации есть у Google и Amazon.

Прим. перев. А у нас есть разъясняющая статья про двухфакторную аутентификацию и протокол FIDO U2F.

2. Роли, разрешения и контроль доступа

Запутались? Объясню подробнее. Смысл слоя, отвечающего за авторизацию, — это выдача разрешений, поддержание безопасности личной информации, отказ в доступе к конкретным действиям и, где требуется, аннулирование привилегий, чтобы одни пользователи не пробирались в аккаунты других и не смотрели их личные фотографии. Логика разрешений проста:

Пользователь x может сделать действие y с объектом z.

Применим это в конкретной ситуации: Шэрон — редактор и может редактировать посты. Тогда надо определить:

3. CRUD — Create, Read, Update, Delete

27–29 декабря, Онлайн, Беcплатно

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

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

Так выглядит CRUD при работе с фреймворком Ruby on Rail, который предоставляет слой объектно-реляционного сопоставления (Object Relational Mapping — ORM ) :

Также ваши ресурсы редко существуют в изоляции. Чаще всего они связаны какими-то отношениями или ассоциациями с другими ресурсами. Давайте взглянем на сценарий, где вы хотите сохранить информацию о парах, которые есть у студента. Вы можете создать дочерний ресурс в student и сохранить его:

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

Заметьте, что для задач CRUD вам также нужно будет научиться проверять входящие данные и сверяться с разрешениями, прежде чем вы сделаете что-то с этими данными.

4. REST

Чтобы обеспечить управление ресурсами в вашем приложении (такими, как книги или аккаунты), нужно реализовать программный слой, принимающий запросы и формирующий ответы. Здесь вам доведется поработать с маршрутами (routes) и контроллерами (controllers). Они обеспечивают соблюдение ограничений, накладываемых REST — стилем архитектуры программного обеспечения для распределенных систем.

В типичном приложении на Ruby маршрут выглядит так:

Что в это время происходит в системе:

Запросы могут приходить из многих источников (их называют клиентами). Чаще всего запросы для веб-приложения формируются в форме ввода браузера. Но, если вы пишете бэкенд для мобильного приложения, то клиент — это API приложения, и он посылает запросы GET, POST, PUT, DELETE из приложения.

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

Прим. перев. Также предлагаем ознакомиться с нашим материалом по этой теме.

5. Формы и состояния

Формы — это самый распространенный способ общения пользователей с приложением. В основном через них пользователи и вводят все данные.

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

Когда пользователь начинает взаимодействовать с формой, вам надо сделать следующее:

6. API

Чтобы ваше приложение стало по-настоящему популярным, вам надо начать делиться данными с другими приложениями. Например, вы — музыкальная компания, и вы хотите, чтобы стриминговые сервисы типа SoundCloud поставляли ваш контент, а пользователи могли покупать вашу музыку напрямую из их приложения. Здесь и нужен API.

Термин API — аббревиатура от Application Programming Interface (интерфейс программирования приложений) — применяется к инфраструктуре, которая позволяет другим приложениям взаимодействовать с вашим. На картинке выше вы видите пример применения API для обслуживания сети из многих мобильных и настольных клиентов.

Основные этапы написания API:

7. Уведомления по Email, SMS и Webhooks

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

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

Для разных случаев вы можете использовать разные уведомления:

8. Подписка и тарифные планы

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

Полезные советы по проектированию тарифных планов:

9. Взаимодействие с платежным шлюзом

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

Во время транзакции нужно:

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

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

Как работает платежный шлюз:

Если остались вопросы, посмотрите это видео:

10. Загрузка файлов

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

11. Сторонние API, фреймворки и пакеты

Ruby, Elixir, PHP и JavaScript уже имеют тысячи пакетов, которые могут быть настроены и применены к вашему приложению. Их легко встроить с помощью команды в одну строку в терминале:

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

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

12. Работа с Open Source

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

13. Интерфейс для управления

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

Хорошая панель управления должна обладать следующими свойствами:

14. Кэширование

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

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

Как работает кэширование в веб-приложениях? Можно выделить следующие типы механизмов:

15. Компоненты

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

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

16. Системы управления версиями

Речь, конечно, идет об использовании Git и GitHub. Новичкам использование Git кажется излишним, а его преимущества — неочевидными, поэтому предлагаю подумать о ситуациях, с которыми вы можете столкнуться в процессе написания кода:

Научиться пользоваться GitHub поможет эта статья.

Прим. перев. А чтобы разобраться в основах Git, читайте наше руководство.

17. Командная строка

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

Для освоения командной строки советую эту книгу.

Прим. перев. Знакомство с командной строкой также можно начать с нашей шпаргалки по Bash.

18. Вопросы на Stack Overflow

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

Источник

Очередь в backend: за чем стоим и с чего начать свой путь?

Для всех, кто не любит делать UI, «дышит» очередями и мечтает об идеальном API, в четвёртый выпуск подкаста «Сушите вёсла» мы позвали backend-разработчиков Андрея, Азата и Антона.

Железные разработчики Redmadrobot Артём и Рома записывают подкаст, где вместе с гостями обсуждают разные стороны создания ИТ-продуктов и делятся опытом в диджитале. В выпуске #4 ведущие разузнали у собеседников, с чего начинался их путь в backend, какой web-framework стоит выбрать, снится ли им верстка экранов и как объяснить маме, кем ты работаешь.

Прикладываем подкаст и ответы на несколько животрепещущих вопросов

Тайминг

01:27 — Как приходят в backend-разработку
10:33 — Что привлекает специалистов в backend
12:32 — Срыв покровов: нужны ли глубокие знания алгоритмов для тех, кто «пилит апишку»?
15:17 — Вопросики масштабирования и безопасности
16:23 — Одинаковую ли работу делают все backend-разработчики?
19:23 — Ruby on Rails, его «магия», взлёт и падение
24:23 — Как выбрать платформу?
28:06 — Зачем нужны микрофреймворки и как с ними работать?
33:55 — Что такое асинхронный сервер и для чего он нужен?
35:58 — Go: простота и архитектура
41:46 — Postgresql вместо MySQL. Почему?
44:58 — Зачем нужно изучить Docker как можно быстрее и для чего стоит поставить nginx?
50:49 — «Зелёные» разработчики: какими минимальными навыками необходимо обладать выпускникам университетов, чтобы устроиться на работу?
1:04:21 — Лучшие книги по алгоритмам
1:09:33 — Что нужно знать и что не нужно делать на собеседовании?
1:14:29 — Не хочется ли ребятам уйти из backend?
1:20:28 — И все-таки, чего не стоит делать на работе и почему «с людьми нужно общаться»?

Как приходят в backend разработку?

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

Азат, например, рассказал, как он не пошел в мобильную разработку и решил, что логичнее заниматься веб-разработкой в широком смысле. А вот история Антона тесно связана с Python.

Я учился в университете и выучил Python. Он мне нравился, и мне хотелось продолжать делать что-то на «питоне». А в Белгороде, где я жил и учился, можно было найти только какую-нибудь веб-студию, которая делает сайты на CMS’ке — просто подверстывают шаблоны. Мне этим вообще заниматься не хотелось. Поэтому мы с другом нашли каких-то людей, сделали им сайт, а потом ещё кому-то сделали. И было классно, потому что я делал то, что хотел. Но хотел я, наверное, не то, что было нужно в тот момент. Но, по крайней мере, я научился делать backend и после этого нашёл нормальную работу.

Что привлекает людей в backend.

…Когда есть суперпопулярный frontend? Артём вспомнил множество собеседований, на которых соискатели рассказывали, почему они хотят строить карьеру в мобильной разработке. Просто чтобы потом похвастаться крутостью приложения. В backend с этим сложнее.

Но на самом деле, если друзья, с которыми ты делишься радостью создания backend, понимают в ИТ-разработке, то они похвалят тебя. А вот маме можно сказать, что делал сервер для мобильного приложения магазина, которым она пользуется. И даже если, что такое сервер, ей не до конца понятно, мама всё равно будет гордиться.

Плюсы Backend-разработки

Азат предположил, что людей привлекает тот факт, что не нужно верстать. Ещё есть мнение, что backend сложнее и круче, хотя каждому, конечно же, свое. После этого ребята ушли в беседу о масштабировании и безопасности. Подробнее — с 15:17.

Все ли backend-разработчики делают одну работу?

Это не так. Задачи в backend разработке бывают разными, и они зависят не от языка или платформы, а от потребностей и специфики компании, а также от уровня самого разработчика.

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

Python, Ruby, Go, С++ и все-все-все

Ребята в студии заговорили о том, как выбрать платформу. А также о том, что Ruby «ещё живет» (Рома недавно видел доказательство), а ещё почему Антон начал учить Python, о странных именах создателей языков программирования, простоте Go, микрофреймворках (о них говорили особенно много — слушайте с 28:06), MySQL, Docker, асинхронных серверах и магии рельсов.

«Зелёные» разработчики и минимальные навыки для соискателя

Насколько глубоко должен, например, выпускник университета разбираться в backend, чтобы получить работу?

Во время обсуждения выяснилось, что он должен быть «уверенным пользователем ПК». А если серьезно, то по мнению Азата, молодой специалист обязан обладать минимальными навыками администрирования unix-систем — знать определенный набор команд: cd, ls и другие.

Также должен понимать, что такое процесс, какие есть права доступа, какая система прав Linux и как вообще в ней функционируют сети, как работает IPC (inter process communications), TCP сокеты. Для начала этого достаточно. Нужно просто уметь программировать. Вот что сказал Антон:

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

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

Какие книги по алгоритмам стоит прочитать

Андрей «топил» за Стивена Скиена и его «Алгоритмы. Разработка и применение». Антон порекомендовал книгу Томаса Кормена, в которой «есть баланс между строгостью, понятностью и простотой изложения», и ещё «Cracking the Coding Interview» — хорошее практическое руководство, чтобы быстро разобраться в алгоритмах.

Также гости посоветовали «Искусство программирования» Дональда Кнута, которая задумывалась как пособие по компиляторам, а стала настоящей «книгой книг».

В итоге, backend — да или нет?

Ребята пришли к выводу, что во всех сферах веб-разработки есть свои плюсы и минусы. И это нормально. Если вам нравится backend, алгоритмы и очереди, то вам стоит задуматься о карьере именно в нём. Это если кратко. Если же хочется вживую услышать рассуждения, то включайтесь в подкаст с 1:14:29.

Полезные материалы

Для желающих погрузиться в Python можно почитать:

Источник

Бойцы невидимого фронта. Кто такой Backend-разработчик и как им стать?

Кто такой Back-end разработчик?

Навыки Back-end разработчика

Как стать Back-end разработчиком?

Выучите основы структур данных и алгоритмов.

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

Выучите язык программирования и выберите фреймворк(и).

Раз уж в бэкенд-разработке используются разные языки программирования, лучше с самого начала определиться с языком или языками (никто не запрещает изучать сразу несколько), на которых вы будете специализироваться. Помимо Java, начинают чаще всего с изучения C, Python или PHP. JavaScript также будет хорошим вариантом для дополнительного развития.

Выучите SQL и основы управления базами данных.

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

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

Начните применять полученные знания на практике.

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

Научитесь работать с облачными сервисами.

Еще одним достаточно важным шагом будет научиться развертыванию ваших программных продуктов на платформах облачных сервисов. Основными вариантами облачных платформ являются AWS, Google Cloud, Azure и Heroku.

Источник

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

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

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

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

Кто это?

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

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

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

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

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

Где нужен?

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

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

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

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

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

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

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

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

+ ООП, фреймворки, Docker+ высоконагруженные системы, ООП, фреймворки, Docker+ Linux, ООП, фреймворки, Docker

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

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

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

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

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

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

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

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

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

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

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

Где учиться

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник