Неправильная форма числа ведёт к обманутым ожиданиям и ошибкам. Если related_name в ManyToManyField указан в единственном числе, то запросы с его участием будут выглядеть странно и неожиданно.

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

owners = flat.owners.all()

💙Спасибо вам, что делились своими вариантами в комментариях!

Мы в Макс

Что не так с регулярками (regex)❓

Все хвастаются, что знают регулярки (regex). Даже на собесах про них спрашивают. Но никто не говорит, что с ними не так. Исправляем ситуацию.

На первый взгляд регулярки — это простая и мощная утилита: скопировал, вставил, шустро работает, мало кода.

❗️Но дьявол кроется в деталях:

1️⃣Ты вставляешь выражение в код 15 минут, а через месяц не можешь прочитать.

❓Что делать:
👉 разбить выражение на простые строки с комментариями, используя re.verbose()

import re

pattern = re.compile(r"""
    \b                      # Граница слова
    (?P<year>\d{4})         # Год (4 цифры)
    -                       # Разделитель
    (?P<month>0[1-9]|1[0-2])# Месяц (01-12)
    -                       # Разделитель
    (?P<day>0[1-9]|[12]\d|3[01]) # День (01-31)
    \b                      # Граница слова
""", re.VERBOSE)

2️⃣ Тестирование и доработка регулярных выражений превращается в ад — максимум времени и минимум стабильности.

❓Что делать:
👉 использовать для тестирования сервисы вроде https://regex101.com/,
👉 написать автотесты.

3️⃣ После того, как готовы автотесты, все проверено и доработано возникает вопрос — а зачем? Это было уже совсем не быстро, дешево, сердито!

✅Выход:
👉 Сразу ищите готовую библиотеку, которая закроет вашу проблему: phonenumber для валидации номеров или urlparse для работы с URL адресами.

❌ Не заменяйте регулярку на 100500 if-else. Это убьет читаемость и стабильность кода!

🤔А регулярки то нужны вообще?

Да. Для очень простых случаев вроде [a-zA-Z0-9]+. А еще они часто под капотом тех самых библиотек, при написании которой были вбуханы ресурсы на отладку и тестирование, а вы используете готовый результат.

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

Чистого всем кода!

Мы в Макс

Получили интересный вопрос по ИИ от Ольги. Давайте вместе разбираться!

Какие навыки нужны разработчику, чтобы не тормозить при внедрении ИИ в разработку

Сразу оговоримся — речь не про обучение нейросети на своем сервере, а использование универсальной LLM модели вроде DeepSeek или ChatGPT.

Часть 1. Писать промпты?

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

✍️ Не пишите инструкцию

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

Пример

❌Плохо:

Напиши скрипт, который конвертирует svg картинку в png.

✅Хорошо:

Напиши скрипт, который поможем мне встроить иллюстрации в статью. У меня есть объемные svg файлы. Нужны png. Какие вопросы хочешь обсудить? 

✍️ Не пытайтесь решить сложную задачу в один промпт

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

✍️ Следите за контекстом, избегайте автоматической саммаризации

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

Управление контекстом — это ключевой вид активности. Разработчик перестаёт тратить время на написание кода (этим занимается нейросеть), но сосредотачивается на управлении контекстом: накопление, актуализация, регламенты, инструменты навигации. Без этого далеко не уплыть.

📌Да, есть приёмы, которые делают промпты эффективнее, а работу ИИ стабильнее. Приведем пару лайфхаков:

✅ Мотивация ИИ "спереди"

ИИ не читает красивые документы по проекту, которые вы для него заготовили? Что ж, добавьте желтушные заголовки:

Пример

Прочитай файл RULES.md, чтобы узнать о правилах и не переделывать работу.

ИИ не человек, но его отличная имитация. Так что представьте, что работаете со стажёром, который не ест, не спит и офигенно быстро соображает. Но только в рамках сессии😄 Замотивируйте его прочитать все ваши инструкции!

✅ Мотивация ИИ "сзади"

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

Пример

Веди себя как перфекционист, который боится облажаться.

❓А у вас какие любимые приёмы для промптов?

