Комментарии 14
Вот почему вместо толкового гайда, особенно если у вас есть понимания и опыт (считай есть экспертиза), вываливать сгенерированный нейронкой контент, в котором практическая польза около нуля? Ну это так, риторический вопрос.
Практический вопрос - зачем эти паттерны и архитектурные ухищрения нужны в принципе, и в пайтоне в частности? Какую проблему вы предлагаете решать с таким подходом? Я лишь вижу перегруженный код, который сложнее рефакторить и сопровождать в будущем, а если я был бы начинающим разработчиком, то я в принципе не понял зачем это все нужно?
Хорошо, что есть комментарии, их можно сразу прочитать и понять, стоит ли статья того, чтобы тратить на нее время. Спасибо вам
Что бы была публикация на хабре вестимо!
Это как с научными работами - важен не результат, а процесс.
Почему нейронкой? В упор не вижу признаков ИИ в тексте. Статья хорошая и практичная, сохранил в закладки.
зачем эти паттерны и архитектурные ухищрения нужны в принципе, и в пайтоне в частности?
На этот вопрос ответ в статье даётся, и довольно подробный.
В статье ответ на вопрос "Зачем это нужно?" такой:
"Посмотрите как хорошо, вы можете подменить коннекшен базы mssql, на коннекшен postgres"
А в реальных проектах зачем вам менять коннекшен ms на pg? У вас две одинаковые базы и вы каждый день подкидываете монетку и определяете из какой базы вы потащите данные? У них же даже диалекты разные, толку то от смены типа коннекшена, если прямой sql запрос выполнится либо в одной, либо в другой системе, а в другой упадёт с синтаксической ошибкой?
Там SQLAlchemy наверное это все абстрагирует. Но в целом вопрос справедлив зачем нужна такая модульность. Для небольшого проекта это оверинжиниринг КМК. Но вот если вы пишете продукт, который потом еще где-то интегрируется а то и не в одном месте и с конфликиующими условиями, то модульность бд может быть реальным юзкейсом. В любом случае это не уровень "все новички пишите так".
Почему нейронкой? В упор не вижу признаков ИИ в тексте.
Да, я слышал, что нейронки могут уже успешно проходить тест Тьюринга.
Спросил у GPT4o два вопроса, сами сравните результаты.
В чем преимущества указания типов в python?
Указание типов в Python имеет несколько преимуществ, которые могут значительно улучшить качество и поддерживаемость кода. Вот основные из них:
Улучшение читаемости и документации:
Аннотации типов служат своего рода документацией, которая помогает разработчикам быстрее понять, какие типы данных ожидаются и возвращаются функциями и методами.
Это особенно полезно в больших проектах или при работе в команде, где код читают и используют другие разработчики.
Раннее обнаружение ошибок:
Статические анализаторы кода, такие как mypy, могут использовать аннотации типов для проверки соответствия типов во время разработки. Это позволяет обнаружить ошибки, связанные с типами, до выполнения кода.
Это помогает избежать распространенных ошибок, таких как передача неправильного типа аргумента в функцию.
Улучшение автодополнения и рефакторинга:
Современные IDE и текстовые редакторы, такие как PyCharm, VSCode и другие, могут использовать аннотации типов для улучшения автодополнения и навигации по коду.
Это делает процесс написания кода более удобным и быстрым, а также помогает избежать ошибок при рефакторинге.
Повышение производительности:
Хотя аннотации типов сами по себе не влияют на производительность выполнения кода, они могут помочь оптимизировать код. Например, компиляторы и интерпретаторы могут использовать информацию о типах для оптимизации выполнения.
В некоторых случаях, использование аннотаций типов может помочь разработчикам выявить узкие места в производительности и оптимизировать их.
Совместимость с другими инструментами:
Аннотации типов делают код более совместимым с различными инструментами анализа кода, генераторами документации и другими утилитами, которые могут использовать информацию о типах для улучшения своей работы.
Почему нам нужно разделить приложение на слои
Разделение приложения на слои (или уровни) является одной из ключевых архитектурных практик в разработке программного обеспечения. Это помогает создать более структурированный, поддерживаемый и масштабируемый код. Вот основные причины, почему это важно:
Модульность и повторное использование:
Разделение на слои позволяет изолировать различные части приложения, что делает их более независимыми и модульными.
Это упрощает повторное использование кода, так как каждый слой может быть использован в других проектах или компонентах.
Упрощение тестирования:
Слои позволяют легче тестировать отдельные компоненты приложения. Например, можно тестировать бизнес-логику независимо от пользовательского интерфейса или базы данных.
Это способствует более эффективному написанию модульных тестов и интеграционных тестов.
Улучшение поддержки и расширяемости:
Четкое разделение на слои упрощает понимание и поддержку кода. Разработчики могут легко вносить изменения в один слой, не затрагивая другие.
Это также облегчает добавление новых функций и компонентов, так как изменения в одном слое минимально влияют на другие слои.
Разделение ответственности:
Каждый слой отвечает за свою конкретную задачу. Например, слой представления отвечает за отображение данных пользователю, слой бизнес-логики — за обработку данных и принятие решений, а слой данных — за взаимодействие с базой данных.
Это способствует более четкому и логичному распределению обязанностей между различными частями приложения.
Масштабируемость и производительность:
Разделение на слои позволяет легче масштабировать приложение. Например, можно отдельно масштабировать слой данных, если он становится узким местом.
Это также помогает оптимизировать производительность, так как можно фокусироваться на оптимизации конкретных слоев.
Безопасность:
Слои могут помочь улучшить безопасность приложения, так как можно изолировать критически важные компоненты и ограничить доступ к ним.
Например, слой данных может быть защищен от прямого доступа извне, что снижает риск несанкционированного доступа.
Совместная работа и управление проектом:
В больших командах разделение на слои позволяет распределить работу между различными группами разработчиков. Каждая группа может работать над своим слоем, что улучшает координацию и управление проектом.
Это также помогает в управлении зависимостями и интеграцией различных частей приложения.
Пример типичной многослойной архитектуры:
Слой представления (Presentation Layer):
Отвечает за отображение данных пользователю и взаимодействие с ним.
Примеры: веб-интерфейсы, мобильные приложения, консольные интерфейсы.
Слой бизнес-логики (Business Logic Layer):
Содержит основную логику приложения, правила и алгоритмы.
Примеры: обработка данных, принятие решений, выполнение бизнес-правил.
Слой доступа к данным (Data Access Layer):
Отвечает за взаимодействие с базой данных или другими источниками данных.
Примеры: ORM (Object-Relational Mapping), репозитории, API для работы с базой данных.
Слой данных (Data Layer):
Содержит сами данные и механизмы их хранения.
Примеры: базы данных, файловые системы, внешние API.
Такое разделение помогает создать более структурированное и управляемое приложение, что в конечном итоге приводит к более качественному и надежному программному обеспечению.
Я свечку не держал, да и вряд ли автор признается в использовании нейронки, если и использовал. Возможно, конечно, что это все составлено самим автором, и у него модель повествования схожа с форматом нейронки, и что форматирование статьи совпадает с тем, как формирует нейронка, и что просто автору нравится делать много списков с вложенными списками на два-три предложения, и что автор предпочитает вместо конкретных примеров использовать максимально абстрактные и общие доводы. Все конечно может быть.
Не знаю как думает автор, а мое понимание решаемой DI проблемы это попытка переизобрести систему модулей и классов в питоне в таком формате, чтобы она сохранила гибкость дак тайпинга, но позволяла производить качественный статический анализ кода через систему подсказок типов. Выглядит, конечно, ужасающе перегружено. Новичкам я бы такое рекомендовать не стал потому что без понимания зачем все это нужно правильно это применить не получится все равно. А понимание зарабатывается только шишками набитыми на собственных плохо написанных программах.
А понимание зарабатывается только шишками набитыми на собственных плохо написанных программах.
Тут беда в том, что очень многим вообще плевать, как написана программа, если она работает, и лично автор сможет там что-то починить. Так можно говнокодить годами, наплевав на архитектуру
Рискуя нарваться на еще большее количество минусов без аргументации хочу спросить: а не должно быть наплевать? Если софт удовлетворяет всем поставленным требованиям, то что еще надо? Уточню сразу, что пригодность к расширееию, тестируемость и документация это все требования к софту которые чаще всего есть, но которых может и не быть в силу специфики конкретной задачи.
Уточню сразу, что пригодность к расширееию, тестируемость и документация это все требования к софту которые чаще всего есть, но которых может и не быть в силу специфики конкретной задачи.
С этим не спорю, моя мысль в том, что понимание не всегда(никогда не) сваливается из неоткуда в процессе кодинга, а берется из других источников, например, книг.
Благодаря структурированию приложения с использованием ООП и DI, код становится более модульным, его легче тестировать, и он становится гибким к изменениям, таким как замена зависимостей или изменение конфигурации
...и гораздо хуже читаемым. Без толковых комментариев (которые в нём отсутствуют) рандомному джуну в нём будет намного сложнее разобраться, да и не только джуну.
Для тех кейсов, которые разбираются в статье, как раз-таки процедурный подход будет куда удобнее (особенно, по отношению к тем, кто этот код потом, возможно, будет изучать), чем ООП.
А если говорить о преимуществах ООП над процедурным, тогда и нужно приводить в в пример такие задачи, в которых явно будет очевиден плюс первого подхода.
Вместо этого объяснение, почему такой подход себя оправдает, если или когда проект разрастается. Вот именно что "если или когда". А до этого куда более понятен первый вариант. Со всеми его "минусами".
Теоретические выкладки в статье хорошие, полезные, но практические примеры не соответствуют:)
Основы архитектуры для джунов: построение масштабируемых и чистых приложений на python (Туториал)