Wrap-up: чек-лист production-ready, куда дальше, mindset

Вы только что прошли 14 модулей — от первого HTTP-запроса до полноценного ETL с тестами и CI. Этот урок не про новый материал. Он про то, что вы уносите с собой и как этим пользоваться завтра, когда вы откроете тикет «забери данные из API партнёра» и сядете писать код.

Здесь три блока: финальный чек-лист, куда двигаться дальше как DE, и главный mindset-сдвиг, который должен произойти.

Чек-лист production-ready API client

Когда вам говорят «напиши клиент к API X», вот вопросы, которые вы должны задать себе ДО написания первой строчки кода. Если вы ответили на каждый — у вас будет production-grade результат. Если пропустили хоть один — где-то будет баг.

Это не «nice-to-have» — это минимум для прода. Junior, который умеет это сделать, на следующее собеседование идёт уже как Middle.

Что дальше: roadmap как Junior DE

Этот курс закрыл одну (большую) часть пазла — взаимодействие с внешними системами по HTTP. Дальше в Data Engineering есть ещё несколько слоёв.

Чтобы расти от Junior до Middle DE за год, обычно нужно прокачать 2-3 из этих направлений до уверенного уровня. Не все сразу. Лучшая стратегия — учить то, что нужно для текущих задач на работе.

Конкретные курсы (на этой платформе)

• python-fundamentals и python-course (advanced) — если до сих пор Python для вас «синтаксис для скриптов», а не язык. Деструкторы, контекст-менеджеры, asyncio внутри, типизация. Без этого читать чужой Python тяжело.
• airflow-course — оркестрация. DAG, sensors, hooks, operators, executors. Как поднять локально и в Kubernetes.
• storage-formats — углубление в Parquet (row groups, encoding, statistics), Iceberg (manifest files, snapshot management), Delta Lake (transaction log).
• sql-fundamentals + sql-internals — DE без SQL не существует. Запросы вы будете писать каждый день. Понимать, как они исполняются — отдельная суперсила.
• kafka-course — event-driven архитектура. Не каждый DE сидит на стримах, но знать, что это и когда применять — обязательно.
• clickhouse-course или postgres internals — углубление в один из основных storage engines.

Что я хочу, чтобы вы унесли с курса

Технические знания — половина дела. Вторая половина — mindset. Вот несколько принципов, которые, я надеюсь, изменили (или сейчас изменят) ваше отношение к работе с API.

Принцип 1: каждое HTTP-обращение — потенциальная точка отказа

Самая частая ошибка джуна — относиться к requests.get(url) как к чему-то надёжному, как к чтению из переменной. Это не так. Между вашим Python-процессом и сервером:

• DNS-резолвер (может тормозить).
• Локальный сетевой стек (могут быть проблемы с MTU, TCP timeout).
• Провайдер (rate limiting, региональные блоки).
• Промежуточные прокси/CDN (могут отдать кешированный ответ, могут уронить запрос).
• TLS handshake (может упасть из-за expired cert).
• Сервер-балансировщик (может направить на больной backend).
• Реальный backend (может быть в режиме graceful shutdown).
• БД за backend (может быть в режиме failover).

Каждый из этих слоёв время от времени отказывает. Большинство — секунды. Некоторые — минуты. Один-два раза в год — часы. Ваш клиент должен пережить любой сценарий: либо корректно отработать (retry, circuit breaker, fallback), либо упасть с понятной ошибкой и не задвоить данные.

Принцип 2: «работает у меня» != «работает в проде»

Когда вы тестируете локально, вы не воспроизводите 99% условий прода. У вас стабильный интернет, нет нагрузки, API идеально доступен, все секреты на месте. В проде:

• Сетевые флаки 1-2 раза в час.
• API в плохие дни возвращает 5xx 0.1% запросов.
• Rate limits работают на скользящем окне, локально вы их не воспроизведёте.
• Несколько экземпляров вашего pipeline могут запуститься одновременно (race condition).
• Внешний API меняет схему ответа в пятницу вечером, никого не предупредив.

Поэтому тесты на error cases важнее, чем тесты на happy path. Happy path работает всегда, error case — раз в месяц, и именно от него зависит, разбудит ли вас pager в три ночи.

Принцип 3: понятные ошибки — это контракт

Когда что-то падает в проде в 03:00, человек на pager хочет видеть: «GitHubClient: rate limit (X-RateLimit-Reset=1747500000), retry next hour», а не «KeyError: ‘message’ at line 247 in some_helper.py». Первое сообщение — диагноз и план действий. Второе — повод копаться в логах ещё час.

Доменные исключения, structured logging, корректные __str__ у custom exceptions — это инвестиция в ваше будущее спокойствие.

Принцип 4: тестируйте то, что страшно

Когда не хочется писать тест — это сигнал, что именно его и нужно написать. «Что-то это сложно тестировать» обычно означает «дизайн такой, что тестировать тяжело», а это означает «в проде там тоже будут проблемы».

Перепроектируйте, разделите слои, мокайте только границы — и тесты станут лёгкими. Если они тяжёлые — тут надо пересмотреть архитектуру, а не пропускать тесты.

Принцип 5: meta-навык — сомневаться

Все технические знания устаревают. Через два года будет httpx 1.0, OpenAPI 4, новый формат файлов «лучше Parquet». Что не устаревает — навык сомневаться в том, что вам говорят (и что говорите вы себе):

• «Этот API не нужно тестировать, он же стабильный» -> проверить.
• «У нас не бывает 5xx» -> залогировать процент 5xx за неделю и убедиться.
• «Этот скрипт идёт в прод как есть» -> пройтись по чек-листу выше.
• «Так писали всегда, не нужно менять» -> понять, почему так, и остаётся ли это валидным.

Junior, который сомневается и проверяет, через год — Middle. Тот, кто верит на слово — навсегда Junior.

Финал

Вы прошли 14 модулей. Это не «прочитали» — это «прошли». В каждом был код, диаграммы, тесты, мысленные эксперименты. Если вы внимательно читали и пробовали — у вас сейчас в голове плотная картина того, как устроена коммуникация в современных системах.

С этим багажом смело идите на интервью на Junior DE. Большинство вопросов — про HTTP, статус-коды, JSON, аутентификацию, retry-стратегии, тесты — теперь не вызовут затруднений. На технических задачах типа «напиши клиент к этому API» вы будете писать не просто работающий, а production-grade код.

И помните: путь от Junior до Middle — это не «выучить ещё пять библиотек», а «начать видеть проблемы до того, как они случились». Этот курс был про ровно это.

Удачи. Пишите хорошие клиенты, ловите 429 правильно, не задваивайте данные.

Курс окончен. Спасибо, что дошли до конца. Дальше — ваша работа: писать хороший код, читать чужой, задавать вопросы и сомневаться. Удачи в Data Engineering.