Разработка сайтов по системе front-end и back-end подразумевает иерархическое разделение процесса создания ресурса на две части, на разработку пользовательского интерфеса –(фронтэнда ) и его программно-административной части (бэкэнда ).

Front-end разработка – это работа по созданию публичной части сайта, с которой непосредственно контактирует пользователь и функционала который обычно обыгрывается на клиентской стороне (в браузере ).

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

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

При создании пользовательской стороны сайта и формировании html страницы мы учитываем следующие моменты:

• Грамотное использование тегов h1, h2 и т.д. в порядке очерёдности.
• Грамотное использование тега lang.
• Реальное заполнение атрибута alt для картинок. Если на картинке изображен логотип, то “Логотип компании”, если человек, то имя человеке. Для значков на английском языке “Twitter Icon” и т.д. (не относиться к динамическим изображениям, например, фото новости).
• Не забываем про метатеги.
• Не забываем про фавиконку (favicon).
• Там где предполагается ссылка, должна быть прописана ссылка.
• Для контактов использовать атрибуты skype, tel и mailto.
• Ссылки на внешние страницы должны открываться в новом окне.
• Каждая ссылка имеет атрибут title.
• Код хорошо прокомментирован.
• Оптимизация изображений для Интернета.
• Использование мобильных версий картинок, там где это необходимо.
• HTML, CSS и JS файлы должны иметь параллельно с основной (рабочей) и сжатую версию для последующего запуска сайта на хостинге.
• Все стили и скрипты вынесенны в отдельные файлы.
• Размеры всех картинок заданы средствами CSS.
• Использовать слайдеры, карусели и галереи адаптированны для мобильных устройств.
• Всплывающие окна адаптированны для мобильных устройств.
• Переименование файлов в случае использования кеширования.
• Подсветка (hover, active, visited) для ссылок.
• Подсветка (hover, active) для кнопок и полей в формах.
• Прижатый подвал при малом кол-ве контента на странице.
• Отсутствие outline у кнопок.

Back-end разработка

Бэкэнд development – это процесс программирования сайта и наполнения его функционалом. Создание ядра сайта, разработка платформы сайта, наполнение его основным функционалом и создание административной зоны – это и есть бэкэнд разработка.

Бэкэнд производит обработку пользовательской информации полученной из front-офиса, и возвращает front-end’у результат в понятной ему форме.

Бэкэнд программирование - это веб программирование, целью которого является реализация серверной стороны сайта, интеграция базы данных и связь ее с пользовательской (front-end) стороной. Разработка бэкэнда сайта так же включает настройку и установку на сервер необходимого программного обеспечения.

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

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

При этом некоторые работодатели всячески это приветствуют и считают чем-то вроде предохранителя от выгорания – человек сменит фокус внимания, сменит департамент или отдел, но не сменит саму работу в целом.

Меня зовут Костя, и я работаю в QIWI почти 4 года. Сегодня расскажу вам, как успешно перешел из frontend-разработки в backend.

Frontend

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

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

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

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

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

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

Backend

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

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

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

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

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

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

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

Что в итоге

Backend-разработка стала для меня еще одним хорошим опытом – я научился писать код и проводить ревью, продумывать архитектуру. Это на самом деле интересно.

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

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

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

Бэк-энд разработчик — боец невидимого фронта.

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

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

Основные инструменты бэк-енд разработчика - серверные языки программирования: такие как PHP, Python, Ruby, Java, Perl, Node JS (программная платформа). Дополнительно к Node JS полезно изучить Express (библиотека для взаимодействия платформы Node JS с сервером) и Mongo DB (базу данных для получения и хранения информации).

В качестве дополнительных средств применяются фреймворки Symfony, Codeigniter, Yii, Zend Framework, Kohana и др. С целью хранения данных используются MySQL/SQLite.

Особенности профессии

Современным разработчикам недостаточно только писать код для программ. Так работали программисты 10-15 лет назад. В настоящее время такой термин неуместен, потому что в работе часто можно обойтись без написания кода, просто соединяя между собой готовые части в единую конфигурацию. И программистов сейчас называют «разработчик» или «инженер».

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

Таким образом, функционал бэк-энд разработчика выглядит следующим образом:

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

Плюсы и минусы профессии

Высокооплачиваемая и востребованная профессия.

Место работы

Компании по разработке сайтов, веб-приложений, мобильных приложений.

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

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

Профессиональные знания и навыки

Знание хотя бы одного языка программирования: Go, C, C++, Perl, Python, PHP, Ruby, Java.

• умение писать быстрый, красивый и правильный код;
• знание популярных веб-фрейморков (Django, Flask, Spring);
• умение проектировать базы данных и оптимизировать запросы;
• знание современных парадигм программирования;
• знание паттернов проектирования;
• понимание устройств веб-сервисов, интерфейсов;
• английский язык для чтения технической документации.

Где учиться на Бэк-энд разработчика

Обучает (Очно, Москва). Международное учебное заведение, специализирующееся на компьютерном образовании. Работает с 1999 года. 42 филиала в 16 странах мира. Крупнейший авторизованный учебный центр Microsoft, Cisco, Autodesk. Студенты получают международные сертификаты и международный диплом. Главная цель – трудоустройство каждого выпускника.

Высшее образование:

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

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

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

Оплата труда (сколько зарабатывает Бэк-энд разработчик)

Зарплата на 16.09.2019

Россия 40000—100000 ₽

Москва 80000—300000 ₽

Ступеньки карьеры и перспективы

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

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

1. Запоминающая предыдущее состояние - реализуется с помощью сессий. Пользователь авторизуется один раз, а затем получает возможность свободно передвигаться по приложению и доступ к защищенным ресурсам (таким, как банковские транзакции или селфи в Snapchat), не отправляя данные, которые подтверждают его вход повторно.
2. Не запоминающая предыдущее состояние - реализуется с помощью токенов. Пользователи делают все то же самое, но при выполнении каждого HTTP-запроса пользователю нужно отправлять идентификационные данные. Так обычно поступают с REST API. Сейчас золотой стандарт, не запоминающей состояние аутентификации с токенами, - JWT .

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

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

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

4. REST

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

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

Get "/photos/:id", to: "photos#show"

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

1. Приходит запрос на фото с этим маршрутом и передается контроллеру с помощью метода show .
2. Этот метод, обращаясь к ресурсу из базы данных или к другому API, формирует и передает ответ в формате HTML или JSON.
3. Клиент (в данном случае браузер компьютера) получает ответ и выводит фото на экран.

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

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

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

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

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

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

6. API

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

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

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