Вредные советы. Храните статусы в базе данных

Заказ. Такая привычная сущность в БД. Так хочется закинуть в админку статусы с выбором: выполнен, оплачен, подтвержден и т.д. Если «повезет», то таких статусов может стать 10, 20, 30… Статусы — это же так здорово и необходимо!


❗️Что получите:
– Никто не разберется в десятках статусов и они будут указываться рандомно;
– Поломку механизмов фильтрации данных по статусам, потому что см. пункт выше;
– Каждое значимое изменение статусной модели будет требовать недели для отладки дата миграций вашей продовой БД;
– Рефакторинг заблокирован, а костыли внутри проекта множатся в геометрической прогрессии.

✍️ Пример из жизни
Интегрировали платежную систему BetaTransfer в один из сайтов. 20 статусов у платежа в документации. Через 4 месяца эксплуатации узнали о 21-ом, которого не было в доке и техподдержка о нем тоже не знала. В общем товарищи накопили тот самый «балласт» статусной модели и потеряли контроль над ситуацией.

📌 Как дойти до жизни такой:
разработать статусную модель для объектов БД на старте,
развивать проект долго,
добавлять новые статусы под потребности бизнеса, не удаляя старые.

❓Может просто статусная модель неправильно была выбрана? Нет, ее в принципе нельзя сделать раз и навсегда в отличии от схемы данных, если она отражает предметную область (см. пост про DDD).

❓А можно удалить ненужные статусы? На них завязан старый код. Удалите — логика рассыплется как карточных домик.

❗️Статусы не являются частью предметной области, т.е. не существуют в реальности. Статусы зависят от контекста и привязаны не к объекту, а к связке Роль — Объект — Процесс. Менеджеру и Клиенту нужны разные статусы одного и того же заказа. Менеджеру нужны разные статусы заказа на разных этапах обработки.

Если Меняется структура команды, меняются бизнес-процессы → меняется набор необходимых статусов и завязанный на них код рассыпается. Если статусы есть в API — тем хуже. На них завязаны интеграции внешних сервисов и менять их совсем больно.

✍️ Как по-другому:

— Использовать и хранить в БД простые поля, привязанные к конкретным событиям: дата оплаты заказа, флаг заказ подтвержден или дата подтверждения заказа, дата доставки заказа и т.д.. Эти свойства существуют в реальности и они не изменятся со временем. Дата оплаты останется датой оплаты.

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

— Перестать воспринимать статус как строковый литерал: «выполнен», «доставлен». Важна не строка, а алгоритм вычисления. Т.е. статус на самом деле — это формула, а не сама строка. В итоге у вас могут появиться в интерфейсе (не в БД!) сложносоставные статусы вроде «одобрен вчера», «рекомендация Юли» и т.д.

❓Как не надо делать API

Каждый разработчик сталкивался с API, который ведет себя неожиданно и в итоге выжирает часы на отладку запросов-ответов и тестирование. Никого уже не удивишь вечным статусом 200 в API ВКонтакте, но это далеко не самый слабый вариант реализации.

В этом году в заказной разработке столкнулись с API Intrum CRM. И вот она разве что нервный срыв у разработчиков не вызвала. Создатели, кажется, совершили все ошибки при разработке API, которые существуют.

❌Отсутствие строгой валидации данных. Запрос отправлен, принят сервером без ошибок. А в CRM часть полей не заполнена. Вот так вот. Разработчик об этом только от менеджера сможет узнать.

❌Некорректное использование GET и POST. Например, удалять записи в Intrum нужно через GET, а получать через POST. Взрыв мозга и бессонная ночь обеспечены.

❌Неполная или устаревшая дока. В итоге никто не знает что и как, пляшем с бубнами и гадаем что и куда подставить. Исходя из странной логики создателей (см. пункт выше), это тот еще квест, потому что все наоборот, как в королевстве кривых зеркал. Проблема решается автогенеренной документацией через OpenAPI + Pydantic в FastAPI или Django Ninja — там те же технологии под капотом.

