Копипаста кода — это плохо.

1️⃣ Если код нужно будет поменять — придётся искать все места, где он использовался и менять его везде, по всем файлам.

2️⃣ Если в коде будет ошибка — её не получится исправить разом, в одном месте, придётся опять же искать все места, где использовался этот код и чинить его несколько раз.

3️⃣Чем больше кода — тем труднее его читать.

Код из нашего примера может выглядеть так:

def get_expected_salary(salary_from, salary_to):
    if not salary_to and salary_from:
        return int(salary_from * 1.2)
    if not salary_from and salary_to:
        return int(salary_to * 0.8) 
    if salary_from and salary_to:
        return int((salary_from + salary_to) / 2)


def predict_rub_salary_hh(hh_vacancy):
    if not hh_vacancy or hh_vacancy.get('currency') != 'RUR':
        return

    salary_from = hh_vacancy.get('from')
    salary_to = hh_vacancy.get('to')

    return get_expected_salary(salary_from, salary_to)


def predict_rub_salary_sj(sj_vacancy):
    payment_from = sj_vacancy.get('payment_from')
    payment_to = sj_vacancy.get('payment_to')
    currency = sj_vacancy.get('currency')

    if currency.lower() != 'rub':
        return

    return get_expected_salary(payment_from, payment_to)

P.S. Спасибо нашим подписчикам за внимательное ревью!❤️ По ходу избавились от пустых return и elif. Если еще есть идеи как улучшить код — пишите свои варианты в комментариях!

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

from django.db import models


class Owner(models.Model):
    ...

    def __str__(self):
        return f'{self.name}'

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

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

Код из нашего примера может выглядеть так:

from django.db import models


class Owner(models.Model):
    ...

    def __str__(self):
        return self.name

❓Как оптимизировать запросы к БД

«Магия» оптимизации запросов в Django ORM — это один из ключевых навыков для борьбы с перегрузом БД и тормознутостью сайта. Проблемы возникают, если использовать реляционную БД со сложными отношениями между таблицами: ForeignKey, ManyToMany.

📌Пример: запросили из базы список постов. Таблица постов связана с таблицей авторов. Если их не запросить сразу, то на каждый пост придется делать ещё запрос для получения автора. С ростом количества постов это приведет к огромному количеству запросов и перегрузу базы.

✍️Цель и метрики
Изначально хочется минимизировать количество запросов к БД. Но еще есть время обработки запроса на стороне базы данных. Чаще всего время обработки запроса в базе пропорционально количеству запросов, но есть исключения.

✍️Инструменты
В уроках курса по базам данных мы предлагаем использоваться Django Debug Toolbar для замера основных метрик: количество запросов, количество дублей, время обработки запроса на стороне БД, общее время запроса.

✍️Методы Django ORM

➡️`select_related`: один жирный JOIN
select_related использует оператор SQL JOIN (внешнее соединение) чтобы присоединить таблицы связанных объектов по внешнему ключу (ForeignKey или OneToOneField) к основному запросу.

Что происходит:
— Django строит один большой SQL-запрос с JOIN.
— База данных возвращает одну таблицу, где строки дублируются для данных из связанных таблиц. Т.е. если уникальных авторов всего два, то строк в таблице будет столько, сколько постов.
— ORM преобразует эту таблицу в объекты Python, уже связанные между собой.

Когда использовать: Когда вам нужно перемещаться «вперед» по связи — от объекта к связанному (книга -> автор). Идеально для связей «один к одному» и «многие к одному».

# ПЛОХО: N+1 запрос
books = Book.objects.all()
for book in books:
    print(book.author.name)  # Новый запрос к БД на каждой итерации!

# ХОРОШО: 1 запрос
books = Book.objects.select_related('author').all()
for book in books:
    print(book.author.name)  # Данные автора уже загружены!

➡️`prefetch_related`: Умная загрузка комплектами

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

Что происходит:
— Django выполняет первый запрос для получения основных объектов (например, авторов).
— Затем второй запрос (или несколько) для получения ВСЕХ связанных объектов для этих основных (например, всех книг этих авторов).
— В Python ORM создает словарь-кэш и подставляет нужные связанные объекты к каждому основному. Используется оператор SQL IN.

# ПЛОХО: N+1 запрос
authors = Author.objects.all()
for author in authors:
    for book in author.books.all():  # Новый запрос на каждом внешнем цикле!
        print(book.title)

