Давайте поговорим о том, как писать правильные сообщения к коммитам. Так сложилось, что писать их приходится всем, но не все делают это правильно: иногда кажется, что какая-то дополнительная работа, которую не обязательно делать хорошо. А во время ревью кода до сообщений редко доходит очередь: есть, что ещё обсудить. Вы наверняка делали коммиты с сообщением «small fixes», да? :)
Но при этом часто бывают ситуации, когда правильные сообщения у коммита резко упрощают жизнь: надо посмотреть, кто, когда и зачем менял что-то в конкретном модуле или почему вот тут стоит такой странный условный оператор. Если у коммита с добавлением этого кода будет сообщение «add weird if», это вряд ли поможет, а вот, например «add nds calclulation for germany» даст куда больше информации.
Давайте соберём чеклист хорошего сообщения к коммиту:
1. На английском. У нас ведь код проекта на английском. Странно переводить его на русский, чтобы читающий потом перевёл его на английский. Если комментарий на русском, получается такой излишне длинный путь: сначала автору кода надо перевести свой код («class Payment: …») на русский («класс платежа»), чтобы потом читающий коммит совершил обратный перевод: «а, класс платежа — это, наверное, Payment». Если писать сразу на английском, этого можно избежать.
2. С дополнительной информацией. Сообщение «add Payment class» выглядит странно: любой может увидеть, что добавлен класс Payment по содержанию коммита, незачем писать об этом в сообщении. Зато можно написать, зачем были внесены изменения: «refactor intergration with Yandex.Kassa». Так сообщения будут нести больше пользы: по логу можно будет понять, какие именно проблемы решались, а не просто увидеть тот же список изменений, что и в diff.
3. Не длинный. Одна строка, не больше твита (старого, в 140 символов). Сообщения стоит делать лаконичными, чтобы в них была сформулирована самая суть изменений без лишней информации.

#deeppostpythonfs

🐍 Как работать с сессиями БД в SQLAlchemy, чтобы общение с базой данных было наиболее оптимальным, защищённым от ошибок и лишнего потребления ресурсов?

Тема пригодится для курса «Разработчик Full Stack на Python». Курс начнётся 28 декабря, поэтому поторопитесь!

Кстати, вчера был открытый урок на тему «Функциональное программирование и работа с данными». Если не смогли присутствовать онлайн, смотрите запись!

📝 Ну а теперь давайте разберём основные ошибки в SQLAlchemy и способы их избежать!

#deeppythonfs #deeppostpythonfs

Сначала давайте разберёмся с тем, какие в SQLAlchemy есть сущности для работы с сессиями и за что они отвечают. Основных три:
– session,
– sessionmaker,
– scoped_session.

Session – непосредственно класс сессии. В его экземпляре хранятся изменения в текущей сессии, его можно настроить на автокоммит, он умеет отправлять данные в БД и ещё много чего.

Sessionmaker – фабрика для создания экземпляров Session с заданными параметрами. Это просто штука, которая немного упрощает жизнь: вместо того, чтобы каждый раз указывать список аргументов у сессии, его достаточно один раз указать у фабрики, а дальше уже создавать сессии без указания аргументов.

Наконец, scoped_session – это хранилище уже созданных сессий, каждая из которых привязана к своему треду. Если вызвать сконфиругированный экземпляр scoped_session в новом треде, он создаст новую сессию, а если потом из этого же треда вызвать scoped_session во второй раз, он вернёт ту же сессию, а не создаст новую.

А теперь несколько советов:

– Передавать в каждую функцию сессию – это явно, но не обязательно. Достаточно использовать глобальную scoped_session: это не создаст нового коннекта в БД. Это делает функцию грязной и создаёт неявную зависимость, но и с этим можно бороться: например, сделать такую функцию методом модели или поселить в отдельный модуль, в котором все функции общаются с базой.

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

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

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

Больше теории практики у нас на курсе «Разработчик Full Stack на Python»: