Ортодоксальный backend

Подробный обзор

CRUD — Create, Read, Update, Delete

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

Frontend developer (Vue)

Sportmaster Lab, Липецк, до 130 000 ₽

tproger.ru

Вакансии на tproger.ru

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

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

  • как создавать новые данные;
  • как их редактировать;
  • как их обновлять и удалять.

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

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

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

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

Частота запросов

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

Как мы можем измерить насколько запрос затратный?

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

Давайте рассмотрим пример того когда это становится критичным: предположим мы разрабатываем google docs.

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

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

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

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

Какие инструменты нужны, чтобы создать серверную часть сайта

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

Ортодоксальный backend
Что такое frontend и backend-разработка

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

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

Курс «Профессия Веб-разработчик»

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

  • Живая обратная связь с преподавателями
  • Неограниченный доступ к материалам курса
  • Стажировка в компаниях-партнёрах
  • Дипломный проект от реального заказчика
  • Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Как развивать карьеру

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

  • занимается самообразованием;
  • знает, где и как искать ответы на вопросы по ходу работы;
  • работает под наблюдением опытных разработчиков;
  • проходит pull request — опытные специалисты просматривают его код, комментируют и дают рекомендации по улучшению.

Ортодоксальный backend
Пример вакансии для Junior с superjob.ru. По статистике, в Москве Junior получают 60 000 рублей, в регионах — 30 000.

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

Ортодоксальный backend
Пример вакансии для Middle c superjob.ru. По статистике, в Москве Middle получают 140 000 рублей, в регионах — 80 000.

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

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

Ортодоксальный backend
Пример вакансии для Senior c glassdoor.com. По статистике, в Москве Senior получают 180 000 рублей, в регионах — 120 000.

Пример из жизни

Для этой зада­чи нуж­но как мини­мум два чело­ве­ка — фрон­тенд, кото­рый настро­ит внеш­ний вид сай­та, кра­си­вые кар­точ­ки това­ров и сде­ла­ет нуж­ные цве­та, и бэкенд-разработчик, кото­рый сде­ла­ет всё осталь­ное. Осталь­но­го будет мно­го:

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

Вывод такой: рабо­ты у бэкенд-разработчика все­гда мно­го, пото­му что заказ­чик все­гда будет стре­мить­ся к тому, что­бы сде­лать сайт ещё луч­ше, быст­рее и удоб­нее.

Как в вакансии

Фронтенд-разработчик дела­ет сле­ду­ю­щее:

  • соби­ра­ет сайт по маке­ту дизай­не­ра;
  • исполь­зу­ет для это­го HTML, CSS, JavaScript и несколь­ко дру­гих язы­ков;
  • пони­ма­ет про­цес­сы, кото­рые про­ис­хо­дят во вре­мя созда­ния сай­та;
  • зна­ет, как опуб­ли­ко­вать сайт в Сети так, что­бы он выгля­дел оди­на­ко­во на всех устрой­ствах;
  • уме­ет рабо­тать с Git или дру­гим инстру­мен­том кон­тро­ля вер­сий;
  • исполь­зу­ет Webpack для сбор­ки про­ек­та и вооб­ще опе­ри­ру­ет пре­про­цес­со­ра­ми.

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

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

Вне фронтенда и бэкенда

Автономный фронтенд

Веб-приложениям, которые вы собираетесь создавать, подключение к Сети будет требоваться всё меньше и меньше.

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

Легкий бэкенд

Бэкенд, в свою очередь, становится легче и легче. Такие технологии, как хранилища документов и графовые базы данных, приводят к сокращению количества обращений к бэкенду для повторного агрегирования данных. Задача клиента — уточнить, какие данные ему нужны (базы данных графов), или извлечь все различные фрагменты данных, которые ему нужны (REST API).

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

Размытые границы

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

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

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

Структура взаимодействия бэкенда и фронтенда

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

Серверные приложения

В этом случае HTTP-запросы отправляются напрямую на сервер приложения, а сервер отвечает HTML-страницей.