# ХОРОШО: 2 запроса
authors = Author.objects.prefetch_related('books').all()
for author in authors:
    for book in author.books.all():  # Книги для всех авторов уже загружены в кэш!
        print(book.title)

✍️Исключения

Иногда на глубоких цепочках (select_related('a__b__c')) JOIN может стать слишком тяжелым, и prefetch_related будет эффективнее.

Пример есть в уроке Знакомство с Django: ORM. Помните блог с постами, где нужно было оптимизировать запросы? В уроке были расплывчатые рекомендации, так что мы ещё раз их проверили.

Для метода tag_filter получили статистику на увеличенном вдвое количестве постов в БД с помощью Django Debug Toolbar:

select_related: 31 запрос, SQL ≈ 0.1288s, elapsed ≈ 0.1350s
prefetch_related: 33 запроса, SQL ≈ 0.0922s, elapsed ≈ 0.0980s

При увеличении количества постов результаты сохраняются:
— select_related делает на 1-2 запроса меньше,
— время обработки запроса для prefetch_related на 40% меньше

Итого: prefetch_related — лучший вариант оптимизации.

P.S. Но скажем по секрету, если вы использовали любой из методов — это уже неплохо! Ну а проверить что эффективнее, лишним никогда не будет ;-)

P.P.S. Напоминаем, что у нас открыта запись на курс по БД! Успейте забронировать осталось всего два места!

👉 Для записи напишите нам в Телеграм!

⚠️ Сайт временно не работает. Чиним.

✅ Сайт работает

ИИ-разработка: подходы

Вайбкодинг стал словом нарицательным с очень явным налетом чего-то неработающего и вообще 💩. Но так или иначе применение нейросетей набирает обороты и в умелых руках является преимуществом, а не недостатком. Сейчас речь не про замену stackoverflow, а именно написание кода с помощью LLM.

AI Oriented Development
AI не является самостоятельным разработчиком, а скорее ассистентом. Это умные подсказки в IDE, генерация документации, автотесты, помощь в отладке.

По разным данным эффективность использования составляет от минус 19 % (METR) до плюс 20 % (Google) к производительности разработчика. Причем чем выше квалификация разработчика, тем хуже результат.

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

AI Driven Development (AIDD)
Разработчик, а точнее архитектор ПО (Solution Architect), разрабатывает ТЗ и архитектуру -- ИИ пишет код, верстает, тестирует. Архитектор ревьюит и принимает решение вливать ли код в main или отправляет на доработку.

И тут открывается совершенно новый процесс разработки, когда не надо держать в штате 100500 узких спецов под каждый стек, заказчик быстрее видит результаты и может сделать гораздо больше за тот же бюджет, ИТ компании становятся более гибкими и маневренными. Разве что на сервера пока пускать стрёмно, но через несколько лет и это будет возможно. Причем уже сегодня писать качественный код можно на обычных LLM без обучения и тонкой настройки специализированных нейросетей. Да, не хватает языка и инструментов для работы с требованиями и подготовки контекста с учётом лимитов для ИИ. И да, google задрал блочить российские аккаунты, но будущее уже наступает на пятки!

Осталось разобраться где брать этих самых крутяшек архитекторов в достаточных количествах🤔

⚠️ Сайт временно не доступен. Обновляем кластер.

✅ В 21:24 завершили работы

💥Делимся хорошей новостью! До 7 марта действует кэшбэк на оплату наших курсов картой Т-Банка 15%!

💵Акция действует для тех, кто:
— Оплачивает услуги школы впервые через этот банк;
— Оплачивает услуги не через СБП.

👉Успейте воспользоваться выгодой при оплате наших курсов:
— «Профессия Middle Python/Django разработчик»
— Мини-курсы
— Курс по FastAPI
— Курс «Проектирование баз данных»

Остались вопросы? Напишите нам в Телеграм!

⚡️⚡️Напоминаем, что у нас открыта запись на курс по базам данных!

🔥Что будет в программе курса:


⚡️Декомпозиция и проектирование функций программного продукта
⚡️Описание требований на базе Domain Driven Design
⚡️Проектирование схемы БД.
⚡️Отрисовка схемы БД в draw.io
⚡️Реализация моделей и QuerySet-методов в Django ORM
⚡️ 6 индивидуальных созвонов с Евгением Евсеевым.

