Паттерны разработки на Python: TDD, DDD и событийно-ориентированная архитектура

@@MaksimG73577 полная шляпа, лучше даже не смотреть

Ты профилировал? Рефлексия не такая тормозная, как class loaders. БОльшая часть времени старта приложения это почти всегда ожидание загрузки классов до их интерпретации.

и живи себе спокойно, в остальных плюс минус так же, просто кто то выебывается, а кто то нет

Странно, долго и нудно писал ответ на этот коммент, а он не показывается 🙄

@@dimusss Обидно, хотелось бы его прочитать

@@vadimv1501 Постараюсь снова написать комментарий... То о чем говорит Григорий про Django/Python на 36:40 минуте могу прокомментировать так. Не скажу про PHP мир, но в рельсах ощущается развитие, желание решать задачи современной разработки. По ощущениям Django где-то застряла и от версии к версии мало что меняется. Заглядывал в мир Рельс и поразился, насколько они стараются и делают жизнь разработчика современных проектов проще и предлагают актуальные, современные инструменты, кажется, почти для всего. Условно в пару команд: rails new theactors --database=postgresql --css=tailwind rails generate scaffold Actor first_name:string last_name:string image:attachment bday:date Можно сгенерировать вполне себе работающий шаблон CRUD проекта для модели Actor с заданными полями, стилями и запущенным Tailwind. У них сразу есть продуманная структура проекта, разбивка тех же настроек на окружения dev, prod и test. Есть готовое решение для создания современного фронтэнда полностью на рельсах - hotwired.dev/ У них есть даже способ оборачивать фронт в приложения - native.hotwired.dev/ (!) Еще у рельсов появился готовый инструмент для деплоя проекта в контейнерах - kamal-deploy.org/ В целом есть ощущение, что идет развитие, вкладываются деньги и есть реальная работа, направленная на решение современных задач. У Джанги же от версии к версии мало что меняется и разработчик должен сам решать, как ему решать ту или иную типовую задачу. Как деплоить джангу? Как сделать современный фронт - React/Vue/Angular или шаблоны+HTMX? Как параллельно в разработке запускать Tailwind/Webpack/Vite? Как сделать вебсокеты ? Чем обжимать картинки? и тд и тп, масса вопросов, от которых Джанга абстрагируется. Вот вам папка для шаблонов, вот папка для статики, кладите туда, что хотите. Про приложения я вообще молчу ) Но! При этом, лично я попробовав некоторые альтернативы Питону и Джанге - Рельсы, Ноду, Go - принял решение остаться на Питоне и Джанге, тк как у нас уже куча когда написано на питоне, можно копипастить решения из проекта в проект, основные боли мы уже знаем, к ним привыкли, а переходя в новый стек столкнешься с новыми проблемами и новыми болями, а кому это надо. P.S. И еще немаловажный момент - вокруг в компаниях питон используется широко, есть вакансии, куча происходит мероприятий, митапов и тд. С Руби все несколько сложнее. Я лично из наших больших проектов знаю только Мегамаркет от Сбера, но по моему опыту сайт работает криво и медленно, и это тоже не добавляет стимула свичнуться на руби.

@@vadimv1501 шок контент, вчера запостил второй раз ответ - его снова нет... пробую третий раз.. То о чем говорит Григорий про Django/Python на 36:40 минуте могу прокомментировать так. Не скажу про PHP мир, но в рельсах ощущается развитие, желание решать задачи современной разработки. По ощущениям Django где-то застрял и от версии к версии мало что меняется. Заглядывал в мир Рельс и поразился, насколько они стараются и делают жизнь разработчика современных проектов проще и предлагают актуальные, современные инструменты, кажется, почти для всего. Условно в пару команд: rails new theactors --database=postgresql --css=tailwind rails generate scaffold Actor first_name:string last_name:string image:attachment bday:date Можно сгенерировать вполне себе работающий шаблон CRUD проекта для модели Actor с заданными полями, стилями и запущенным Tailwind. У них сразу есть продуманная структура проекта, разбивка тех же настроек на окружения dev, prod и test. Есть готовое решение для создания современного фронтэнда полностью на рельсах - hotwired.dev/ У них есть даже способ оборачивать фронт в приложения - native.hotwired.dev/ (!) Еще у рельсов появился готовый инструмент для деплоя проекта в контейнерах - kamal-deploy.org/ В целом есть ощущение, что идет развитие, вкладываются деньги и есть реальная работа, направленная на решение современных задач. У Джанги же от версии к версии мало что меняется и разработчик должен сам решать, как ему решать ту или иную типовую задачу. Как деплоить джангу? Как сделать современный фронт - React/Vue/Angular или шаблоны+HTMX? Как параллельно в разработке запускать Tailwind/Webpack/Vite? Как сделать вебсокеты ? Чем обжимать картинки? и тд и тп, масса вопросов, от которых Джанга абстрагируется. Вот вам папка для шаблонов, вот папка для статики, кладите туда, что хотите. Про приложения я вообще молчу ) Но! При этом, лично я попробовав некоторые альтернативы Питону и Джанге - Рельсы, Ноду, Go - принял решение остаться на Питоне и Джанге, тк как у нас уже куча когда написано на питоне, можно копипастить решения из проекта в проект, основные боли мы уже знаем, к ним привыкли, а переходя в новый стек столкнешься с новыми проблемами и новыми болями, а кому это надо. P.S. И еще немаловажный момент - вокруг в компаниях питон используется широко, есть вакансии, куча происходит мероприятий, митапов и тд. С Руби все несколько сложнее. Я лично из наших больших проектов знаю только Мегамаркет от Сбера, но по моему опыту сайт работает криво и медленно, и это тоже не добавляет стимула свичнуться на руби.