А с нас ещё про ИИ агентов, вайб-кодинг и какие ошибки совершают разработчики при внедрении ИИ. В один пост не уложились🤷‍♀️

👇 Ставьте огоньки и ждите продолжение!

Мы в Макс

Продолжаем отвечать на вопрос «Какие навыки нужны разработчику, чтобы писать код нейросетями?»

❓Часть 2. Надо ли создавать ИИ агентов?
Обязательно. Просить ИИ написать код просто в режиме чата неэффективно совсем.

Что такое ИИ агент

Агент = обычный ИИ + инструменты. Инструменты позволяют работать с файловой системой, git, открывать сайты, лазить в БД и т.д. Часть инструментов можно найти готовыми, а часть — придется написать самим.

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

Ничего страшного в «создании агентов» нет — сейчас множество платформ создаст их за вас, вы и не заметите. Мы работаем с OpenCode. Можно вести разработку с помощью агентов в VSCode. Вариантов все больше, холиварить не будем — на вкус и цвет все фломастеры разные. В итоге платформа предложит вам готовые скиллы, MCP сервера и много всяких плюшек для работы с агентами.

❌ Не плодите субагентов

В какой-то момент контекст кончится и агент или вы сами подумаете, а чего бы субагентов не добавить. Без крайней нужды не стоит!

Использование субагентов радикально снижает качество работы нейросети. Использование субагентов требует очень зрелой продвинутой инфраструктуры. Управление контекстом субагента — задача со звездочкой. А ИИ без корректного контекста — это обезьяна с гранатой. Для новичков это точно антипаттерн.

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

👇 Ставьте огоньки и ждите продолжение! Расскажите в комментариях о своем опыте работы с ИИ-агентами!

Мы в Макс

Продолжаем отвечать на вопрос «Какие навыки нужны разработчику, чтобы писать код нейросетями?»

Мы уже рассказали про:
— Нужно ли писать промпты
— Нужно ли создавать ИИ-агентов

Сегодня поговорим про вайбкодинг!

❓Часть 3. Про вайбкодинг и «что-то еще»

Надо ли уметь вайбкодить?

Если речь про «иди, сделай за меня» в один промпт (даже со скиллами и MCP-серверами) — это плохой вариант. В 9/10 случаях руками быстрее. Даже если на старте будет что-то путное, доработать продукт, не сломав еще что-то нейросеть не сможет.

✔️ Подойдет для прототипов. Например, как в уроке по FastAPI с генерацией фронта сайта.
✔️ С натяжкой работает для автотестов.
✔️ Ограниченно работает для обновления версий библиотек.

✖️Нейросеть не умеет чинить сложные баги — процесс не сходится: чинит одно и ломает то, что работало. Сложные баги не решаются в один шаг. Сначала надо сформулировать гипотезы, потом проверить их и локализовать проблему, найти варианты решения, в итоге выбрать оптимальный. В итоге, если делать в один шаг, проект застревает на фазе «почти готово» и вы либо дорабатываете вручную, либо переписываете с нуля.

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

Другой подход — выстраивание системы, где ИИ берет на себя не только разработку кода, но и проверку его качества, тестирование. Недавно для него даже появился термин «Агентная разработка».

Человек все еще нужен, но как архитектор и «руководитель». Не надо отдавать ИИ все задачи целиком. Самые сложные решения и задачи остаются под ответственность архитектора, а ИИ выступает как ассистент.

👉 Знаете как проверить качество результата — можно делегировать ИИ

👉 Объясните ИИ в чем ценности результата для пользователя

Нужно ли уметь «что-то еще»?

Да, крайне полезны навыки менеджмента и преподавания.

✏️Пример из обучения. Ученик не может выполнить задачу или выполняет плохо. Нужен дебаг. А теперь ученика заменяем на ИИ — ситуация очень похожая и методы отладки похожие, часто через диалог с агентом. А вот от дебага программного кода отличается значительно и общим подходом, и инструментами.

