Техническая база для менеджеров продукта — часть 3 — backend
Это 3я часть из серии, в ней собраны: подходы к выбору технологий проекта, этапы разработки, уровни разработчиков (jun-sen), требования к архитектуре и документации, концепции тестирования (обзорно).
Backend
Backend — это серверная часть приложения, отвечающая за хранение, обработку и агрегацию данных. Реализует бизнес логику. При реализации задачи, нет явного представления (интерфейса) понятного пользователю/менеджеру, значит код можно наговнячить как угодно.
Backend реализует в себе:
- Большое количество технологий и подходов (нужно уметь выбрать стек технологий под проект; всё определяет задача);
- Распределенные системы хранения и обработки данных;
- Хостинг и сохранность данных;
- Контроль доступа (фаервол, пермишены);
- API для внешних интеграций.
Код ревью — процесс проверки кода на соответствие стандартам и подходам команды (code style). Существует, чтобы снизить уровень грязи, уменьшить bus-factor.
Выбор языка:
Задача (бизнес требования) определяет Технологию (язык, БД, подход и тд).
Выбор технологии:
- задача “ сделать автопилот в машину” или “сделать мед систему для введения лекарства” или “сделать автопилот для самолёта” — нужны быстрые и точный вычисления, долгосрочная перспектива использования, нет возможности быстро обновить, отказоустойчивость, глобальный продукт— используют компилируемые языки, которые работает однотипно, понятно, быстро, без зависаний;(подойдут C++, Java, C#, .NET );
- задача “сделать корп сайт” или “сделать интернет магазин” — требования к точности и устойчивости ниже, нужна скорость разработки, простота, общение клиент-сервер — используют интерпретируемые языки (PHP, Ruby, Python, Node.js — они больше заточены под это);
- задача “перебрать страницы в интернет и собрать данные” или “нужна нейросеть, которая меняет лица” — используют специальные языки или библиотеки для работы с нейронными сетями (Python, R, C++);
- задача “сделать просто сайт” — стоит использовать готовые решения (frameworks, CMS).
Сначала думай, а потом пиши (или не пиши).
Разница между компилируемым и интерпретируемый языком состоит в процесс разработки:
Этапы разработки:
- Создание исходного кода (набор команд);
- Компиляция: превращение исходного кода в бинарный (проверка ошибок, отладка, понятный машине код);
- Исполнение кода (1 и 0): процессор память принимают и обрабатывают код, создают файл работы.
При выборе технологий для проекта, стоит смотреть не только на доступные ресурсы (технологии и разработчики), а подумать об оптимальности (что мы вообще можем использовать); под каждый вид деятельности, есть свои стек; выбор технологии вначале может сильно повлиять на сроки разработки.
Можно ли сделать наоборот?
Магазин на 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: обычно на этом уровне возникает специализация — кто-то занимается сложным проектированием, кто-то знает глубокие особенности огромного количества инструментов и фреймворков, кто-то может организовать работу над большой задачей.
-
Прекрасно владеет профильными
технологиями; - Задаёт вектор развития команде;
- Знает свою часть проекта;
- Выполняет сложные задачи;
- Контролирует работу мидлов и джунов;
Знает как сделать систему \ компонент лучше, чем в “дефолтной реализации”. Смотрит глубоко во внутрь систем, разбирается.
Не все доходят до этого уровня. Переход на этот уровнеь зависит от желания, амбиций и тд.
Требования к архитектуре
При создании информационных систем следует учитывать:
- архитектуру, инфраструктуру, выборе компонентов и связей между ними, открытость, масштабируемость, переносимость, мобильность, защита инвестиций и т.п.;
- архитектура должна быть достаточно гибкой, т.е. должна допускать относительно простое, без коренных структурных изменений, развитие инфраструктуры и изменение конфигурации, наращивание функций и ресурсов;
- должны быть обеспечены безопасность функционирования системы при различных видах угроз и надежная защита данных от ошибок проектирования, разрушения или потери информации, а также авторизация пользователей, управление рабочей загрузкой, резервированием данных;
- следует обеспечить комфортный, максимально упрощенный доступ пользователей к сервисам через крутой интерфейс;
- систему должна сопровождать актуализированная, комплектная документация.
Требования к документации
Документация должна обладать следующими свойствами:
- полнота — должна наиболее полно, правильно и в полной мере описывать функцию, которую необходимо реализовать;
- однозначность — описание должно быть таким, чтобы никаких расхождений в трактовке не возникало;
- непротиворечивость — не должно быть противоречивых требований, конфликтующих между собой;
- необходимость — требования должны отражать функции, действительно необходимые для пользователя, для удовлетворения задач пользователей;
- осуществимость — насколько прописанные требования возможно реализовать;
- тестируемость — возможность проверить все прописанные требования после их реализации.
Реализовать такую документацию можно посредством четырёх практик:
- Декомпозиция — разбиение системы на структурные составляющие, по типу, назначению, функциям, зависимым сущностям. Представить можно в виде диаграммы декомпозиции или словесным описанием.
- Описание зависимостей — описание связей между сущностями и системными ресурсами. Представить можно в виде структурных схем, диаграмм потоков данных, схемы транзакций.
- Описание интерфейса — список всего, что может потребоваться знать проектировщику, программисту или тестировщику для того чтобы использовать структурные составляющие системы. Представить можно в виде описания интерфейсов, таблицы параметров.
- Описание деталей — описание внутреннего устройства частей программы. Представить можно в виде блок-схем, 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). Он нужен, чтобы бэкенд сайта знал, какую именно страницу показать по запросу.
Парсер — программа (паук, робот), которая ходит по интернету и собирает данные по кусочкам.
Например: агрегаторы цен, сайты поиска и статистики, поисковики, СЕО-анализаторы.
Нейронная сеть — математическая модель, реализованная в коде, для выполнения специфической задачи, через поиск закономерностей в данных.
Например: реализует систему рекомендаций, дип фейки, подмена лица, поиск признаков болезни на МРТ.
Класс — представляет собой шаблон для создания объектов, обеспечивающий начальные состояния;
Объект — экземпляр (реализация) класса;