Вездесущие проверки на err != nil говорят об обратном :) Конечно по результатам проверки я могу ничего не делать, но мы то в подкасте говорили про болерплейт-код

@ нет, можно просто поставить _ вместо err . Вот так value, _ := someFunc(). И обойтись без err != nil, компилятор ничего не скажет. Если ошибка это единственное, что можно вернуть, то можно обойтись просто someFunc() или при желании _ := someFunc()

@@lacosteque О, значит я этот момент понимал неправильно, спасибо!

@@korneevm только линтеры будут ругаться, но кого это останавливало в Python :)))

Кек

не работает)))

Так, а какой смысл, если софт выполняет свои функции и приносит деньги. Софт можно править и адаптировать под потребности. Какой смысл бежать за версиями. Когда тратишь свои деньги, то вообще на версии не смотришь, хоть python5

@@cyrillcheckoutну второй пайтон уже своего рода бомба замедленного действия, разработчиков нанимать все сложнее и сложнее будет на такой проект, никому это неинтересно в легаси ковыряться

Да, я надеялся про кошелек Миллера послушать...

На конференции.

pre-commit неудобный способ форматирования. Он отложен, он не нагляден, петля обратной связи длинная. Гораздо удобнее иметь форматирование налету, что рафф обеспечивает моментально. Я не на зачете и уж точно приказы от рандомных людей принимать не собираюсь. Откуда инфа что читаем сотни, а пишем один раз? Переписываем код приложения мы регулярно, так устроена продуктовая разработка. Надеюсь, я не открыл здесь новое. Отсюда и аннотации переписываем ну очень часто, а аннотации на каждом шагу и часто приходится жонглировать ими. Плюс довольно наглядно всегда где аннотации, где нет. А что пугает в длине переменных? У нас стандартное название минимум 8 символов. Если бы все определяла длина переменных, мы бы называли переменные a, b, c и так далее. Но мы так не делаем, т.к. это путает, цепляется за весь код, сложно искать и пользоваться множественными трансформациями. А модуль typing, как назло, содержит слишком общие слова типа optional, any, union и будучи импортнутыми непосредственно без неймспейса, они слишком часто клешатся с именами по коду, что добавляет хаоса. В итоге, это правило стоит не на пустом месте. В общем, уважаемый анон, приказы и зачеты оставь себе.

@@xfenix3 Ну во первых - извиняюсь за тон комментария. Обычно их никто не читает, поэтому позволяю некую вольность в высказываниях. Так проще коментаторов забайтить на дисскусию. А дискуссии я люблю, так как в процессе можна узнать что-то новое, и, или утвердиться в своей точке зрения, или даже поменять. Поэтому эти призывы можете воспринимать как художественный прием, не более. А вот по существу - прочитал Вашу аргументацию. И пока не поменял своего мнения. 1) pre-commit - отложен. Да тут видимо кардинальное несовпадение, потому как мне не нравиться когда поправляют каждый мой чих. Я когда пишу или рефакторю - то там много кода будет не по пепу условно говоря. И мне мешает когда пайчарм исправляет после каждой правки. Ну тут видимо разные привычки - ничего не поделаешь. Но по простоте настройки при-коммит конечно стоит рассмотреть. Так как он не даст закоммитить без форматирования и проверки. Но это уже дело вкуса, а о вкусах не спорят. 2) импорт модуля. Про человеческое именование переменных - поддерживаю двумя руками за. Но это не относиться к использованию typing.Union[str, typing.Optional[int]]. Без typing будет проще прочитать. Ну и это относиться не только к typing, а к любым импортам. Когда жестко клешаться имена - да, это выход. Но в большинстве случаев это исключение. Но кажеться опять начинаеться про вкусы. Одним словом - остаюсь при своем мнении. Я понимаю что это дело привычки, но может набереться критическая маса мнений, и вы все-таки к чему-то когда-то прислушаетесь. Отдельно хочу сказать спасибо за презентацию, было интерестно. Смотрел много ваших выступлений - всегда зачет. За множество мемов и юмор - отдельный лайк. Успехов в работе! Буду ждать следующих докладов.

@@xfenix3 А, еще вспомнил про форматирование на лету - иногда приходиться работать со старым проектом - где автоформатирование точно не желательно. И начинаются вот эти пляски с включением и выключением.

​@@andrewmoon181 1 - это было проблемой на связке black + isort + pyupgrade + docformatter + pybetter и так далее. На ruff это незаметно и никаких проблем не вызывает вообще ни у кого у нас. Оно форматируется на ходу, а сразу пишется прям немного же кода, поэтому все вообще естественно. 2 - это практика, мы убивались об это частенько, постоянно все со всем путалось в именах. Текущий подход исправил проблему. На мой вкус тут можно копья ломать долго, но правду найти не получится. Поэтому я не правду несу, а точку зрения. Между компаниями спорить на эту тему не сильно осмысленно, т.к. везде своя кухня. Главное здесь внутри компаний не ломать копья и унифицировано с этим работать. По поводу включения-отключения да немного раздражает, но обычно даже в старом проекте автоформат норм заходит. Стараемся просто унифицированно на все проекты это раскатывать. Авто-кодинг он чего-то стоит, конечно, но того стоит. Ещё мы когда-нибудь решим уже вопрос с лучшим аи-автокомплитером, полирнём сверху и будет отличная конфигурация для самых ленивых, вроде меня. Спасибо!