Бэкэнд что это в бизнесе

Записи из курса по technical product manager; позиционируют как: “Говори с разработчиками на одном языка”.

Это 3я часть из серии, в ней собраны: подходы к выбору технологий проекта, этапы разработки, уровни разработчиков (jun-sen), требования к архитектуре и документации, концепции тестирования (обзорно).

Backend

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

Backend реализует в себе:

• Большое количество технологий и подходов (нужно уметь выбрать стек технологий под проект; всё определяет задача);
• Распределенные системы хранения и обработки данных;
• Хостинг и сохранность данных;
• Контроль доступа (фаервол, пермишены);
• API для внешних интеграций.

Код ревью — процесс проверки кода на соответствие стандартам и подходам команды (code style). Существует, чтобы снизить уровень грязи, уменьшить bus-factor.

Что должен знать JUNIOR BACKEND разработчик? Подробный план

Выбор языка:

Задача (бизнес требования) определяет Технологию (язык, БД, подход и тд).

Выбор технологии:

• задача “ сделать автопилот в машину” или “сделать мед систему для введения лекарства” или “сделать автопилот для самолёта” — нужны быстрые и точный вычисления, долгосрочная перспектива использования, нет возможности быстро обновить, отказоустойчивость, глобальный продукт— используют компилируемые языки, которые работает однотипно, понятно, быстро, без зависаний;(подойдут C++, Java, C#, .NET );
• задача “сделать корп сайт” или “сделать интернет магазин” — требования к точности и устойчивости ниже, нужна скорость разработки, простота, общение клиент-сервер — используют интерпретируемые языки (PHP, Ruby, Python, Node.js — они больше заточены под это);
• задача “перебрать страницы в интернет и собрать данные” или “нужна нейросеть, которая меняет лица” — используют специальные языки или библиотеки для работы с нейронными сетями (Python, R, C++);
• задача “сделать просто сайт” — стоит использовать готовые решения (frameworks, CMS).

Сначала думай, а потом пиши (или не пиши).

Разница между компилируемым и интерпретируемый языком состоит в процесс разработки:

Этапы разработки:

1. Создание исходного кода (набор команд);
2. Компиляция: превращение исходного кода в бинарный (проверка ошибок, отладка, понятный машине код);
3. Исполнение кода (1 и 0): процессор память принимают и обрабатывают код, создают файл работы.

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

Можно ли сделать наоборот?

Что такое Backend?

Магазин на Java, C++ или “автопилот на JS или PHP” — да, можно, но это экономически не выгодно (разработчики стоят дороже, есть простые решения).

Если в начале выбрали не тот язык?
Кейс: VK сделали на PHP (ядро); столкнулись с проблемой производительности при нагрузке (high load — много пользователей, данных, запросов, высокий он-лайн при росте); пришлось самим делать инструменты, костили и тд (т.к. переписать всё нормально уже было долго и дорого); в 2012 году переписали на новом языке, а старый говно-код выложили на github.

CMS vs. Framework

Фреймворк — набор библиотек, в которых “с коробки” реализована базовая логика, например для сайта: роутинг (url), авторизация, подключение и БД; разработчик сразу начинает писать бизнес логику; ядро (каркас) уже есть.

CMS — готовое решение на уровне продукта (бизнес логика); нужно только кастомизировать всё под себя (контент, внешний вид). Можно настроить без опыта разработки и добавлять функции (плагины) под себя. Сильно дешевле собственной разработки.

Backend разработка

Обязанности (задачи) backend разработчика:

• разработка ПО: выбор типа базы данных + проектирование; проектирование моделей; создание CRUD операций; реализация бизнес-логики; покрытие кода Unit-тестами; поддержка микросервисов; управление демонами и воркерами; написание методов API; кеширование;
• настройка доступов (это для dev ops);
• организация бэкапов (это для dev ops);

Для комфортной работы разработчику потербуеться:

• документация (техническая, продуктовая, блок-схемы, диаграммы, в актуальном состоянии);
• описание бизнес процессов: задачи в трекере, user story (с критериями приема, логикой и тд) понятный флоу движения задач;
• соглашения по архитектуре: сервисы, фреймворки, архитектура кода, код стайл (переменные, методы, расположение файлов, подключение ресурсов и тд.);
• понимать, кто будет использвать backend и как: разработчик в команде, продукт, сервис по API, клиенты и тд;
  тут много подводных камней по безопасности и версионности;
• интеграции и сторонные сервисы: оптимизация запросов, настройки безопасности, кэширование и тд;
• использование готовых систем / решений:
  SAAS (готовые решения от других компаний для конечного пользователя — курс валют, API погоды);
  PASS (платформы от компаний — google docs, google drive);
  IASS (платформа с инфраструктурой и тд — iOS, amazon web servise, azure).

Уровень разработчиков (jun, midl, senior)

Junior: разработчик, у которого мало прикладного опыта. Если наставник есть и задачи позволяют — можно за год-другой пройти этот этап, но можно и лет на 5 на нём зависнуть, если не шевелиться.

• Небольшие, лёгкие, чёткие задачи;
• Много вопросов, мало знаний;
• Нужен наставник;
• Риск ошибок велик;
• Стоят не дорого;

К сожалению, такие примеры мы нередко видим на
собеседованиях. Сейчас есть практика “no junior”, когда кампании нанимают от middle.

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

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

В целом это — уровень большинства нормальных программистов.

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

• Прекрасно владеет профильными
  технологиями;
• Задаёт вектор развития команде;
• Знает свою часть проекта;
• Выполняет сложные задачи;
• Контролирует работу мидлов и джунов;

Знает как сделать систему компонент лучше, чем в “дефолтной реализации”. Смотрит глубоко во внутрь систем, разбирается.

Не все доходят до этого уровня. Переход на этот уровнеь зависит от желания, амбиций и тд.

Требования к архитектуре

При создании информационных систем следует учитывать:

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

Требования к документации

Документация должна обладать следующими свойствами:

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

Реализовать такую документацию можно посредством четырёх практик:

1. Декомпозиция — разбиение системы на структурные составляющие, по типу, назначению, функциям, зависимым сущностям. Представить можно в виде диаграммы декомпозиции или словесным описанием.
2. Описание зависимостей — описание связей между сущностями и системными ресурсами. Представить можно в виде структурных схем, диаграмм потоков данных, схемы транзакций.
3. Описание интерфейса — список всего, что может потребоваться знать проектировщику, программисту или тестировщику для того чтобы использовать структурные составляющие системы. Представить можно в виде описания интерфейсов, таблицы параметров.
4. Описание деталей — описание внутреннего устройства частей программы. Представить можно в виде блок-схем, N-S диаграммы

Разработка в Backend

(эти термины уже были в части 1, тут обзорно)
CRUD: сreate, read, update, delete — базовые функций в системе; доступна на всех уровнях (интерфейс — api — запросы — бэк);

Бизнес логика — любая логика, сделанная поверх CRUD;
Например: редактировать пост может только админ(это фича поверх create и update, значит бизнес логика);

MVC — model view controller;

Разработка Web API:
Основные подходы:

• REST: crud на уровне http:
  детальнее: https://habr.com/ru/post/181988/
• RPC: вызов удаленных процедур; очень гибкий к телу запроса и параметрам;
• Soap: старый формат, для 1с используют.;

Минимизация количества запросов к БД и к API через кэширование.

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

Важная часть CI-CD: continious integration.

Например: поменять имя пользователя; выйти из учетной записи;

Подход TDD:
Test Driven Development — подход в разработке, когда тесты пишут до начала разработки. Подходит для команд, которые работают по user stories (когда есть хорошо описанные требования к системе).

Тогда, мы пишем тесты по всем атрибутам системы в формате “если — то”, запускаем тесты, получаем fail и реализуем эти функции в коде.

Термины

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

Парсер — программа (паук, робот), которая ходит по интернету и собирает данные по кусочкам.
Например: агрегаторы цен, сайты поиска и статистики, поисковики, СЕО-анализаторы.

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

Класс — представляет собой шаблон для создания объектов, обеспечивающий начальные состояния;

Объект — экземпляр (реализация) класса;

Источник: alekseisnuff.medium.com

Что такое бэкенд. Объясняем простыми словами

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

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

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

Пример употребления на «Секрете»

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

(Из материала о правилах работы бизнеса с дизайнерами.)

Нюансы

Бэкенд-разработчик, или бэкендер, пишет код для сервера, работает с базами данных, разрабатывает API, создаёт библиотеки. Он работает с не имеющими интерфейса компонентами системы.

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

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

Источник: secretmag.ru

Фронтенд и бэкенд: с чего же начинается мобильное ecommerce-приложение

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

2894 просмотров
В этой статье:

• Что такое бэкенд, и какую роль он играет в e-commerce приложении
• Зачем на e-commerce проекте архитектор
• Сколько сервисов нужно подключить, чтобы всё заработало
• Кому доверить разработку бэкенда

Вы в блоге Surf. Мы более 12 лет работаем с мобильными технологиями. Переиспользуем успешный опыт из разных отраслей и помогаем крупным игрокам войти в топ. Среди наших клиентов лидеры своей сферы — Росбанк, Рив Гош, Бетховен и KFC.

Узнайте больше о нашем опыте мобильной разработки.

В канале в Telegram делимся своим продуктовым видением.

Что такое бэкенд в e-commerce, и как к нему подступиться