Кто такой backend-разработчик и сколько он зарабатывает

Общий монорепозиторий. Hold

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

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

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

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

Чем занимаются фронтенд-разработчики

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

Что нужно знать фронтенд-разработчику:

• Языки: HTML, CSS, JavaScript, всё чаще требуется TypeScript.
• Фреймворки: React, Vue или Angular. Нужно уметь работать с одним из них.
• Дополнительные инструменты: работа с внешними расширениями через NPM или Yarn, настройка сборки фронтенда (например, Webpack).

Рассмотрим типичную задачу младшего фронтенд-разработчика.

Предположим, у команды есть проект на React и TypeScript. В него нужно добавить компонент, выводящий на страницу иконку. Иконка может быть разных цветов в зависимости от ситуации, в которой она появляется:

‘primary’ — основной цвет,

‘secondary’ — вспомогательный цвет,

‘error’ — цвет в случае ошибки,

‘success’ — цвет в случае успешной операции.

Все цвета заданы в дизайн-системе. Связь названий и цветов описана в файле utils.ts. Выглядит он примерно так:

// utils.ts

type TIconTypes = 'secondary' | 'primary' | 'error' | 'success';

export type TIconProps = { type: TIconTypes, onClick?:() => void; };
export const getIconColor = (type: TIconTypes) => {

  return `${
    type === 'secondary'
      ? '#8585AD'
      : type === 'error'
      ? '#E52B1A'
      : type === 'success'
      ? '#00CCCC'
      : '#F2F2F3'
  }`;
};

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

// icon.tsx

import React from 'react';
import { getIconColor, TIconProps } from './utils';

export const Icon = ({ type }: TIconProps) => {
  return (
    <svg
      xmlns="<http://www.w3.org/2000/svg>"
      width="24"
      height="24"
      viewBox="0 0 24 24"
      fill={getIconColor(type)}
    >
      <path d="/* здесь будет длинный набор чисел, описывающих svg-изображение */"/>
    </svg>
  );
};

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

Это лишь небольшой пример задачи, но он наглядно демонстрирует необходимость понимания дополнительных технологий помимо HTML, CSS и JavaScript: например, React и TypeScript. То, какие технологии потребуются на конкретном проекте, определяет стек, принятый внутри команды или компании. Его нужно либо знать, либо быть готовым быстро в него погрузиться.

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

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

Преимущества и недостатки

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

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

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

Главные недостатки:

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

Предыстория

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

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

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

Менеджер зависимостей

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

Кстати, если у вас возникнут проблемы при тестировании, когда go test лезет в папку vendor, жадно тестируя каждую либу, то проблема решается элементарно:

Этот параметр исключает папку vendor из тестирования. В сам репозиторий достаточно положить glide.yaml и glide.lock файлы.

Мобильной разработке это все никак не поможет, но просто, чтобы вы знали)

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

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

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

Как строится работа над проектом

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

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

Руководитель сервиса отвечает за эти задачи — он объясняет всем, что сейчас важно делать и почему. Обычно бэкендер отвечает за конкретный кусочек продукта, с которым надо делать что-то разумное

Например, ускорять его», — говорит Алексей Шаграев из Яндекс.Поиска.

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

«Могу рассказать на примере команды Яндекс.Практикума. Я как заказчик для бэкенда говорю: «Нам нужно, чтобы платформа умела делать то-то и то-то. Например, чтобы я вводила код в окошко, а платформа мне что-то отвечала». Дальше мы садимся с бэкендом и обсуждаем задачу: что нужно сделать, как это реализовать, какие есть ограничения. Мы можем выбирать решение вместе, потому что я и моя команда понимаем в разработке. Иначе у бэкендеров была бы дополнительная задача — объяснить нам как заказчикам особенности каждого решения», — рассказывает София Техажева.

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

Если проект начинают с нуля, то шаги для бэкендера будут такими:

• Выбрать язык. Python, C++, Java, PHP — это основные языки, на которых пишут бэкенд. Так, на Java написано большинство банковских систем — этот язык используют в Райффайзенбанке и Сбербанке. На PHP создана сеть Badoo и часть сервиса ВКонтакте. Чаще всего это исторически обусловленные решения. Когда в компании уже пять лет пишут на Java, сложно переводить огромный массив кода на другой язык.
• Выбрать инструменты. Например, базу данных или фреймворк. Набор этих инструментов плюс языки, которые бэкендер выбирает, чтобы строить свой двигатель, все вместе называются стек технологий. Стеки бывают разные, в зависимости от задач и традиций компании.
• Написать код. Здесь бэкендер пользуется инструментами для создания версий, тестирования и хранения данных.

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

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

«В больших компаниях бэкендер растет так: вначале он действует как механик — что-то чинит, вставляет новые части. А обучение и опыт приводят к тому, что он начинает проектировать новые структуры самостоятельно», — объясняет София Техажева.

Например, вы отправляете запрос, а ответа нет или выпадает бессмысленный текст — значит, с сервисом что-то не так. Когда пользователь видит ошибку, он редко может определить, где она случилась — во фронтенде или в бэкенде. Но если происходит сбой на сервере, то система выдает соответствующие сообщения (Error 503 Backend fetch failed и другие).

Чем занимаются фулстек-разработчики

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

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

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

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

Backend-разработчик

Если фронтенд создает часть для пользователя, то бэкенд работает для сервера – оборудования, на котором находится сайт.

Например, вы пишете в Twitter пост и нажимаете кнопку «Отправить»: на этом моменте работа фронтенд-части заканчивается. Набранный текст уходит к backend-программе, которая сохраняет его в базу данных. Из этой базы ваш пост заберёт другая программа: она снова перебросит сообщение во фронтенд и покажет его в ленте.