Между получением запроса и ответом сервер обычно ищет по запросу информацию в базе данных и встраивает ее в шаблон (ERB, Blade, EJS, Handlebars).

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

Связь с использованием AJAX

Другой тип архитектуры использует для связи AJAX (Asynchronous JavaScript and XML). Это означает, что JavaScript, загруженный в браузере, отправляет HTTP-запрос (XHR, XML HTTP Request) изнутри страницы и (так сложилось исторически) получает XML-ответ. Сейчас для ответов также можно использовать формат JSON.

Это значит, что у вашего сервера должна быть конечная точка, которая отвечает на запросы JSON- или XML-кодом. Два примера протоколов, используемых для этого — REST и SOAP.

Клиентские (одностраничные) приложения

AJAX позволяет вам загружать данные без обновления страницы. Больше всего это используется в таких фреймворках, как Angular и Ember. После сборки такие приложения отправляются в браузер, и любой последующий рендеринг выполняется на стороне клиента (в браузере).

Такой фронтенд общается с бэкендом через HTTP, используя JSON- или XML-ответы.

Универсальные/изоморфные приложения

Некоторые библиотеки и фреймворки, например, React и Ember, позволяют вам исполнять приложения как на сервере, так и в клиенте.

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

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

  • Стив Макконнелл «Совершенный код». Просто читайте эту книгу и впитывайте то, что там написано. Вы сразу (нет, не сразу) поймёте, что такое грамотная разработка, и чем она отличается от говнокода.
  • htmlbook.ru — просто добавьте этот сайт в закладки, закреплённое и в своё сердце. Это великолепная энциклопедия веб-разработчика на русском языке с адекватной и удобной структурой. 
  • Книги Кайла Симпсона — ищите то, что вам нужно и то что актуальной даты издания. Он очень круто пишет и структурирует информацию о JavaScript.
  • Хавербеке Марейн «Выразительный JavaScript. Современное веб-программирование» — практически ценная книга от настоящего профессионала. Если не ошибаюсь, у «Питера» пережила издание в 2019 году, свежак.
  • webref.ru — очень классный сайт для разработчиков веба, разбирайтесь, обучайтесь. 
  • Книги по вашей технологии — переводные или в оригинале (ищите O’Reilly).
  • codecademy.com — люблю этот сайт и иногда использую для поддержания мозгов в порядке. Интерактивный сайт для обучения разработке на разных языках программирования на английском, с самого низкого, нулевого, уровня. Есть базовый бесплатный курс, есть платный — 15$ в месяц. Нравится общая интерактивность, значки, ачивки и постепенное нарастание сложности задач. 
  • htmlacademy.ru — есть бесплатные курсы, части курсов и блог. Берите все знания, что сможете унести.
  • Бесплатные курсы и видео, которых бесконечно много на Youtube на русском и английском языках. Просто слушайте, повторяйте, систематизируйте знания. Для начала подойдут любые, очень скоро вы научитесь отличать крутые вещи от дилетантских. 
  • Ну и конечно — не бойтесь и не стесняйтесь коммитить в open source проекты (начните с небольших, а там и до библиотек, и до фреймворков дойдёте), ковыряйте чужой код, изучайте принципы и алгоритмы.
  • Хорошая статья с очень простым английским и подсказками для начинающих свой путь в JavaScript.
  • Конечно же Хабр. Одна команда RUVDS сколько крутого по JavaScript и фронтенду перевела!

Так что же все-таки выбрать

Опытные разработчики рекомендуют начинать с верстки, после чего изучать JavaScript и сопутствующие технологии. Часто уже на этом этапе начинается освоение PHP или Node.js, ведь для полноценной работы фронтенд-специалисту нужно знать основы бекенда. Если по ходу уроков человек понимает, что его больше увлекает backend, он в любой момент может начать углубляться в интересующую область.

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