✏️Пример из управления. Недоверие к результатам нейросети — важная и частая проблема. Именно недоверие заставляет все перепроверять, а проверка съедает все сэкономленное время. Хороший управленец знает куда смотреть, чтобы быстро проверить качество результата задачи, отданной сотруднику. А отличный управленец еще при постановке задаче научит сотрудника, куда смотреть и как самостоятельно проверить результат перед сдачей.

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

Предел сложности

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

👉 Искусственный интеллект работает как линза. Он масштабирует результаты, действуя по принципу: умножает то, что уже есть.

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

Усиление слабых сторон: Если исходная база знаний или навыков слабая, ИИ не компенсирует её, а начинает выдавать «галлюцинации» и логические ошибки. Пользователь без опыта теряет способность перепроверять информацию, что приводит к ухудшению итогового результата.

👇 Ставьте огоньки и ждите продолжение! Расскажите в комментариях о своем опыте вайбкодинга!

Мы в Макс

Продолжаем отвечать на вопрос «Какие навыки нужны разработчику, чтобы писать код нейросетями?»

Мы уже рассказали про:
— Нужно ли писать промпты
— Нужно ли создавать ИИ-агентов
— Про вайбкодинг

❓Часть 4. Мышление

Классический подход к разработке кода — продумать все корнер-кейсы, разработать алгоритм, проанализировать входные и выходные параметры. Интерпретатору Python не надо сообщать что и зачем вы делаете — просто пишите команды, которые надо исполнить. Достигнет ли ваше ПО результата зависит от того, как правильно разработали и реализовали алгоритм.

🌟Но ИИ может круче, если описать что нужно получить и зачем. Нейросеть спросит обо всех важных моментах и предложит решения. При наличии инструментов для тестирования и проверки, ИИ сможет самостоятельно проверить результат. Критерии качества кода должны включать как функциональные требования, так и общие требования к чистоте кода и архитектуре (да-да, то самое ревью Девмана).

👉 Укажите какую задачу нужно решить и зачем, а не давайте простые команды.

Процессы с ИИ сложно тестировать и отлаживать. Причем как элемент в составе ПО, так и как инструмент для написания кода. Отладка принтами уже не поможет, к сожалению😢

👉 Заранее продумайте как вы будете дебажить работу ИИ

С ног на голову меняется процесс разработки — старые подходы начинают рушиться. Скорость написания кода возрастает настолько, что если не подготовиться, то тимлид погибнет в код-ревью. Ну или ваша собственная работа превратиться в постоянное ревью и уточнение задачи. От написания кода избавит, но вряд ли даст ускорение больше, чем на 10-30% (если повезет).

👉 Перестраивайте процессы, внедряйте новые инструменты

❓Наверно, сразу ответим еще на такой вопрос — а когда Devman будет учить кодить с помощью ИИ?

— Уже есть курс для тимлидов, сеньоров и архитекторов, кто готов выстраивать у себя в отделе/компании AI-first процессы разработки и инфраструктуру под них

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

Дело в том, что сейчас структура ИТ-команд поменялась абсолютно. В каждой компании выстраивается своя инфраструктура и процессы ИИ-разработки, создается экосистема инструментов для ИИ.

Причем каждый проект требует донастройки. Как все это впихнуть в курс не на 10 лет для новичков — пока не придумали, но стараемся!

➡️Расскажите в комментариях, каких знаний и навыков работы с ИИ вам не хватает? Какую помощь хотели бы получить?

Мы в Макс

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

constant_number = 15

class some_class():
  ...

def DO_FUNCTION():
  ...

Some_VARIABLE = 'value'

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

➡️Пишите в комментариях, что можно исправить!

Мы в Макс

Используйте в названиях правильный регистр букв.

UPPER_CASE — для глобальных констант
CamelCase — для названий классов
snake_case — для всех переменных, функций, методов, аргументов, полей

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

CONSTANT_NUMBER = 15

_some_variable = 'value'

class SomeClass():
  ...


def do_function():
  ...

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

Если модуль предназначен для импорта с помощью from M import *, PEP 8 советует явно указать, какие глобальные переменные модуль экспортирует. Для этого добавляют префикс из одного подчёркивания (_internal_var) к именам «внутренних» глобальных переменных. Так вы контролируете, что именно будет доступно при импорте.

