Comments 13
Нынче скилы надо писать, а не шаблоны :)
Честно говоря, таких статей даже на хабре полно, а уж гитхаб такими темплейтами завален вообще. Не обижайтесь на критику, но ничего нового тут не присутствует.
Здесь мы имеем типичный монорепозиторий, заточенный под один конкретный тип проектов. Ну хорошо, вот у вас телеграм-боты. А если ещё веб будет - его тоже в эту же папку мешать, несмотря на то, что там своя структура будет?
Makefile - ну, может быть, вы его и любите, но совершенно он здесь не нужен - хватит и обычного sh/bash. make может по дефолту не стоять, это отдельный пакет build-essential (на Ubuntu), а на рабочие сервера вообще девелоперские инструменты не рекомендуется ставить.
Я всегда критикую привычку использовать переменные окружения, а также класть конфиги в одну папку с кодом. У вас, похоже, оба пункта присутствуют.
пожалуй присодинюсь - проще сделать директорию _templates, накидать туда шаблонов под разные проекты и копировать их через терминал, что то типа Copy-Item -Recurse ".\_templates\ticket_streamlit" ".\20260228_ITSD-XXXX_short_slug" если в винде.
Благодарю за критику! На счёт веб-проектов, то у меня на этом шаблоне и сайт был, так что вцелом ничего) Сайт, конечно, простецкий лендинг, но как будто ему ничего в этом шаблоне не мешало. Модели общие, репозитории общие. Для серьёзнах проектов не годится, но для маленьких MVP - мне было полезно).
На счёт Makefile - очень дельное замечание. Его действительно по умолчанию обычно нет. Но мне в быту часто был нужен и для других дел, поэтому у меня он почти всегда был.
По поводу конфигов вы подали мне неплохую идею! Возможно в следующей статье я вынесу их куда-то и объясню как и почему)
Ещё раз благодарю за ваше внимание и критику
Расскажите, почему решили использовать Makefile, а не питоновское poe the poet?
У нас машины Linux, Windows, Mac. Работает poe хорошо. Но мне интересно, почему именно Makefile?
Шаблон который мы заслужили
Еще очень сыро.
1) Вроде написано, что основано на ЧА, но сервисы почему-то знают что-то об arq и sqlalchemy, а не работают через абстракции.
2) Репозитории возвращают в сервис sqlalchemy модели, а не entity на основе датаклассов. В некоторых случаях это ок, но тут сомнительно.
3) Опять же, сервисы возвращают в хендлер модель sqlalchemy, а не dto.
4) В хендлерах создается сессия к бд. Это можно было вынести в репозиторий.
5) Зачем в хендлерах на каждую команду заново создавать сервисы и репозитории? Почему бы не сделать хендлер на основе класса, добавить тод register, который будет вешать команды на нужный метод класса, а сервисы и репозитории передать в инит?
6) Ну и в целом я бы добавил абстракций, для удобства. Чтобы в сервисах и тд в типах указывать не реализацию, которая зависит от чего-то конкретного, а абстрактные классы, реализация которых может быть любая.
Я устал каждый раз собирать проект с нуля — и сделал универсальный Docker+Python-шаблон