Серия бесплатных видео-уроков от EasyCode

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

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

  • Знание хотя бы одного «серверного» языка программирования: 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 года, нижняя строка — «дополнительные» скиллы.Принцип формирования списка: пользователи, внося данные о заработной плате, указывают скиллы, которые у них в приоритете (что они умеют делать!). То есть это не требования работодателя, а навыки специалистов каждой категории.роадмап, но уже для бэкенд разработчика

Структура сайта

Любой сайт состоит из пользовательской и серверной частей. На странице в интернете вы видите текст, кнопки, панели, изображения и видео. Можете перемещаться по сайту, свободно изучать контент. Перед вами — пользовательская часть сайта и результат труда frontend-разработчика: визуализация, интерактивность и понятность интерфейса. Вы видите красивый дизайн, подсвеченные кнопки и интересную типографику, сайтом удобно пользоваться. Но как все это работает изнутри?

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

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

Ортодоксальный backend
Функции Frontend и Backend

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

Ортодоксальный backend
Связка Frontend и Backend

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

Делегирование бизнес логики

Если какая-то бизнес логика вашего функционала может быть реализована и на бэкенде и на фронтенде, где лучше её реализовать?

В основном лучше делать это на бекенде. Причины:

  1. Бэкенд может быть изменен намного быстрее — один деплой на все сервера и обновленная логика будет доступна. Фронтенд же, на руках у пользователей и деплой не будет означать что старая логика в которой возможно присутствуют ошибки, не будет запущена на продакшене.
  2. Если бизнес логика требует вычислительной мощности, её тяжело протестировать на различном спектре устройств с которых пользователи могут заходить на ваше приложение. Если вы заходите на него с топового macbook, то не сможете представить насколько медленными будут вычисления на chromebook за 100 долларов.
  3. Более безопасно блокировать бизнес логику на бэкенде. Предположим у вас есть функционал только для pro пользователей. Если ограничение будет сделано на фронтенде, то кто-либо потенциально может провести реверс-инжиниринг и получить доступ к функционалу.

Впечатления от бэкенда после фронтенда

Нет работы с UI. Вообще. Раньше приходилось убивать время на исправление багов в UI, сейчас – нет. Минусы такого положения – конечный пользователь не видит результатов конкретно моей работы, как это было с фронтом. Я пытался определить, что же сложнее – бэк или фронт, и понял, что (лично для меня) тяжелее всегда было работать с многопоточностью и сетевым стеком

И тут уже не так важно – за фронт ты или за бэк. На фронте я просто столкнулся с такими задачами впервые, без подготовки, а на бэкенде уже с каким-никаким опытом

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

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

API

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

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

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

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

Frontend

В QIWI я с конца 2014 года, начинал работать как разработчик iOS–приложений, и, в принципе, пару лет занимался разработкой QIWI-кошелька. При этом не могу сказать, что было скучно – задачи были довольно разные и в рамках одного приложения: мы занимались интеграцией кошелька с другими нашими сервисами, чинили баги, подтягивали анимацию. Кроме этого, был занятный опыт по созданию приложения для Apple Watch. Потом немного расширил фокус и поработал еще и над iOS-приложением для «Совести».

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

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

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

Так что тут сложилась win-win ситуация – я хотел помочь команде и продукту (перевес в разработке был сильно не в сторону бэкендеров) и набраться новых знаний. Тимлиды все поняли и отпустили меня без каких-то претензий, продакт тоже.

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

Кэширование

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

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

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

  • кэширование контента. Если контент веб-страницы не изменяется постоянно, то нет нужды каждый раз заново его генерировать. Целая HTML-страница может быть сохранена в кэше;
  • кэширование фрагментов. Иногда целая страница не может быть закэширована, потому что на ней есть контент, который постоянно изменяется, но есть и части, которые изменяются медленно. HTML для этих статичных частей генерируется только при первом запросе, а при повторных извлекается из кэша;
  • кэширование данных. Часто в основе веб-приложения лежит база данных, но каждый раз извлекать из нее информацию достаточно накладно, поэтому часто используемые данные кэшируются в памяти приложения или в других хранилищах, например, Redis, Varnish и Memcached.

