Comments 25
Каждая новая исключительная ситуация должна приводить к созданию нового типа (класса) исключения. Имя класса должно семантично описывать эту ситуацию.
Но вы же сами себе противоречите, приводя такой пример:
try {
$this->connection->query($data);
} catch (\PDOException $e) {
throw new DataBaseException(\i18n('Error on sql query execution: ' . $e->getMessage(), $e->getCode()), $e);
}
То есть вы перехватываете исключение общего вида (\PDOException) и вводите свое исключение общего вида DataBaseException. Какой в этом смысл? Чем DataBaseException лучше \PDOException? Даже Query из него не вытащить же.
При проектировании приложения, абстракция — это то, что добавляет гибкости, и позволяет откладывать конкретные решения и детальную реализацию, пока не известны все нюансы, а требования к коду ещё не известны, либо могут поменяться. Это инвестиция, которая окупается со временем.
С этим, опять же, можно поспорить. Эта инвестиция может и не окупиться со временем с большой вероятностью, все зависит от проекта. Надо понимать что делаешь и для чего, а не реализовывать шаблоны типа «каждая новая исключительная ситуация должна приводить к созданию нового типа (класса) исключения», мало ли понадобиться в будущем… Для большинства конечных проектов вполне достаточно стандартных исключений.
То есть вы перехватываете исключение общего вида (\PDOException) и вводите свое исключение общего вида DataBaseException. Какой в этом смысл? Чем DataBaseException лучше \PDOException? Даже Query из него не вытащить же.
Смысл в том, что на верхнем уровне нам не интересно, какой драйвер и какая библиотека используется для работы с БД (это может быть PDO или, например, mysqli). Нам важно только, что произошла исключительная ситуация при работе с БД. А чтобы вытащить query, стоит пробрасывать предыдущее исключение в новое.
Эта инвестиция может и не окупиться со временем с большой вероятностью, все зависит от проекта
Обычно либо проект умирает на ранней стадии, либо развивается до очень крупного. Или, третий вариант, проект настолько плохо написан, что его никто не хочет дорабатывать, и он так и остается маленьким и уродливым легаси.
Смысл в том, что на верхнем уровне нам не интересно, какой драйвер и какая библиотека используется для работы с БД
Смысл такой архитектуры я прекрасно понимаю, просто пример в статье на мой взгляд не удачный, не очевиден профит подхода.
Описываемый способ является де-факто стандартом в сообществе: он используется во многих серьёзных библиотеках и фреймворках. В том числе Zend, Symfony.
Кстати, а вы не задумывались, что описанный подход как раз таки уместен в переиспользуемых библиотеках/фреймворках и несколько избыточен для большинства (не говорю про все) конечных проектов?
Обычно либо проект умирает на ранней стадии, либо развивается до очень крупного.
Вы серьезно? А как же нишевые проекты, коих большинство и которые живут себе припеваючи, покрыты автотестами и вполне себе поддерживаются и развиваются без сферических абстракций в вакууме? Вы думаете если вы напишете идеальный код и напичкаете его точками расширений, то проект из интернет-магазинчика вырастет до уровня Яндекса или Гугла ?)
Ну и в конце концов, проект написанный плохо может быть легко переписан с нуля, если уж выстрелил и даже на другом языке. Примеров масса…
Кстати, а вы не задумывались, что описанный подход как раз таки уместен в переиспользуемых библиотеках/фреймворках и несколько избыточен для большинства (не говорю про все) конечных проектов?
Не вижу смысла принципиально отличать код библиотечный и нет. Считаю качества он должен быть одинакового.
Возможность переиспользования, это, имхо не самоцель при написании кода или его собственная характеристика, а скорее следствие того что он качественный, т.е. удачно спроектирован, на должном уровне абстракции.
Не вижу смысла принципиально отличать код библиотечный и нет. Считаю качества он должен быть одинакового.
И библиотечный код и код конечного проекта конечно же должен быть одинаково качественны, с этим никто не спорит.
Вопрос в выборе того самого «должного уровня абстракции», о котором вы пишите.
Вы же понимаете, что создатели библиотечного кода решают несколько другие задачи, чем создатели конечного проекта и уровень абcтракции не соизмерим?
Кстати, а вы не задумывались, что описанный подход как раз таки уместен в переиспользуемых библиотеках/фреймворках и несколько избыточен для большинства (не говорю про все) конечных проектов?
Он уместен всегда, поскольку практически не требует усилий и работы мозга. При этом профита дает много.
А как же нишевые проекты, коих большинство и которые живут себе припеваючи, покрыты автотестами и вполне себе поддерживаются и развиваются без сферических абстракций в вакууме?
Можно пример?
Вы думаете если вы напишете идеальный код и напичкаете его точками расширений, то проект из интернет-магазинчика вырастет до уровня Яндекса или Гугла ?)
Я не совсем верно выразился. Под крупными проектами я подразумевал проекты с большой кодовой базой, а не большой аудиторией.
Интернет-магазины, обычно, либо на SaaS, либо CMS, и поддержка и расширение лежат, в большинстве своем, на разработчиках ядра.
Он уместен всегда, поскольку практически не требует усилий и работы мозга.
Конечно, следование любому паттерну или лучшей практике особо не требует усилий и работы мозга, в этом есть некоторая проблема, я считаю. Работы мозга «писателя» кода действительно особо не требуется, а вот «читатель» потом голову ломать будет, зачем здесь выделен тип исключения если он нигде не используется, что автор имел ввиду, можно ли это выпилить?
Можно пример?
Не понял какой пример вы хотите. Из личного опыта? Пожалуйста — проект, в котором я сейчас работаю (maxposter.ru). Нишевой проект, который «заточен» под автосалоны, под капотом довольно сложная бизнес-логика, аналитика, агрегация биллингов разных площадок, всяческие сложные мониторинги и логирование, которые чем-то похожи, но меняются раз в пол года без согласования с нами, и для которых не возможно выделить удачную абстракцию, которая будет сколько-нибудь жизнеспособной и помогла бы быстро решать проблемы. Именно здесь мы в команде пришли к выводу, что DDD не всегда применим, часто надо быть проще и жить будет легче. Проект успешно развивается командой, покрыт тестами, деплоится каждый день «по кнопке», имеет несколько микросервисов написанных на nodejs / golang которые тоже деплоятся «по кнопке». Основное наше конкурентное преимущество — качество и работоспособность сервиса и быстрое изменение кода под сложившуюся ситуацию. Мы с этим успешно справляется и дело тут далеко не в лучших практиках, иерархии типизированных исключений и удачных абстракциях.
При этом профита дает много.
А можно вот тоже пример из вашего опыта, когда это выделение типа исключения на каждый чих дает профит и почему это сложнее было сделать методом рефакторинга существующего кода с общим исключением? Я как раз и пытаюсь добиться ответа на вопрос «в чем профит то?»
Нишевой проект, который «заточен» под автосалоны
Проект развивается, кодовая база увеличивается. Я про это и говорил, что проект либо умирает, либо растет. Вы писали, что такие инвестиции могут не окупиться. но они всегда окупаются, когда проект дорастает до определенного уровня.
А можно вот тоже пример из вашего опыта, когда это выделение типа исключения на каждый чих дает профит и почему это сложнее было сделать методом рефакторинга существующего кода с общим исключением?
Пример: исключения логируются. Я знаю, что скрипт падает из-за проблем с внешним сервисом, но не знаю, из-за чего конкретно. Все исключения в скрипте базового типа. Я мог бы легко найти в логе все ошибки, связанные с внешним сервисом, если бы у них был отдельный тип, но увы. Приходится эмпирически искать по сообщению исключения.
Ну и в конце концов, проект написанный плохо может быть легко переписан с нуля
Если вы довели свой проект до состояния "дешевле переписать чем поддерживать", это не слишком хорошо говорит о качестве решений. Так как "дешевле переписать" это нифига не дешево на самом деле.
Что значит "довели"? Просто изначально были выбраны более простые решения и подходы, а потом выяснилось что их не хватает да и вообще, могли упереться в то, что и язык был выбран не удачно.
К примеру, можно взять за основу laravel, и быстро накидать довольно не плохой прототип проекта, используя магию, статические фасады, автоматическую инъекцию сервисов, все что ускорит получение результата, но не является "best practice". А можно долго и нудно конфигурировать Симфони, Доктрину и получить тот же результат, но с лучшими свойствами "качества" но за большее время. Так вот иногда время, которое экономится в ущерб качеству важно, ибо пока вы пишите православный слоистый код, вводите иерархию исключений, конкуренты берут и делают в 2 раза быстрее на коленке, и вы весь свой идеальный код несете на свалку. А конкуренты переписывают все на праволавную Симфони и начинают использовать лучшие практики именно в этот момент
Просто изначально были выбраны более простые решения и подходы, а потом выяснилось что их не хватает да и вообще
это и называется "довести". Обычно симптомы того что что-то не так проявляются намного раньше точки невозврата.
могли упереться в то, что и язык был выбран не удачно.
Сомнительно. Вам либо подходит PHP либо нужно писать на Rust/Go. Еще есть нюансы когда нужная часть есть в готовом виде, но это как правило легко пристраивается рядом с проектом. Переписывать весь проект при этом не нужно.
А можно долго и нудно конфигурировать Симфони, Доктрину и получить тот же результат
Вообще-то та же Doctrine например как раз таки для выстрой разработки. Можно взять накидать пачку объектов, не особо заморачиваться с оптимизациями выборок, и когда уже будет хоть чуть чуть стабилизировано то что вы делаете с базой — тогда уже браться за оптимизации:
- сначала оптимизируем выборки, индексы, джойны вместо lazy load
- multistep hydration что бы ускорить дела
- для тех у кого доктрина становится узким местом — кастомные гидраторы
- а потом пилим свой дата мэппер под себя (до этого этапа дорастает очень маленький процент проектов).
И уж тем более добрых 95% проектов на симфони и доктрин не сильно далеко уходят по качеству от Laravel. Что до автоинджекта сервисов — это как раз таки best practice. Быстро, удобно, не очень явно конечно но в целом норм. А статические фасады не нужны — есть же автоинджект сервисов.
В целом мне как человеку который пишет на симфони уже достаточно давно не очень понятно почему проекты на симфони писать дольше.
Так вот иногда время, которое экономится в ущерб качеству важно, ибо пока вы пишите православный слоистый код,
я не пишу "православный слоистый код", я просто выбираю ту степень изоляции и декомпозиции которая нужна. И да, это все меняеся с течением жизни проекта.
конкуренты берут и делают в 2 раза быстрее на коленке, и вы весь свой идеальный код несете на свалку.
я вам расскажу историю. Один из моих последних проектов шел с очень жесткими таймлайнами. Проект пишется на симфони и доктрине. Делать "на коленке прототип" который потом выкидывать не вариант, поскольку "сегодня прототип, завтра продакшен". Проект — небольшая ecom система с блокчейнами и прочей хайповой фигней. MVP был реализован за 4 недели. С тех пор прошел почти год, а проект все еще активно развивается на той же кодовой базе что была в самом начале. Да, там есть проблемы, которые по историческим причинам остались, но в целом это все чистят.
Потому я плохо понимаю "почему на Laravel можно сделать быстрее". У меня есть возможность сравнить по цифрам наши проекты на symfony и laravel — разница в скорости разработки в пределах погрешности.
Чем DataBaseException лучше \PDOException?
Слоем приложения. Если вы работаете с репозиторием, то не можете утверждать, что работа ведется при помощи PDO, но точно можете сказать, что работаете с хранилищем данных.
Да, к инфраструктурному. Но суть в том что драйверы могут быть использованы разные. Вместо примера с базами данных можно рассмотреть какой-либо другой, например какая-либо обертка которая прячет с какой очередью задач мы работаем. Или какой драйвер для обработки картинок мы юзаем (gd, imagemagick, что-то еще через third-party api). Нам возможно нужно отловить и обработать определенные исключения вроде "картинка слишком большая" и нам не хочется ловить исключения драйверов.
Нам возможно нужно отловить и обработать определенные исключения вроде «картинка слишком большая» и нам не хочется ловить исключения драйверов.
Я понимаю и осознаю пользу типизированных исключений, я против бездумного следования шаблону «а давайте на каждый чих сделаем новый тип исключений». Я за планомерный рефакторинг: изначально кидаем исключение общего типа, к примеру из SPL, если нужно как-то отдельно обрабатывать, вводим новый тип или маркерный интерфейс для множества ситуаций. Не понимаю, в чем проблема сделать это именно тогда когда понадобилось?
Исключения, связанные с компонентом, на мой взгляд, должны находиться в нем же. Не понимаю, почему Вы так против этого?
Разве я говорил что я против этого, я как раз за, если это действительно зачем-то нужно и этот «компонент» выделили из приложения для переиспользования.
Я высказываю мнение против слепого следования практике «Для каждой ситуации — свой тип» исключения.
Эти правила лишь обобщения, ведущие примерно к одному результату — улучшению качества кода.
Если проводить аналогию, Вы ведь не будете рассказывать восьмилетнему ребенку, как происходит пиролиз на примере ожога? Почти наверняка Вы объясните, что огонь опасен и, если до него дотронуться, возникнет боль. И это будет ценный совет, хоть он и не раскрывает полной картины.
Не понимаю, в чем проблема сделать это именно тогда когда понадобилось?
В целом проблем с этим нет. Все зависит от того что вы пишите и какие требования к тому что вы пишите. Если вы пишите библиотеку — то требования к таким вещам будут куда жеще потому что "когда понадобиться" — будет уже поздно либо придется ломать обратную совместимость.
Просто в проектах все уже будет зависить от размеров команды и т.д. Если вы делаете что-то критически важное в контексте проекта, там стоит загнаться. Но это обычно не очень большая часть всего кода проекта.
С другой стороны речь идет про DatabaseException, что как бы говорит нам о том что мы имеем дело с какой-то очень важной инфраструктурной шляпой которая будет использоваться в разных контекстах нашего приложения. Такие вот мелочи могут сильно усложнить клиентский код, это то чего мы хотим избежать.
Могу повторить суть из резюме поста: да это инвестиция, не самая краткосрочная. Если проект настолько компактный и краткосрочный, жизненный цикл его не подразумевает изменений в контроле над исключениями, вы планируется написать чистовик за одну-две итерации и больше не трогать — она может быть не оправдана.
Как и любая абстракция.
Я понял ваше мнение, не буду переубеждать. Просто высказываю альтернативный подход, который тоже работает. Мой опыт привел меня от слоистой архитектуры с преждевременным вводом абстракций к подходу: "напиши просто, насколько это возможно, покрой тестами, чтобы можно было расширить и порефакторить". А после того как я пописал на golang довольно не простые сервисы минималистично и просто, я по другому посмотрел на современные практики в разработке и считаю что некоторые из них монструозны и не всегда уместны.
Просто высказываю альтернативный подход, который тоже работает.
Вопрос не в том "работает" или "не работает". Вопрос в списке плюсов и минусов каждого подхода. Что мы приобретаем с вашим альтернативным решением и чего лишаемся.
я по другому посмотрел на современные практики
Вот только у Go есть своя специфика которая позволяет чуть-чуть по другому вещи писать. И с этим все хорошо. Попробуйте еще на Rust пописать — тоже интересный опыт будет.
Иерархия исключений в современном PHP-приложении