⚡️Осталось три дня! Напоминаем, что сейчас действуют скидки на ВСЕ мини-курсы Devman!

Успейте приобрести мини-курс со скидкой 25%!

⚡️Выбирайте мини-курсы здесь или задавайте вопросы нам в Telegram!

🤔 Давайте вместе разберемся, что не так с этим кодом?

import argparse
import os
import httpx
from dotenv import load_dotenv
import json

EARTH_RADIUS_KM = 6378

👉 Чтобы понять, что можно исправить, загляните в типичные улучшения Девмана.

💡Согласно рекомендациям PEP8, импорты стоит разделять на 3 группы. И записывать каждую в отдельных блоках:
— стандартные библиотеки,
— сторонние библиотеки,
— локальные модули.

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

✅Правильное расположение импортов будет таким:

import argparse
import json
import os

import httpx

from dotenv import load_dotenv

#оформление_python

Асинхронность vs многопоточность в FastAPI: как не убить производительность

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

Представьте: ваш сервис отлично работает при нагрузке в 100 RPS, но когда приходит 1000 запросов в секунду — всё начинает сыпаться. Сервер захлёбывается, время ответа растёт, а клиенты получают ошибки 503 Service Unavailable. Вы добавляете больше CPU и памяти, но проблема не исчезает. В чём же дело?

Проблема синхронных функций в асинхронном подходе

from fastapi import FastAPI
import time  # Синхронная библиотека!


app = FastAPI()


@app.get("/blocking-endpoint")
async def blocking_endpoint():
    """Этот endpoint заблокирует весь event loop на 5 секунд!"""
    time.sleep(5)  # Синхронная блокирующая операция
    return {"message": "Запрос выполнен"}

— Когда вы вызываете time.sleep(5) внутри async def, весь асинхронный event loop приостанавливается. event loop — это механизм для управления асинхронными операциями. Он позволяет обрабатывать задачи, не блокируя основной поток выполнения программы.
— Даже если другие пользователи отправляют запросы в это время, они не будут обрабатываться, пока sleep не завершится.

❌ Это сводит на нет все преимущества от написания сложной логики асинхронного кода

👉 Если вы разрабатываете программный продукт на FastAPI и плохо разбираетесь в асинхронщине — используйте встроенный механизм многопоточности.

👉Собрали список популярных синхронных библиотек.

Встроенная многопоточность

FastAPI по умолчанию заботится о производительности при использовании синхронных (блокирующих) операций. Вместо того чтобы тормозить весь сервер, он автоматически выносит такие задачи в фоновые потоки.

Если вы объявляете endpoint*, как обычную функцию (def):
— FastAPI Определяет, что функция синхронная.
— FastAPI запускает функцию в ThreadPoolExecutor — пуле потоков.
— Пока функция выполняется, основной поток (event loop) продолжает работать и обрабатывать другие запросы.

*Endpoint — это конечная точка в API, к которой можно обратиться для выполнения нужного действия или получения данных. Например, на сайте Девмана есть эндпойнт /modules.

from fastapi import FastAPI
import time


app = FastAPI()


@app.get("/sync-route")  # ← Обычная синхронная функция!
def sync_endpoint():
    time.sleep(5)  # Блокирующая операция
    return {"message": "Это выполнится в отдельном потоке!"}

❗️В Python потоки выполняются не одновременно, а с переключениями. Но для I/O-операций (ожидание БД, сетевых запросов) этого достаточно — пока один поток ждет ответа, другой может работать. Если таких запросов будет слишком много, пул потоков переполнится.

❗️ Важно помнить, что Fast API создает потоки автоматически только для синхронных endpoint-функций:
— Если синхронный код вызывается внутри зависимостей, фоновых задач, middleware, а также при обработке WebSocket автоматическое распределение по потокам не работает.
— Встроенная многопоточность не работает в async def endpoints при работе с синхронными библиотеками. Например, requests.get(), pandas.read_csv() или psycopg2 требуют ручного выноса в потоки при вызовах из асинхронных обработчиков.

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

👉 Если вы плохо понимаете механизмы asyncio, а ваш pet-проект не предполагает высокой нагрузки (более 20 запросов одновременно) — можно положиться на встроенный механизм распределения по потокам.

Это сильно упростит код и снимет ограничения на использование синхронных библиотек, а также позволит сосредоточиться на изучении механизмов FastAPI, вместо погружения в «глубокую нору» асинхронной разработки.

🌟 Код-ревью — это проверка кода, написанного разработчиком для решения задачи, перед вливанием в основную ветку проекта.

✅Почему это полезно?

👉 Прокачивает навыки — вы учитесь на реальных примерах, а не на своих ошибках.

👉 Ускоряет рост — без код-ревью можно годами оставаться на одном уровне.

👉 Заставляет анализировать свой опыт. Если вы сами делаете код-ревью и объясняете, почему предложенное вами решение будет лучше.


Разбираем пользу код-ревью в нашей статье. Читайте и делитесь впечатлениями в комментариях!

Кофеин, стресс и бесконечные митинги: жизнь настоящего проджекта

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

Важно, что менеджеров в IT, около IT и вообще, много. Сегодня мы говорим именно про менеджеров проектов, не про продуктовых, операционных, аккаунт, бренд или каких-то ещё. Если будет интересно, в следующих постах поговорим и о других.

Сегодня Артем Каменев, ПМ с опытом 5+ лет поделится с нами своим опытом. Начнём сразу с самого больного вопроса.

❓Почему программисты ненавидят PM-ов?
Чаще всего, потому что не знают или не понимают, для чего они нужны.

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

❓Что делает PM?
✏️Следит за соблюдением планов и договоренностей;
✏️Отчитывается перед руководством компании о расходах и сроках проекта;
✏️Демонстрирует прогресс для заказчиков, неважно внешние они или внутренние;
✏️Собирает обратную связь по проекту со всех заинтересованных.

❓Как он это делает?
✏️Ведёт задачи в таск-трекере и следит за тем, чтобы другие вели их правильно;
✏️Проводит регулярные и точечные встречи с командой и заказчиком;
✏️Отслеживает трудозатраты и расходы по проекту;
✏️Заполняет отчёты и ведёт статусные страницы в вики-подобном формате;
✏️Переписывается. Постоянно и без остановок.

❓Какие бывают подходы к управлению проектами?

Подходов и фреймворков для ведения проектов много. Однако, их можно разделить на 3 категории:

👉 Каскадный (waterfall) подход. В IT чаще всего встречается в небольших проектах (1-3 месяца) и при работе с гос. организациями.

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

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

👉Гибкий (AGILE) подход — встречается повсеместно и постоянно, т.к. гибкость понятие очень широкое :)

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

Гибкий подход универсален и разнообразен, в неопытных или ленивых руках может привести к хаосу. Тем не менее, он лучше всего подходит в условиях, когда нет чёткого ТЗ или требования меняются слишком часто.

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

👉 Гибридный подход — берём лучшее из каскадного и гибкого подходов, смешиваем и наслаждаемся.

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

Именно этот формат работы лучше всего подходит аутсорс командам. Когда требование «сделайте красиво», но бюджет «100 тысяч и не копейкой больше».

Коротко описать гибридный подход можно словосочетанием — управляемый хаос. По факту именно из-за необходимости управлять хаосом и растёт количество менеджеров разного формата.

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

➡️ Какой у вас опыт работы с ПМ-ами? Кто был наихудший, а кто наилучший и почему? И присылайте ваши любимые мемы про проджектов в комменты!