📌Чтобы принять участие в интенсиве, нужно:
👉 Иметь опыт работы с Django ORM (знать основные связи между моделями, уметь писать и оптимизировать запросы, в том числе с агрегацией, есть опыт схема- и дата-миграций);
👉 Иметь базовый опыт по работе с Django, уметь настраивать админку

Если вы проходили наши мини-курсы Django ORM и Django до 2 урока включительно, то их достаточно для участия в интенсиве.

Максимальная польза — если управляли проектами или был опыт разработки или доработки схем баз данных.

🌟Что вы получите:
🔥 Уникальную возможность поучаствовать в разработке совместного проекта с Евгением Евсеевым;
🔥 Возможность прокачать навыки в проектировании БД;
🔥 Жесткое ревью кода от Евгения Евсеева;
🔥 Множество инсайтов, кейсов из опыта Евгения и тайных знаний.

🚀Стартовать можно в любой день до конца февраля!

❗️Успейте забронировать! Осталось всего два свободных места!
👉 Для записи на курс напишите нам в Телеграм!

❓Кому нужен DDD?

✍️DDD (Domain-Driven Design) — предметно-ориентированное проектирование — это подход к разработке сложных программных систем, который фокусируется на создании программной модели, максимально точно отражающей предметную область, бизнес-логику и процессы. DDD не является конкретной технологией или фреймворком, это набор принципов, паттернов и практик.

📌Ключевые концепции DDD:
— Единый язык, понятный и разработчикам, и специалистам со стороны бизнеса. Он используется как для коммуникации, так и для названий классов и методов;

— Декомпозиция системы через ограниченные контексты, когда большая система разбивается на логические модули не от балды, а отражая естественную декомпозицию в реальной предметной области. Естественную декомпозицию можно нащупать через кластеризацию сущностей и их связей — бьём их по как можно более слабо связным кучкам. Это и есть принцип Low Coupling (низкая связанность) и High Cohesion (сильное зацепление). Только применять его надо не только к коду, а к сущностям предметки (домена);

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

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

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

❌Как делать не надо мы рассказывали здесь

📌Когда и кому использовать DDD?

— Сложные бизнес-процессы. Тут главные критерий и симптом — это скорость погружения нового сотрудника в проект. Если за вычетом специфических технологий и инструментов подробный и исчерпывающий рассказ не укладывается в полчаса – значит, вам нужен DDD.

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

Итого — DDD позволяет разработать архитектуру программного продукта, которая выдержит проверку временем.

Принципы DDD нужны архитекторам и тем, кто разрабатывает схемы базы данных.

➡️В нашем курсе «Проектирование баз данных» вы сможете попробовать DDD на практике! Успейте забронировать сейчас и стартуйте в любое время до конца февраля!

👉 Для записи напишите нам в Телеграм!

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

def do_something(value):
    print(value)
    ...

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

➡️Делитесь своими ответами в комментариях!

Отладочных print вообще не должно быть в рабочем коде при коммите. Если что-то нужно выводить в консоль, используйте logging.

Код из нашего примера может выглядеть так:

def do_something(value):
    ...

Или так:

def do_something(value):
    …
    logging.info(value)

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

for number, link in enumerate(response.json()['links']['flickr']['original'], start=1):
    ...

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

➡️Делитесь своими ответами в комментариях!

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

Код из нашего примера может выглядеть так:

image_links = response.json()['links']['flickr']['original']
for number, link in enumerate(image_links, start=1):
    ...

Если ответ на запрос будет еще где-то использоваться, то его следует закэшировать:

response = response.json()
image_links = response['links']['flickr']['original']
for number, link in enumerate(image_links, start=1):
    ...

По поводу обработки корнер-кейса с отсутствием значений в словаре: если применить метод get(), то получится нечто страшночитаемое вроде:

image_links = data.get('links', {}).get('flickr', {}).get('original', 'default.jpg')

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

try:
    image_links = response.json()['links']['flickr']['original']
except KeyError as exc:
    raise CustomException() from exc

Итого — get() хорош, но все-таки когда одноуровневый словарь и есть реальное значение по умолчанию, которое можно и нужно использовать.

Но ошибка то может быть не только из-за пустого словаря…😱

try:
    image_links = response.json()['links']['flickr']['original']
except (KeyError, json.JSONDecodeError, UnicodeDecodeError) as exc:
    raise CustomException() from exc

Так что прикрутите Pydantic валидацию и выдохните!

Спасибо большое, что активно писали в комменты и предлагали свои варианты!❤️