❌Ошибки со статусом 200. Классика. Все бы ничего, но сервер честно кладет данные из запросов с ошибками в базу данных CRM. Отобразить в веб-интерфейсе при этом не может, т.к. ошибки. Итог — чего только в базе нет…

❌Кастомные поля. Доступны для каждого пользователя, объекта. Корректный вариант — когда доступные атрибуты перечислены и ограничены. Но в данном случае можно создавать любые кастомные поля через техподдержку. Вместо номеров и названий, у полей есть только идентификатор ID. Никто не знает что в этом поле лежит. Неизвестно что прилетит в ответе на любой запрос и что надо отправлять. ID по порядку выдают, судя по всему, уже четырехзначные пошли!

❌Божественный нейминг. Названия полей и их содержание вообще не совпадает. Например, поле «Автор» содержит имя ответственного менеджера. С числами тоже все плохо. Пользователь (User) содержит список сотрудников. А «Типы объектов» требуют строго один идентификатор.

❌Все поля ответа сервера опциональные. Так что даже если сервер и ответит, не факт что там будет хоть что-то или вы сможете расшифровать смысл.

❌Обязательные необязательные поля. Отправляешь запрос, а его не приняли. В запросе не хватает обязательного поля. Какого? Неизвестно. Что в нем должно быть? Неизвестно. В документации поле необязательное. Ну что, кто первый угадает чего не хватило?

✍️Делимся с вами, чтобы вы не повторяли их ошибок! Даже если ИИшка пишет за вас, вычитайте и позаботьтесь о тех разработчиках, которые будут с вашим API взаимодействовать.

Ленты пестрят новостями о сокращениях, увольнениях джунов и «оптимизации» целых отделов. Кажется, что поезд ушел, и нейросети теперь сделают всю работу за нас. Зачем учиться, если через полгода тебя заменят кодом от ChatGPT?

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

— Вместо краткосрочной экономии за счет замены людей ИИ, компания выбирает долгосрочную выгоду за счёт формирования кадрового резерва;

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

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

— Больший эффект достигается при сотрудничестве опытных и молодых специалистов. Опытные привносят стратегическое видение и понимание контекста, а молодые — владение ИИ-инструментами и энергию для поиска новых решений.

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

👉Мы изучили вакансии для Python-разработчиков на hh.ru и увидели, что, как минимум, в четверти из них требуются навыки работы с ИИ:
— В начале марта на hh.ru более 8000 вакансий с упоминанием Python;
— Если исключить слова, связанные с ИИ, то вакансий уже около 6000.

Получить навыки работы с нейросетями вы можете на наших курсах:
— FastAPI: Создаем AI генератор сайтов с нуля
— Курс по FastAPI: чат с ИИ за 4 часа

➡️А вы часто видите вакансии с требованием навыка работы с ИИ? Пишите о своём опыте в комментариях!

❓Стоит ли верить слухам о «вымирании» Python

Несмотря на броские заголовки в СМИ вроде: «Python готовятся сбросить с первого места», язык все еще является одним из самых популярных и востребованных. Действительно, согласно февральскому рейтингу TIOBE, доля Python снизилась до 21.81% (пик был 26.98% в июле 2025).

Как ни странно, теснят Python «старички»: язык C (второе место) и специализированные языки вроде R (рванул с 15й на 8ю строчку) и Perl .

📌Вердикт TIOBE: несмотря на легкое охлаждение, Python остается королем горы с огромным отрывом от конкурентов. Это скорее нормализация после аномального взлета, чем катастрофа. Плюс есть некоторые вопросы к методике оценки рейтинга.

В отличие от опросов разработчиков, TIOBE использует косвенный метод. Он оценивает популярность языка по тому, как часто его название встречается в интернете:
— Поисковые запросы. Индекс подсчитывает количество страниц, найденных по запросу +"<название языка> programming" (например, +"Python programming");

— Источники данных. Поиск ведется не в одном, а в 25 крупнейших поисковых системах и популярных сайтах по всему миру;

— Формула и веса. Результаты из всех этих источников не суммируются просто так. Каждому сайту присваивается свой вес (доля) в финальном результате, который зависит от его популярности.

