Почему эта дисциплина у меня

Курс собран из того, что реально делают на работе

«Обучая других, мы учимся сами.»

Сенека

Один запрос от начала до конца

Приложение только показывает. Считает — сервис

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

Термин 1 · API

Список адресов, по которым к сервису обращаются программы

У человека для сервиса есть экран. У программы — адреса. Для каждого заранее известно, каким способом к нему обращаться, что отправить и что придёт в ответ.

Три цифры в ответе говорят больше, чем текст: 200 — всё хорошо, 404 — такого нет, 401 — не представился, 403 — представился, но нельзя, 500 — сервис сломался. Их мы разберём отдельно.

Термин 2 · JSON

То же самое, что на экране, только для программы

{
  "id": 42,
  "status": "delivering",
  "total": 1890,
  "items_count": 3
}

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

Термин 3 · бизнес-логика

Правила предметной области, а не кнопки и не таблицы

Если правило написать в приложении, оно будет работать только там: сайт и мобильное приложение начнут вести себя по-разному, а через месяц никто не вспомнит, какое поведение правильное. Поэтому правила живут в сервисе, посередине.

Термин 4 · база данных

Таблицы, строки и связи между ними

Заказ не хранит почту покупателя — он хранит его номер, и подсвеченные ячейки это показывают: заказ 42 принадлежит пользователю 7. Почта поменялась в одном месте — и все его заказы знают новую. А главное отличие от файла или переменной: содержимое базы переживает перезапуск сервиса и его падение.

Один и тот же код на двух машинах

Работает не программа, а программа вместе с окружением

Поэтому на защите я разворачиваю ваш сервис из чистого клона, а не смотрю на ваш ноутбук. К этому же приводит вся связка Docker Compose, зафиксированных зависимостей и README, которую мы соберём.

Backend baseline release v1.0

Пять частей, которые работают вместе

Это и есть итог дисциплины. Каждый раздел добавляет к сервису один кусок — и он не выбрасывается, а остаётся в проекте до защиты.

Сквозной сервис вместо набора несвязанных лабораторных

Каждая новая тема добавляется в тот же проект — и сразу видно, что она чинит и что ломает.

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

Один продукт · четыре команды

Договорились о формате — и работаем параллельно

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

Что значит «сломать контракт»

Одно переименованное поле — и приложение показывает пустоту

{
  "id": 42,
  "status": "delivering",
  "total": 1890
}

{
  "id": 42,
  "status": "delivering",
  "amount": 1890
}

Сервис отвечает успешно, ошибок в логах нет. Но приложение ищет поле total, не находит его — и в строке «Сумма» у пользователя пусто. Разбираться будут Android-разработчик и тестировщик, потому что у них «вдруг сломалось», а у вас всё зелёное.

То же ломающее изменение: убрать адрес, поменять тип с числа на строку, сделать необязательное поле обязательным.

Как менять контракт и никого не сломать

Добавлять можно, отнимать — по договорённости

Это и есть «замороженный контракт»: не «нельзя трогать никогда», а «нельзя менять внезапно». Совместимости в курсе посвящено отдельное занятие, а на пятом спринте вы будете сводить свой сервис с приложениями однокурсников — там всё это проверяется на практике.

Ритм пары · 184 часа практики из 218

Каждая пара заканчивается чем-то проверяемым: кодом, тестом, миграцией, логом, схемой, отчётом об инциденте или заметкой к релизу. Не «послушали про Docker», а «стенд поднимается».

218 часов · на карточке номера занятий

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

Три уровня внутри одной программы

Все 109 пар проходят все. Отличается не состав, а требуемая глубина.

Каждый спринт — четыре пары

Планирование → реализация → проверки и Pull Request → демонстрация и разбор

• 74–77Спринт 1 · основная пользовательская функция целиком
• 78–81Спринт 2 · хранение данных, миграция и работа с реальными данными
• 82–85Спринт 3 · защищённая функция, негативные сценарии и заморозка контракта
• 86–89Спринт 4 · кэш или фоновая задача плюс разбор учебной аварии
• 90–93Спринт 5 · стыковка с Android, WPF и тестировщиками
• 94–99Резерв · bug bash, восстановление, узкое место, security review, передача проекта

Резерв — не «свободные пары». Это шесть занятий, на которых чинится то, что всплыло за год: у одних миграции, у других логи, у третьих сборка.

Проверка на границе сервиса

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

Заодно решается вечная проблема «а какие вообще есть адреса и что они принимают»: описание контракта формируется из того же кода, а не пишется отдельно и не устаревает.

PostgreSQL, SQLAlchemy и Alembic

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

Пароль, токены, роли и негативные сценарии

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

Быстрое хранилище рядом с сервисом

Redis держит данные в памяти и отдаёт их за доли миллисекунды, но живёт отдельно от вашего процесса и может упасть.

Очередь, повторы и статус

Одна команда поднимает весь стенд

Именно эта связка делает возможной защиту из чистого клона: я беру ваш репозиторий на своей машине и запускаю одной командой.

Структурированные логи и сквозной идентификатор

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

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

Отказ по расписанию

Раз в несколько занятий сценарий ломается намеренно. Задача — не «чтобы не сломалось», а найти причину, починить минимальной правкой и доказать, что починили.

Сломанный на паре сервис в минус не идёт — это часть задания. В минус идёт другое: не суметь повторить поломку и не понять, из-за чего она случилась.

Пять тем, которые обычно видят только на работе

По одной-две пары на подготовленном стенде. Задача — не «освоить», а понимать назначение и границы: где это нужно, чего стоит и что читать дальше.

Сто баллов · порог 60

• 90–100«5» · сервис устойчив, расширения разобраны, границы объяснены
• 75–89«4» · основные функции и инфраструктура работают, есть отдельные недочёты
• 60–74«3» · API, база, вход и стенд собраны, но есть пробелы в git-flow, Docker или очередях
• 0–59«2» · сервис не разворачивается или не работает основной сценарий

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

Семь обязательных пунктов

• 01Развернуть сервис из чистого клона
• 02Показать работу API, базы, входа, кэша и фоновой задачи
• 03Провести платёж в песочнице и обработать повторный webhook
• 04Объяснить устройство очереди и восстановление worker
• 05Найти учебный инцидент по метрикам и логам
• 06Показать таймауты, повторы и пакетную обработку файла
• 07Объяснить, что в вашем сервисе базовый уровень, а что требует углубления

Седьмой пункт — самый весомый. Признать «здесь у меня упрощение, в реальном проекте так нельзя, потому что…» — сильный ответ, а не слабый.

ИИ на дисциплине

Инструмент, которым учимся пользоваться грамотно

То же правило про чужой код из интернета: копировать можно, не понимая — нельзя. В Pull Request достаточно одной строки: откуда взято и что изменено.

Словарь · часть 1 из 2

Слова, которые сегодня прозвучали

Словарь · часть 2 из 2

И слова про эксплуатацию

Домашнее задание № 1 · к следующему занятию

Максим Николаевич не хочет задавать домашнее задание. Но очень хочет

Кода писать не нужно. Задание на полстраницы — про то, чтобы начать видеть за экраном приложения запрос, проверку и ответ.

Домашнее задание № 1 · порядок сдачи

Куда положить и как сдать

Про ИИ: сначала думаете сами, дальше можно попросить модель причесать формулировки и оформить в .md. Я сам так делаю всегда, поэтому и вам запрещать не буду. Важно, чтобы наблюдения были ваши.