Компетенции бэкенд-разработчика
Play ITЗагрузка интерактивного демо…
Матрица ролей - кто за что отвечает в продукте
Энциклопедия даёт глубину по темам; эта страница — карта компетенций для роли бэкенд-разработчика веб-приложений. Каждый пункт означает — вы понимаете, что это, какую проблему решает, когда применять и где углубиться в нашей базе.
Клиентская сторона (HTML, fetch, CORS, фреймворки) — в Фронтенд и пунктах 1–27 чек-листа.
Матрица устроена как системная модель профессии. Каждый блок отражает отдельный слой ответственности — среда, сеть, данные, API, безопасность, эксплуатация и архитектура. Когда эти слои изучаются вместе, разработчик принимает решения с учётом последствий для производительности, надёжности и эволюции продукта.
Уровни (ориентир, не должность):
| Уровень | Смысл |
|---|---|
| J (junior) | Можете сделать под руководством, объяснить базовые термины |
| M (middle) | Проектируете и отлаживаете самостоятельно в типовых задачах |
| M+ (middle+) | Учитываете при нагрузке, сбоях и эволюции архитектуры |
Изучайте блоки сверху вниз; внутри блока — сначала J, затем M и M+.
Переход между уровнями показывает рост глубины. На уровне J специалист уверенно повторяет рабочие паттерны, на уровне M проектирует типовые решения самостоятельно, а на уровне M+ удерживает стабильность системы под нагрузкой и при изменении архитектуры.
1. Среда и Linux
Этот блок формирует эксплуатационный фундамент. В продакшене качество диагностики часто определяется тем, насколько быстро разработчик читает логи, понимает состояние процессов и проверяет сервис напрямую с хоста.
| Компетенция | J | M | M+ | Материалы |
|---|---|---|---|---|
| Контейнер для локальной разработки | ✓ | Контейнеризация, Linux для бэкенда | ||
Пакетный менеджер (apt / apk) | ✓ | Администрирование Linux | ||
| Bash: файлы, пайпы, перенаправление | ✓ | ✓ | Терминал, Linux для бэкенда | |
Процессы, сигналы SIGTERM / SIGKILL | ✓ | ✓ | Linux для бэкенда | |
systemd, фоновые задачи, cron | ✓ | Планирование задач | ||
| Лимиты дескрипторов, OOM | ✓ | Linux для бэкенда, Ошибки системы | ||
| SSH, копирование логов/дампов | ✓ | ✓ | Настройка сервера |
2. Сеть
Сетевой слой влияет на пользовательский опыт так же сильно, как и качество кода. Понимание DNS, RTT и поведения HTTP помогает отличать деградацию приложения от проблем маршрута, TLS или балансировки.
| Компетенция | J | M | M+ | Материалы |
|---|---|---|---|---|
| DNS, URL, IP (v4/v6) | ✓ | Сеть и интернет, DNS | ||
| TCP vs UDP, HTTP поверх TCP | ✓ | ✓ | Протоколы, HTTP | |
| RTT, потери пакетов, джиттер | ✓ | ✓ | Сеть для бэкенда | |
curl / DevTools Network | ✓ | Тестирование API | ||
| HTTP/2, WebSocket | ✓ | API | ||
| Reverse proxy, TLS-терминация | ✓ | Веб-серверы, Бэкенд |
3. Данные и СУБД
Блок данных отвечает за корректность и предсказуемость бизнес-операций. Здесь компетенции строятся вокруг модели хранения, транзакционных гарантий и стоимости запроса под нагрузкой.
| Компетенция | J | M | M+ | Материалы |
|---|---|---|---|---|
CRUD, индексы, EXPLAIN | ✓ | ✓ | SQL, Оптимизация | |
| Транзакции, уровни изоляции, deadlock | ✓ | ✓ | Транзакции | |
| Иерархии в реляционной БД | ✓ | Деревья в SQL | ||
| Redis как кэш / сессии | ✓ | ✓ | Redis | |
| MongoDB / документная модель | ✓ | MongoDB | ||
| JSON / YAML / бинарные форматы | ✓ | ✓ | JSON, Бинарная сериализация | |
| CAP и компромиссы распределённых БД | ✓ | ✓ | Основы NoSQL, PACELC |
4. HTTP и API
API является внешним контрактом сервиса. Чем точнее определены методы, коды ответов, версии и идемпотентность, тем устойчивее интеграции с frontend, мобильными клиентами и внешними системами.
| Компетенция | J | M | M+ | Материалы |
|---|---|---|---|---|
| Методы, коды ответов, заголовки | ✓ | HTTP | ||
| REST, версионирование, OpenAPI | ✓ | ✓ | API, Проектирование API | |
| Идемпотентность, пагинация | ✓ | Методы и идемпотентность | ||
| CORS, cookies, кэш HTTP | ✓ | Cookie, API | ||
| GraphQL / gRPC (когда уместны) | ✓ | API, Бэкенд | ||
| Nginx / проксирование | ✓ | ✓ | Веб-серверы |
5. Безопасность
Безопасность в матрице рассматривается как часть ежедневной разработки. Практика показывает, что базовые меры из этого блока предотвращают большинство инцидентов прикладного уровня до этапа эксплуатации.
| Компетенция | J | M | M+ | Материалы |
|---|---|---|---|---|
| AuthN vs AuthZ, сессия vs JWT | ✓ | ✓ | Cookie, session, JWT и PASETO, Интеграционная авторизация | |
| RBAC / ABAC | ✓ | Zero Trust | ||
| SQLi, XSS, CSRF | ✓ | Безопасность приложений | ||
| IDOR, open redirect, rate limit | ✓ | Уязвимости API | ||
| TLS, хеши, соль паролей | ✓ | ✓ | ИБ — введение |
6. Почта, поиск, наблюдаемость
Этот блок закрывает операционную зрелость. Сервис становится управляемым, когда команда умеет контролировать исходящие коммуникации, искать данные в продукте и быстро локализовывать инциденты по метрикам, логам и аудиту.
| Компетенция | J | M | M+ | Материалы |
|---|---|---|---|---|
| Исходящая почта, MIME | ✓ | Почта на бэкенде | ||
Полнотекстовый поиск vs SQL LIKE | ✓ | ✓ | Полнотекстовый поиск | |
| Метрики vs логи vs аудит | ✓ | ✓ | Наблюдаемость, Мониторинг | |
| Health check, smoke-тест | ✓ | ✓ | Тестирование |
7. Архитектура и процесс
Архитектурный блок описывает долгую дистанцию проекта. Здесь формируется способность принимать решения, которые сохраняют скорость разработки при росте кода, команды и числа интеграций.
| Компетенция | J | M | M+ | Материалы |
|---|---|---|---|---|
| MPA / SPA / SSR / CSR / SSG | ✓ | ✓ | Типы веб-приложений | |
| SOLID, KISS, DRY, IoC/DI | ✓ | Паттерны | ||
| GRASP, ADR (веб) | ✓ | GRASP и ADR | ||
| MVC, слои controller–service–repo | ✓ | ✓ | Бэкенд | |
| Очереди, идемпотентные потребители | ✓ | ✓ | Брокеры | |
| Микросервисы, CAP/PACELC | ✓ | Микросервисы, PACELC | ||
| Git, CI/CD, контейнеры | ✓ | ✓ | Git, 12 команд, DevOps | |
| Технический долг, антипаттерны | ✓ | ✓ | Рефакторинг |
8. Язык и рантайм (выберите свой стек)
Отметьте в матрице свой основной язык. Общие темы:
| Компетенция | J | M | M+ |
|---|---|---|---|
| Типы, коллекции, обработка ошибок | ✓ | ✓ | |
| HTTP-сервер или фреймворк | ✓ | ✓ | |
| ORM / драйвер БД, N+1 | ✓ | ✓ | |
| Пул соединений, таймауты | ✓ | ✓ | |
| GC / память / профилирование | ✓ | ✓ | |
| Асинхронность, graceful shutdown | ✓ | ✓ |
Навигация по языкам — Python, Java, C#, Go.
Язык реализации влияет на инструменты, но инженерные принципы остаются общими. Один и тот же сервис выигрывает от корректных таймаутов, аккуратной работы с памятью, предсказуемой обработки ошибок и дисциплины в API-контрактах.
Как пользоваться
- Пройдите блок 1 → 4 до первого рабочего API.
- Параллельно ведите чек-лист самопроверки — он проверяет понимание, эта матрица — покрытие тем.
- Для карьерного контекста: дорожная карта, подборка Бэкенд и серверная разработка.
Поднимите локально API + БД + Redis в контейнерах, добавьте health-endpoint, структурированные логи и один дашборд метрик — так матрица превращается в навык, а не в прочитанный список.
Как растить уровень на реальных задачах
Ниже дорожка в формате "сделал руками → закрепил компетенцию". Она помогает пройти от чтения к рабочей привычке.
Шаг 1 — "стабильный CRUD"
- Поднимите сервис с одной таблицей, валидацией входа и обработкой ошибок.
- Добавьте миграции, индексы и один запрос с
EXPLAIN. - Подключите логирование с
request_id.
Что закрепляется — блоки 3, 4, 6 этой матрицы.
Шаг 2 — "API под нагрузкой"
- Добавьте Redis-кэш для "горячего" чтения.
- Введите лимиты и таймауты исходящих вызовов.
- Снимите p95/p99 по эндпоинту до и после изменений.
Что закрепляется — блоки 2, 3, 6, 8.
Шаг 3 — "продовый контур"
- Соберите сервис в контейнер.
- Добавьте health/readiness endpoint.
- Настройте CI с тестами и безопасным деплоем.
Что закрепляется — блоки 1, 6, 7.
Мини-портфолио бэкенд-разработчика
Для собеседований и роста внутри команды удобно вести "паспорт" из 3–5 завершённых мини-проектов:
- сервис с JWT + refresh и ролевой авторизацией;
- сервис с очередью фоновой обработки;
- интеграция с внешним API с retry и circuit-breaker;
- API с OpenAPI-спекой, тестами и мониторингом;
- проект с SQL + Redis, где видна работа с кэшем и инвалидацией.
Каждый проект желательно описать коротким runbook:
- Как поднять локально.
- Какие метрики/логи смотреть первыми.
- Как воспроизвести одну типовую неисправность и как её устранить.
Как использовать матрицу в команде
- Разработчику: планировать учебные спринты по 1–2 блокам.
- Тимлиду: формировать прозрачный рост junior → middle через observable-критерии.
- Архитектору: видеть пробелы в эксплуатационных навыках до появления инцидентов.
Для командной калибровки полезно связать эту страницу с типами веб-приложений, наблюдаемостью и сетью для диагностики: так компетенции превращаются в целостную картину эксплуатации веб-системы.
В таком формате матрица работает как общая карта принятия решений. Команда синхронно видит, какие навыки уже обеспечивают стабильность продукта, а какие темы требуют приоритета в ближайших задачах и обучении.