✍️Итого индекс показывает не то, сколько кода написано на языке или сколько вакансий по нему открыто, а лишь «информационный шум» в интернете и подвержен следующим искажениям:
— Устаревший, но обильно представленный в сети язык может иметь высокие позиции;
— Метод сильно зависит от выбранных поисковых запросов;
— Рейтинги могут значительно колебаться от месяца к месяцу из-за изменений в алгоритмах поисковиков, а не из-за реального роста или падения популярности язык;
— Подверженность накруткам. Теоретически, рейтинг уязвим для искусственного завышения результатов сторонниками того или иного языка.

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

Если смотреть другие рейтинги с другими методами оценки — Python все равно в первой пятерке и исчезать никуда не собирается, так что продолжаем изучать и применять! Веб-разработка, интеграции с ИИ, ML, DataScience без него уже немыслимы.

⚡️ Перенесли курс «Введение в Python: онлайн-магазин» на сайт Девмана!

🌟Вы можете пройти этот курс у нас на сайте!

Чему вы научитесь:
— Запускать Python-скрипты и редактировать код в IDLE
— Создавать строковые объекты и работать с базовыми типами данных
— Импортировать модули и использовать встроенные функции вроде print()
— Применять условные операторы if elif else для построения логики программ
— Взаимодействовать с внешними сервисами через готовые фреймворки

Курс подойдёт даже тем, кто не написал ни одной строчки кода!

Давно мечтали стать Python разработчиком, но все ещё откладываете? Этот мини-курс для вас!

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

👉 Купить курс можно здесь

🌟А те, кто проходил курс «Введение в Python: онлайн-магазин в телеграм за 4 часа» на Stepik могут получить ревью по проекту!

👉 Чтобы получить код-ревью, напишите нам в Телеграм

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

from datetime import datetime

datetime = datetime(2025, 1, 1, 0, 0, 0)
…
datetime = datetime(2025, 2, 1, 0, 0, 0)
print(datetime)

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

После такого объявления доступ к классу datetime пропадёт. Вместо него будет переменная с датой.

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

from datetime import datetime

start_datetime = datetime(2025, 1, 1, 0, 0, 0)
…
end_datetime = datetime(2025, 2, 1, 0, 0, 0)
print(end_datetime)

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

Для получения всех встроенных имён выполните код в python:

import builtins
print(dir(builtins))

✍️Новые возможности генераторов списков

Генераторы списков или List Comprehension — мощный инструмент для высушивания и упрощения кода. Инструмент реализует упрощенный подход к созданию списка, который задействует цикл for, а также инструкции if-else для определения того, что в итоге окажется в финальном списке.

Было:

squares = []
for x in range(10):
    squares.append(x ** 2)

Стало:

squares = [x ** 2 for x in range(10)]

✅Преимущества:
– Простота чтения: без циклов for и вложенности;
– Скорость. Быстрее for-циклов, которые он и заменяет;
– Неизменность данных. Исходные данные изменять опасно, а когда эти данные типа list или dict часто начинаются проблемы. List comprehensions создает новый список, не меняя исходный.

В шестом альфа-релизе Python 3.15.0a6 (февраль 2026) появилась реализация PEP 798 — Unpacking in Comprehensions. До сих пор мы могли распаковывать коллекции внутри литералов списков/словарей ([*a, *b]), но не могли сделать то же самое внутри comprehensions (генераторов списков). PEP 798 исправляет это.

👉Склейка вложенных списков
Раньше:

list_of_lists = [[1, 2], [3, 4], [5, 6]] 
flattened = [x for sublist in list_of_lists for x in sublist]

С новым синтаксисом:

list_of_lists = [[1, 2], [3, 4], [5, 6]]
flattened = [*sublist for sublist in list_of_lists]

👉Слияние словарей

Раньше: цикл с update.

С новым синтаксисом:

dicts = [{"a": 1, "b": 2}, {"b": 3, "c": 4}, {"d": 5}]
merged = {**d for d in dicts}
# {'a': 1, 'b': 3, 'c': 4, 'd': 5}