Программы для создания кода

Код пишут где угодно, даже в блокноте. Однако для удобства придуманы системы, где работает автоподстановка, можно заниматься дебагом (подсказка: Процесс отладки кода) и использовать массу иных возможностей. Такая программа называется IDE — интегрированная среда разработки, или редактор кода.

Для работы с PHP рекомендуем две IDE:

Основное преимущество — это бесплатная система. Однако NetBeans съедает много памяти во время работы и не такой прогрессивный, как редактор ниже.

Очень удобный интеллектуальный редактор от компании JetBrains. Обладает отличной автоподстановкой и продвинутой системой семантического анализа. Программист допустил опечатку — анализатор тут же показывает, где именно. Незаменимый инструмент для веб-разработчика на PHP.

Краткое, но исчерпывающее введение в PhpStorm от официального разработчика.

Кто это?

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

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

Советы

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

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

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

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

Не зубрите теорию.

Единственный способ подготовиться к техническому интервью – работать и вникать в различные задачи. Если ваша команда готовила какое-то решение, а вы работали только над его небольшим куском, который слабо связан с остальными частями решения, скорее всего, с технической частью на интервью все будет не очень хорошо. Это касается разработчиков уровня senior в первую очередь. У нас это специалисты с опытом от 5-6 лет. Причем опыт может быть разным: к нам приходят как специалисты из стартапов, так и из крупных компаний. Главное – не бояться разбираться в процессах, пробовать новое, уметь видеть общую картину. Тогда все обязательно получится!

После успешного прохождения технического собеседования кандидаты также общаются с нашим CTO. Но это уже совсем другая история

Кто такой бэкенд-разработчик

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

Просто. Бэкенда можно сравнить со строителем, который:

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

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

Frontend или backend — что выбрать новичку

Выбор зависит от предпочтений человека. Если он предпочитает деятельность, плоды которой можно «пощупать», то это скорее фронтенд, ведь он позволяет сразу же видеть изменения на сайте. Противоположный выбор подходит тому, кто хочет работать с серверными данными — брать HTML файлы, которые уже создал фронтенд-разработчик, и настраивать их передачу на сервер, а также хранение, обработку, сортировку, вычислительные действия.

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

Сложно найти дополнительную мотивацию в размере заработных плат, так как в обоих направлениях они примерно одинаковы.

По данным Dou за декабрь 2018, JavaScript является одним из наиболее популярных языков.

Уровень заработной платы специалистов по JavaScript

По графику видно, что зарплаты выше в Киеве, кроме ситуации с Middle — для них более выгоден Львов. ЗП сотрудников уровня Senior в Харькове и Львове равны.

Уровень заработной платы бекендеров: PHP, Python, Ruby

Зарплаты бекенд-программистов и фронтенд-специалистов находятся на одном уровне. Значительные отличия заметны только у сотрудников уровней Middle и Senior в PHP.

Что такое backend-разработка?

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

Например, когда вы вводите запрос на странице поисковика и жмёте клавишу Enter, frontend заканчивается и начинается backend. Ваш запрос отправляется на сервер Google или «Яндекса», где расположены алгоритмы поиска. Именно там случается всё «волшебство». Как только на мониторе появилась информация, которую вы искали, — вновь происходит возвращение в зону frontend.

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

Важно!

Backend — это процесс объединения сервера с пользователем.

Компоненты backend-разработки

Backend-разработчик применяет те инструменты, что доступны на его сервере. Он вправе выбрать любой из универсальных языков программирования, например, Ruby, PHP, Python, Java. Всё зависит от конкретного проекта и задачи заказчика.

Также для backend-разработки используются системы управления базами данных:

  • MySQL;
  • PostgreSQL;
  • SQLite;
  • MongoDB.
admin
Оцените автора
( Пока оценок нет )
Добавить комментарий