Всё, что скрыто от глаз пользователей и работает на сервере – это и есть backend-разработка.

Задачи backend-разработчика

• Создать базу данных и программы, которые будут записывать информацию в базу и забирать её оттуда;
• Защитить данные: шифровать пароли и ценную информацию, настроить доступы и многое другое;
• Чтобы база не пропала в результате какого-то сбоя, нужно регулярно создавать её запасные копии – бэкапы. Это делается автоматически, но настраивает систему резервного копирования именно backend-разработчик;
• Писать скрипты и программы, которые обрабатывают то, что не видит пользователь.

В конечном итоге, бэкенд-разработчик отвечает за всё, что не относится к «фронтальной» части сайта.

Инструменты бэкенд-разработчика: Java, SQL, C#, Python.

У backend-разработчиков в «арсенале» десятки языков. У каждого есть какие-то плюсы и минусы: одни хорошо подходят для больших проектов, другие для маленьких. Так что способ реализации back-end выбирает сам, исходя из пожеланий заказчика и задач.

Кейс 3. Контролируем эксплуатацию

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

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

Фронт: Ребят, я всё сделал. Код в репе. Выкатите, плиз!Админ: Как оно выкатывается?Фронт: Собираешь нодой и раздаёшь статику веб-сервером из папки Админ: Какой версией ноды собирать? Какая команда сборки? Каким веб-сервером раздавать?

В итоге для админа развёртывание вашего проекта превращается в не менее увлекательный квест, как для вас развёртывание API на локальной машине из предыдущих кейсов.

Даже если проект будет работать у вас на компьютере, совсем не обязательно, что всё так же будет работать на продакшене. И мы получаем классическую проблему «это работает на моей машине».

Docker помогает нам и с этим. Решение простое, если мы запаковали наш проект в Docker, тем самым автоматизировав его сборку и настроив запуск, то он будет одинаково работать на всех серверах, которые поддерживают Docker.

А инструкция для админов сведётся к:

Фронт: Ребят, я всё сделал. Собрал для вас Docker-образ. Выкатите, плиз!Админ: Ок

Уж с чем, а с Docker-образами админы точно должны уметь работать. Не то, что с нашей нодой.

Что нужно делать

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

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

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

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

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

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

С чего начать

Главный инструмент бэкенд-разрабочика — язык программирования. Здесь у бэкенда два главных языка:

• PHP, на котором сделаны почти все современные веб-движки;
• Python, на который переходит весь просвещённый мир.

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

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

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

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

Кто такой frontend-разработчик

Над созданием веб-ресурса работает целая команда. Наряду с веб-дизайнером, верстальщиком и SEO-специалистом трудится и frontend-разработчик.

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

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

Чем занимается

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

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

Кроме этого, в основные обязанности входит:

1. Верстка дизайна веб-сайта. Цель этого этапа – создание структуры HTML-страницы, элементы которой будут совпадать с теми, что на макете дизайнера. Элементами могут быть кнопки, картинки, текст и т. д. Для работы понадобится не только HTML, но и CSS.
2. Регулирование функционала сайта: отладка кнопок, клавиш, форм для заполнения личных данных, полей для обратной связи, форм для комментариев, слайдеров, фотогалерей. Фронтенд может создать свою программу (скрипт) или взять готовую.
3. Проверка функционирования всех элементов интерфейса, их тестирование и доработка при необходимости.

После передачи проделанной работы в руки заказчику фронтенд может и дальше с ним сотрудничать:

1. Дает рекомендации и советы по поводу реализации и оптимального эксплуатирования определенной опции на сайте.
2. Оптимизирует скрипты, чтобы сайт стал загружаться быстрее.
3. Создает шаблоны для CMS.

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

Если хотите посмотреть HTML-код, который написал frontend-разработчик, нажмите “Ctrl+Shift+L”. Другой способ – нажать правой кнопкой мыши на пустом месте страницы и в появившемся окне нажать на “Посмотреть код”.

Эта деятельность требует умения владеть большим набором современных технологий.

Практический курс по верстке лендинга

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

• попрактиковаться в создании привлекательных лендингов (одностраничных веб-сайтов);
• научиться рационально организовывать процесс верстки;
• лучше разбираться в принципах работы препроцессоров SASS и Pug;
• прокачать навыки создания интерактивных страниц с использованием JavaScript;
• использовать менеджер заданий Gulp;
• усовершенствовать навыки владения системой контроля версий Git и сервисом хостинга проектов GitHub

Готовый проект вы сможете добавить к себе в портфолио — а это никогда не будет лишним.

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

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

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

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

Будущее фронтендера

1. Внутри фронтенд-стека. Первый уровень — заточенность на задачу и кодинг; второй уровень — расширенная работа с интерфейсами и концепциями, освоение нескольких фреймворков, TDD, новые библиотеки; третий уровень — архитектура и проектирование интерфейсов, производительность; четвёртый уровень — техническая экспертиза и управление группой разработчиков. 
2. Переход на полный стек (фуллстек-разработчик) — путь к бОльшим деньгам, крупным корпорациям, нетривиальным задачам. Вы соединяете в себе способность разрабатывать веб-приложения сразу со всех сторон и не зависеть от чужого кривого кода (в идеале, а так-то — ха-ха).
3. Переход на менеджерские позиции, управление проектами, управление всем коллективом разработчиков, общение с клиентами, презентации. Исключительно для тех, кто это любит.

Где же могут пригодиться такие навыки?

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

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

Как правило, в обязанности программиста серверной части сайта входит:

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

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

Причины перехода на Go

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

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

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

У Go такой проблемы нет. От слова совсем. Иногда даже через слишком: сидишь, ищешь идеальное решение, а StackOverflow тебе на это отвечает: ‘Ну да, просто циклом for, а ты чего ждал?’

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