👉Генераторы

gen = (*range(i) for i in range(3))  # 0, 0, 1, 0, 1, 2

❗️Осторожно:
– В Python 3.15 эта фича пока в альфе. Использовать в продакшене рано, но тестировать уже можно!
– Синтаксис работает только на верхнем уровне выражения. То есть [*x for x in y] — ок, а [x for x in [*y]] (если бы это имело смысл) — нет;
– В асинхронных генераторах пока есть нюансы с yield from.

🐍 Сколько зарабатывает миддл Python-разработчик в 2026 году?

По данным Dreamjob средняя зарплата миддл Python-разработчиков с 2026 году — 233 000 рублей! Но рынок меняется быстрее, чем требования в вакансиях, поэтому хотим собрать актуальную статистику по зарплатам и грейдам среди Python-разработчиков!

Пройдите короткий анонимный опрос — это займет меньше минуты!

🤔Про использование ИИ мы сейчас слышим из каждого утюга. Но так ли эффективно внедрение искусственного интеллекта в процессы?

Согласно отчету MIT, 95% процентов пилотных проектов не влияют на результаты компаний.

Почему так может быть? Мы собрали три ловушки, в которые попадают разработчики, которые используют ИИ-агентов. Делимся первой:

✍️Вайб-кодинг (vibe coding)
— Что это: код генерируется быстро, но критерии приемки и гейты качества либо отсутствуют, либо формальны;
— Симптом: «работает у меня». На следующий день — регрессии, ломается сборка, растёт шум в ревью;
— Пример: агент «поправил авторизацию», но не обновил тесты и не проверил пограничные случаи. Вы узнаете об этом по падению в проде или по жалобам;
— Лечение: сначала сделать базовые гейты обязательными, потом поднимать глубину делегирования написания кода ИИ.

❓А вы используете ИИ-агентов в своей работе и насколько удовлетворены результатами? Пройдите, короткий опрос, который займет меньше минуты! Рассказывайте о проблемах, с которыми сталкиваетесь при использовании ИИ, в комментариях!

Если ответов будет много, мы запостим еще две ловушки, с которыми сталкиваются разработчики!

Видим, что вы часто сталкиваетесь с проблемами при использовании ИИ в разработке. Мы уже писали о первой ловушке, которая мешает разработчикам научиться использовать ИИ в разработке. Сегодня поделимся еще двумя.

✍️Ложная автономность (proxy autonomy)
— Что это: кажется, что «агент делает», но вы всё продумываете за него;
— Симптом: чтобы получить результат, вы пишете слишком подробные инструкции до уровня «вот в этом файле поменяй эту функцию». Быстрее было бы сделать руками;
— Пример: задача выглядит как «сделай фичу», а по факту вы диктуете агенту пошаговый рецепт, потому что без него он не попадает в архитектуру.
— Лечение: поднимать глубину делегирования кодинга там, где можно описать ценность и критерии приемки, а не технические шаги. Инвестировать в контракты (например, схему API) и шаблоны задач.

✍️Разрастание скоупа (scope explosion)
— Что это: агент начинает «улучшать всё подряд»: правит форматирование, переименовывает, меняет архитектуру, добавляет лишние зависимости;
— Симптом: слишком большой набор изменений без понятной цели, много побочных правок, сложно ревьюить;
— Пример: вы попросили «починить баг», а агент параллельно переименовал половину модулей и заменил библиотеку логирования;
— Лечение: жесткие рамки (что трогаем/не трогаем), лимит на размер изменений, стоп-правила («остановись и спроси»), приоритет «минимальное изменение, которое дает ценность».

— Дополнительно: ввести бюджет код-ревью (Code Review Budget): лимит времени и внимания на ревью, под который подгоняете объем изменений;
— Дополнительно: фиксировать архитектуру и ценность ее компонентов, чтобы агент не «оптимизировал» то, что трогать нельзя.

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

👉А с какими еще ловушками при использовании ИИ-агентов вы сталкивались? Делитесь в комментариях!