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

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

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

Вайбкодинг стал словом нарицательным с очень явным налетом чего-то неработающего и вообще 💩. Но так или иначе применение нейросетей набирает обороты и в умелых руках является преимуществом, а не недостатком. Сейчас речь не про замену 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 валидацию и выдохните!

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

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

Заказ. Такая привычная сущность в БД. Так хочется закинуть в админку статусы с выбором: выполнен, оплачен, подтвержден и т.д. Если «повезет», то таких статусов может стать 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 могут получить ревью по проекту!

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