Чем шире scope конкретной транзакции, тем дольше она выполняется. Особенно если внутри нее есть еще запросы в другие сервисы / базы. Во время того, как транзакция открыта, соединение с БД не может быть возвращено назад в пул и использовано другими запросами. Рано или поздно упретесь в лимит открытых конекшенов. Если в рамках транзакции вы делаете лок (select for update) и держите ее открытой дольше чем необходимо для обновления стэйта сущности, которую лочите, то другие ресурсы тоже не смогут получить к ней доступ на запись и будут скапливаться в очередь, что может привести к приличной деградации. Ну и бонусом, всякие неприятные последствия для бизнес логики, если ваша транзакция откатится из-за какого-нибудь минорного исключения выше по стэку, который на суть бизнес операции не влияет никак.
В целом, для небольших проектов не под нагрузкой все эти моменты едва-ли будут ощутимы. Однако это очень частая проблема при росте. И большой вопрос, стоит ли такую бомбу замедленного действия закладывать со старта.
Я думаю, что изначально комментатор имел ввиду, что при работе с такой важной вещью как транзакционность, лучше полагаться на более очевидный и понятный всем код, нежели чем на AOP магию. Не зная особенностей работы последней, можно очень здорово стрельнуть себе в ногу голову, особенно в каком-нибудь финтехе.
Я конечно диванный вирусолог. Но думаю, что мутации вируса, которые приводят к повышенной стойкости к иммунитету, менее вероятны при взрывной модели заражения (R0 > 1.60). Да, конечно, он будет мутировать очень активно, но так как подавляющее большинство его носителей не будет иметь иммунитета, то и версии, которые этого иммунитета боятся будут "выживать". Опять же имхо, сейчас проблема в том, что в популяции достаточно много людей с иммунитетом, но и так же достаточно много без него, которые активно вирус распространяют. Сам же COVID, попадая в организм привитого или переболевшего, мутирует таким образом, что выживают те копии, которые умеют иммунитет обходить.
Как раз на эту тему где-то читал про другую модель, согласно которой появления мутаций, способных обходить иммунитет, как раз наиболее вероятно при вакцинации от 60 до 70% популяции. Что мы примерно сейчас и наблюдаем.
Дело в том, что при вертикальном масштабировании мы можем буквально вставлять железки в кластер и реплицировать это всё, либо разворачивать новые копии монолитного приложения. Это очень долго и неэффективно. При горизонтальном мы можем легко, добавив больше ресурсов в кластер, получить большую пропускную способность и вычислительную мощность.
Что-то мне кажется здесь какая-то путаница с типами масштабирования. Вертикальное это как раз про наращивания физических ресурсов для фиксированного количества копий приложения. Горизонтальное масштабирование это про увеличение кол-ва копий, возможно и монолитного приложения, таким образом, чтобы они не влияли друг на друга.
Я думаю, Вы заведомо ставите работников в очень неудобное положение и это совершенно не способствует открытости в беседе с Вами в дальнейшем. Оценить уровень квалификации без полноценного собеседования сложная, но вполне выполнимая задача. Да, на это будет потрачено несколько больше времени, но взамен вы, во-первых, сохраните нормальные отношение с коллективом, а во-вторых, получите возможность оценить сотрудника не по первому впечатлению, а в реальном рабочем процессе.
Если у вас нет слоя абстракции между менеджером этой сущности и БД, то кроме функционального тут ничего особо не придумаешь. По хорошему, должен быть слой (DBL, UnitOfWork,.etc), который берет на себя общение с БД. Он может быть изолированно покрыт функциональными тестами, либо же юнитами на предмет корректного генерирования SQL в разных условиях. Вы же для своего менеджера, который сохраняет сущность, проверяете только то, что он корректно с корректными аргументами дергает методы этого слоя для работы с БД.
А по теме функциональных тестов: я ничего плохого в них не вижу, когда речь идет действительно о стыке разных систем. Единственная проблема с ними — скорость выполнения. По этому там где возможно и понятно как писать юниты — пишем юниты, там где напрашивается функциональный — соответсвенно.
Скажите, а какой редактор/IDE может выдавать адекватные подсказки для autocomplete на метод, у которого не указан возвращаемый тип и отсутствует phpdoc?
Вся интересность в том, что за последние 150 лет на "нашей" территории существует как минимум третье государство. "Нашей" специально в кавычки взял, потому что территория тоже меняется постоянно и вы можете сейчас жить в своей стране, а через месяц в другой (1991 год). И честно, не понимаю, как можно любить все три государства, что были. А вот любить какие то национальные особенности вполне возможно, что и есть в моем, конечно, понимании патриотизм.
Читал всю ветку с попкорном на коленках. Одного понять не могу — почему Вы патриотизм противопоставляете поиску более комфортного места для себя? Я люблю русскую культуру, язык, быт, русских людей и нашу самобытность и уклады (как раз это обычно называют патриотизмом, нет?), но при этом я не вижу приличного будущего для моих детей на данный момент в государстве с названием Россия и сознательно выбрал другое место для жизни, по крайней мере на данный момент. Можно меня назвать патриотом? Ну наверное да, я ценю и люблю свою родину. Можно назвать предателем и прочими нехорошими словами? Тоже да, я ведь уехал, а не стал терпеть.
Иногда спрашивают, а что если вторая половинка против? Ну найдите правильную вторую половинку, которая не против. Мне кажется, их устраивает, что ты так много вкладываешь в работу, и они гордятся тем, что ты делаешь крутые вещи. Мне близок этот подход. Но если ты выбрал себе в 18 лет неправильную половинку, и теперь страдаешь — то извини. Это как если ты нанял неправильного сотрудника и не хочешь его увольнять. К тому же вторая половинка хорошо живет, твоя работа обеспечивает семью.
Серьезно? То есть жена, которая хочет видеть своего супруга раньше 11 часов вечера и не только жить на его зарплату, но и проводить с ним совместно какое-то ощутимое время, — неправильная?
Давайте по-рассуждаем, что может быть внутри такого метода и как это можно было бы реализовать по другому
Очевидно что, для MyClassInterface и для array логика обработки разная либо нам нужно привести аргументы к одному типу, тогда ваш метод будет выглядеть примерно так
public function decode(array|MyClassInterface $item): string
{
if (is_array($item)) {
// do some logic for array or cast type to MyClassInterface
return ...;
}
// do some logic for MyClassInterface
return ...;
}
Я бы не назвал это хорошим кодом. В данном методе как минимум два блока кода с разной логикой, которая явно напрашивается быть разбитой на два метода. Кроме того, что если потребуется реализовать decode для какого-нибудь другого типа? Нам придется модифицировать метод и добавлять еще одно условие и т.д.
В классических языках со строгой типизацией это бы решилось простой перегрузкой и код превратился бы в что-то типо того
public function decode(array $item): string
{
// do some logic for array or cast type and call decode with MyClassInterface argument
return ...;
}
public function decode(MyClassInterface $item): string
{
// do some logic for MyClassInterface
return ...;
}
И таким образом компилятор/интерпретатор бы сам решал, какой метод использовать в зависимости от аргумента. К сожалению, в php такой код работать не будет, но мы можем реализовать его немного по другому:
public function decodeArray(array $item): string
{
// do some logic for array or cast type and call decode with MyClassInterface argument
return ...;
}
public function decodeMyClass(MyClassInterface $item): string
{
// do some logic for MyClassInterface
return ...;
}
Таким образом, если нам необходимо будет реализовать decode для чего-то еще нам нужно всего лишь добавить еще один метод (а не модифицировать старый Open/Closed из SOLID) и мы гарантированно не сломаем то, что уже работает.
Либо, если array можно представить в виде MyClassInterface, то реализовать MyArrayClass, который бы создавался из массива и имплементировал MyClassInterface, и у нас бы остался decode с одним типом аргумента. Ну и конечно наоборот, когда MyClassInterface можно представить в виде массива…
Вот по этому я считаю, что Union Types нужен в большинстве случаев для того, чтобы засахарить тот код, который стоило бы отрефакторить, и фактически легализует написание кода из примеров выше.
Представьте, что это метод, который принимает или объект или массив для инициализации объекта и возвращает строку или false
Так проблема то собственно не в json, а в том, что вы должны
Четко документировать в каких случаях может быть false (то есть от phpdoc мы не избавимся)
Предоставить механизм получения детальной информации, что пошло не так
И это все решается как раз таки механизмом исключений.
Пример, когда возвращается либо результат, либо false, в принципе очень не удачен. Для того же json_decode в 7.3 ввели опцию JSON_THROW_ON_ERROR, чтобы в случае ошибки не false возвращать, а исключение кидать. И в целом этот подход считается одним из самых не удачных во встроенных функциях php
Так может декомпозировать и эти ситуации?:) Моя идея в том, что если язык движется в сторону строгости, то и разработчики должны писать более строгий код и стараться избегать ситуаций, где допустимы несколько типов одного аргумента или возвращаемых значений. Там где "капец как надо" или для легаси останется возможность тип не указывать вообще. А принятие этого предложения фактически легализует возможность юзать несколько типов везде где надо и не надо, что точно не приведет к росту качества php-кода.
В этом случае нужно в phpDoc описать в каких случаях у вас будет false. Кроме этого, чтобы получить информацию о том, почему же все таки false, пользователю метода нужно будет догадаться вызвать json_last_error, а если вы вдруг решите метод поменять и парсить json как-то по другому? Здесь как раз таки намного разумнее кинуть исключение, если string не может быть возвращен, с описанием собственно почему, а пользователю уже решать, что с этим делать.
Соглашусь с Вами, что некачественный код можно написать тысяча и одним способом и сейчас. Но вот предложение тоже не поддерживаю. Когда язык обязывает указывать строго один тип (в крайнем случае nullable), вам так или иначе придется преобразование типов выносить либо наверх, либо в другой метод, тем самым упрощая этот конкретный метод, избавляя его от необходимости обрабатывать несколько типов. В других строго-типизированных языках такие проблемы решаются перегрузкой, когда для разного набора аргументов (в том числе других типов) определяется другой одноименный метод, реализующий требуемую логику именно для такого набора. Вычитать такой код будет куда проще, чем когда все в одной куче. И уж если PHP идет в сторону более строгой типизации, то было бы логичнее придерживаться более строгого подхода и в данном случае тоже, и вполне достаточно того, что можно типы не указывать вообще. ИМХО, естественно.
Есть OpenLens https://github.com/MuhammedKalkan/OpenLens. Правда некоторые extensions нужно доставить руками.
Чем шире scope конкретной транзакции, тем дольше она выполняется. Особенно если внутри нее есть еще запросы в другие сервисы / базы. Во время того, как транзакция открыта, соединение с БД не может быть возвращено назад в пул и использовано другими запросами. Рано или поздно упретесь в лимит открытых конекшенов. Если в рамках транзакции вы делаете лок (select for update) и держите ее открытой дольше чем необходимо для обновления стэйта сущности, которую лочите, то другие ресурсы тоже не смогут получить к ней доступ на запись и будут скапливаться в очередь, что может привести к приличной деградации. Ну и бонусом, всякие неприятные последствия для бизнес логики, если ваша транзакция откатится из-за какого-нибудь минорного исключения выше по стэку, который на суть бизнес операции не влияет никак.
В целом, для небольших проектов не под нагрузкой все эти моменты едва-ли будут ощутимы. Однако это очень частая проблема при росте. И большой вопрос, стоит ли такую бомбу замедленного действия закладывать со старта.
Я думаю, что изначально комментатор имел ввиду, что при работе с такой важной вещью как транзакционность, лучше полагаться на более очевидный и понятный всем код, нежели чем на AOP магию. Не зная особенностей работы последней, можно очень здорово стрельнуть себе в
ногуголову, особенно в каком-нибудь финтехе.А как же прекращение возможности продления лицензий ISPManager 5 версии и форсирование перехода на 6-ую, которая существенно дороже?
Я конечно диванный вирусолог. Но думаю, что мутации вируса, которые приводят к повышенной стойкости к иммунитету, менее вероятны при взрывной модели заражения (R0 > 1.60). Да, конечно, он будет мутировать очень активно, но так как подавляющее большинство его носителей не будет иметь иммунитета, то и версии, которые этого иммунитета боятся будут "выживать". Опять же имхо, сейчас проблема в том, что в популяции достаточно много людей с иммунитетом, но и так же достаточно много без него, которые активно вирус распространяют. Сам же COVID, попадая в организм привитого или переболевшего, мутирует таким образом, что выживают те копии, которые умеют иммунитет обходить.
Как раз на эту тему где-то читал про другую модель, согласно которой появления мутаций, способных обходить иммунитет, как раз наиболее вероятно при вакцинации от 60 до 70% популяции. Что мы примерно сейчас и наблюдаем.
P.S. сторонник вакцинации
Что-то мне кажется здесь какая-то путаница с типами масштабирования. Вертикальное это как раз про наращивания физических ресурсов для фиксированного количества копий приложения. Горизонтальное масштабирование это про увеличение кол-ва копий, возможно и монолитного приложения, таким образом, чтобы они не влияли друг на друга.
Это какой-то ваш внутренний тул? Не смог сходу найти его в open source.
Я думаю, Вы заведомо ставите работников в очень неудобное положение и это совершенно не способствует открытости в беседе с Вами в дальнейшем. Оценить уровень квалификации без полноценного собеседования сложная, но вполне выполнимая задача. Да, на это будет потрачено несколько больше времени, но взамен вы, во-первых, сохраните нормальные отношение с коллективом, а во-вторых, получите возможность оценить сотрудника не по первому впечатлению, а в реальном рабочем процессе.
Если у вас нет слоя абстракции между менеджером этой сущности и БД, то кроме функционального тут ничего особо не придумаешь. По хорошему, должен быть слой (DBL, UnitOfWork,.etc), который берет на себя общение с БД. Он может быть изолированно покрыт функциональными тестами, либо же юнитами на предмет корректного генерирования SQL в разных условиях. Вы же для своего менеджера, который сохраняет сущность, проверяете только то, что он корректно с корректными аргументами дергает методы этого слоя для работы с БД.
А по теме функциональных тестов: я ничего плохого в них не вижу, когда речь идет действительно о стыке разных систем. Единственная проблема с ними — скорость выполнения. По этому там где возможно и понятно как писать юниты — пишем юниты, там где напрашивается функциональный — соответсвенно.
Скажите, а какой редактор/IDE может выдавать адекватные подсказки для autocomplete на метод, у которого не указан возвращаемый тип и отсутствует phpdoc?
Вся интересность в том, что за последние 150 лет на "нашей" территории существует как минимум третье государство. "Нашей" специально в кавычки взял, потому что территория тоже меняется постоянно и вы можете сейчас жить в своей стране, а через месяц в другой (1991 год). И честно, не понимаю, как можно любить все три государства, что были. А вот любить какие то национальные особенности вполне возможно, что и есть в моем, конечно, понимании патриотизм.
Читал всю ветку с попкорном на коленках. Одного понять не могу — почему Вы патриотизм противопоставляете поиску более комфортного места для себя? Я люблю русскую культуру, язык, быт, русских людей и нашу самобытность и уклады (как раз это обычно называют патриотизмом, нет?), но при этом я не вижу приличного будущего для моих детей на данный момент в государстве с названием Россия и сознательно выбрал другое место для жизни, по крайней мере на данный момент. Можно меня назвать патриотом? Ну наверное да, я ценю и люблю свою родину. Можно назвать предателем и прочими нехорошими словами? Тоже да, я ведь уехал, а не стал терпеть.
Серьезно? То есть жена, которая хочет видеть своего супруга раньше 11 часов вечера и не только жить на его зарплату, но и проводить с ним совместно какое-то ощутимое время, — неправильная?
Так пусть возвращаемым типом будет
ResponseInterface, аSuccessResponseиErrorResponseбудут его имплементировать. И фич никаких не нужно.Давайте по-рассуждаем, что может быть внутри такого метода и как это можно было бы реализовать по другому
Очевидно что, для MyClassInterface и для array логика обработки разная либо нам нужно привести аргументы к одному типу, тогда ваш метод будет выглядеть примерно так
Я бы не назвал это хорошим кодом. В данном методе как минимум два блока кода с разной логикой, которая явно напрашивается быть разбитой на два метода. Кроме того, что если потребуется реализовать
decodeдля какого-нибудь другого типа? Нам придется модифицировать метод и добавлять еще одно условие и т.д.В классических языках со строгой типизацией это бы решилось простой перегрузкой и код превратился бы в что-то типо того
И таким образом компилятор/интерпретатор бы сам решал, какой метод использовать в зависимости от аргумента. К сожалению, в php такой код работать не будет, но мы можем реализовать его немного по другому:
Таким образом, если нам необходимо будет реализовать decode для чего-то еще нам нужно всего лишь добавить еще один метод (а не модифицировать старый Open/Closed из SOLID) и мы гарантированно не сломаем то, что уже работает.
Либо, если
arrayможно представить в видеMyClassInterface, то реализоватьMyArrayClass, который бы создавался из массива и имплементировалMyClassInterface, и у нас бы осталсяdecodeс одним типом аргумента. Ну и конечно наоборот, когдаMyClassInterfaceможно представить в виде массива…Вот по этому я считаю, что Union Types нужен в большинстве случаев для того, чтобы засахарить тот код, который стоило бы отрефакторить, и фактически легализует написание кода из примеров выше.
Так проблема то собственно не в json, а в том, что вы должны
false(то есть от phpdoc мы не избавимся)И это все решается как раз таки механизмом исключений.
Пример, когда возвращается либо результат, либо false, в принципе очень не удачен. Для того же
json_decodeв 7.3 ввели опциюJSON_THROW_ON_ERROR, чтобы в случае ошибки неfalseвозвращать, а исключение кидать. И в целом этот подход считается одним из самых не удачных во встроенных функциях phpТак может декомпозировать и эти ситуации?:) Моя идея в том, что если язык движется в сторону строгости, то и разработчики должны писать более строгий код и стараться избегать ситуаций, где допустимы несколько типов одного аргумента или возвращаемых значений. Там где "капец как надо" или для легаси останется возможность тип не указывать вообще. А принятие этого предложения фактически легализует возможность юзать несколько типов везде где надо и не надо, что точно не приведет к росту качества php-кода.
В этом случае нужно в phpDoc описать в каких случаях у вас будет false. Кроме этого, чтобы получить информацию о том, почему же все таки false, пользователю метода нужно будет догадаться вызвать
json_last_error, а если вы вдруг решите метод поменять и парсить json как-то по другому? Здесь как раз таки намного разумнее кинуть исключение, если string не может быть возвращен, с описанием собственно почему, а пользователю уже решать, что с этим делать.Соглашусь с Вами, что некачественный код можно написать тысяча и одним способом и сейчас. Но вот предложение тоже не поддерживаю. Когда язык обязывает указывать строго один тип (в крайнем случае nullable), вам так или иначе придется преобразование типов выносить либо наверх, либо в другой метод, тем самым упрощая этот конкретный метод, избавляя его от необходимости обрабатывать несколько типов. В других строго-типизированных языках такие проблемы решаются перегрузкой, когда для разного набора аргументов (в том числе других типов) определяется другой одноименный метод, реализующий требуемую логику именно для такого набора. Вычитать такой код будет куда проще, чем когда все в одной куче. И уж если PHP идет в сторону более строгой типизации, то было бы логичнее придерживаться более строгого подхода и в данном случае тоже, и вполне достаточно того, что можно типы не указывать вообще. ИМХО, естественно.