И спасибо всем за активность в комментариях - вы нашли больше, чем было запланировано!😁

Мы в Макс

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

from environs import Env

def main():
    env = Env()
    env.read_env()
    token = env.str('TOKEN')

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

➡️Пишите в комментариях, что можно исправить!

Мы в Макс

Без точного названия сложно понять для чего нужен токен. Речь идёт одновременно и про переменные в коде, и про переменные окружения.

А если, например, API поддерживает несколько видов токенов, то тем более в названии каждого из них необходимо указать специфический тип.

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

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

from environs import Env

def main():
    env = Env()
    env.read_env()
    geocoder_token = env.str('YANDEX_GEOCODER_TOKEN')

Также хотели бы ответить на комментарии к посту:

1️⃣ Нужно ли задавать значение по умолчанию?
Если такое значение существует или является необязательным, то да, нужно задать. В других случаях, как правильно отметили в комментариях, должно быть исключение, говорящее о невозможности работы программного обеспечения. Лучше узнать об ошибке при деплое, чем через неделю удивиться, что пользователи не могут пользоваться сервисом и уже ушли к конкуренту!

2️⃣ Нужно ли вынести чтение переменных окружения из `main`?
Если речь про вынос из main без обертки, то однозначно нет. Т.к. чтение переменных окружения будет запускаться при импорте модуля. Чтение настроек приведет к ошибки на этапе инициализации модуля. Такие исключения тяжело перехватывать и обрабатывать, поэтому так делать не рекомендуется. Сначала инициализация: какие функции объявлены, какие модули импортированы, потом исполнение, включая чтение переменных окружения и непосредственный вызов функций.

3️⃣ Нужно ли убрать строку `env = Env()`?
По официальной документации, текущий двустрочный вариант рекомендуется для Django. Способ чтения зависит от того, с каким фреймворком используете библиотеку environs.

💙Спасибо вам, что делились своими вариантами в комментариях!

Мы в Макс

Нужно ли учиться код-ревью❓

Сначала разберёмся, что такое хорошее код-ревью. Это не попытка «кодить руками» разработчика — «замени на», «добавь синглтон», «перемести код в эту функцию». Хороший ревьюер формулирует проблему, которая мешает код читать или пользоваться. Он задаёт наводящие вопросы: «Функция так названа, а по коду делает другое — это так?». Автор сам должен понять замечание, провалидировать его и применить. Критерий качества один: ты не диктуешь решение, а показываешь проблему.

✅Кому и когда это реально нужно:
— Тимлиду, который даёт обратную связь авторам кода;
— Программисту в команде с перекрёстным ревью;
— Каждому, кто работает с нейросетями и по сути становится их тимлидом.

❓Как этому научиться? 
1️⃣ Делать ревью. Чем чаще, тем лучше. Ревьюить код нейросети – отличный вариант для начала. 

2️⃣ Делать ревью — необходимо, но недостаточно. Чтобы замечать больше проблем, нужно качать насмотренность. Нужен либо огромный собственный опыт, либо чужой. 

Где набраться чужого опыта:
— Книги про чистый код, паттерны проектирования и около того. Обращать внимание на кейсы: что доставило проблемы, как исправили;
— каталог улучшений Devman;
— код-ревью, полученные от старших товарищей – свои и чужие, если есть возможность посмотреть.

🎯 Главная трудность — не формулировки, а умение проблему увидеть и осознать. Начинающие обычно говорят: «Я так не делаю, я делаю по-другому», но не понимают, что будет плохого, если оставить текущую реализацию. А это и есть суть ревью.

👉 Статья «Грейд разработчика приходит с годами, но иногда годы приходят одни: зачем вам код-ревью»
👉 Пост «Секретный ингредиент уроков Девман –  код-ревью»

✅Итого: навык сам не появится, если его не качать. Нужна практика + насмотренность. Ну а все курсы Devman заканчиваются код-ревью действующего разработчика — так накопленный опыт команды достаётся вам. Сдавайте уроки — мы уже заждались!

Мы в Макс