Статья интересная (наверное). Но почему прочтения заголовка ожидалось прочитать про SOLID, а не про SOLIDWORKS? Какой-то дешевенький кликбейт получается.
Из каждого угла слышно "выходите из зоны комфорта". Ска, дайте пожалуйста хотя бы зайти в эту зону, прежде чем выходить из нее.
Это так, но ведь стресс возникает везде и всегда. Согласитесь, поднимать голос на коллег, швырять бумаги или как-то еще бунтовать, - не самое разумное решение. Даже на самой мирной и спокойной работе такие моменты случаются, когда хочется сделать именно как описано выше. Владеть собой и достойно коммуницировать свое недовольство - тоже навык. Но стресс нужно снимать так или иначе. Например, в спортивном зале, или просвещая себя любимым занятиям и хобби, например.
А зачем мучатся? Если ты не можешь ужиться в компании, или компания дерьмо, или у тебя постоянный стресс, то либо меняй себя, либо меняй окружение/компанию. Смысл страдать? Если аргумент "денюшки", ну тогда страдай дальше, раз нет возможности и желания изменить что-то.
Я понимаю ваш скепсис. Более того, я как и наверняка 99% людей миллион раз ходила на собеседования с HR и выходила со встреч разочарованная, непонятая и иногда облитая грязью. Но серьезно. Именно поэтому мы тут, на Хабре, пытаемся сказать вам, что не всегда все происходит именно так. И так быть не должно. Есть компании, где вам отзвонят, спросят про ваши впечатления и сомнения, посоветуют, как можно в будущем скорректировать самопрезентацию в будущем или на предстоящем собеседовании с непосредственным работодателем.
Эээ я прям удивлен что я 1% процент счастливчиков, у которых все ок на собеседованиях. Или может дело в том, что когда ты так себе специалист тебе и приходиться проходить миллион собеседования и слышать миллион отказов? И тут даже речь не про то, что я невероятный специалист (наверное), а про то что нужно адекватно себя оценивать.
Веселят такие ребята, которые: "Как это вы не готовы платить мне 100К в месяц за свободный график и удаленку? Я вообще-то студент (или еще круче "я онлайн-курсы прошел"), который только что выпустился и у меня нулевой опыт работы."
Да-да, именно вынесения всей каши из init.php в отдельный файл и инклудить его обратно в init - это тру ?
Вы наверное сами не понимаете о чем говорите:
# init.php
<?php
\Bitrix\Main\Loader::includeModule('module.name');
?>
# module.name/include.php
<?php
// подписка на события
// инциализация DI
?>
И в чем тут проблема? А если модулей несколько, то наверное вместо очередного инклуда модуля (и группирования кода по контексту a.k.a модулю), лучше конечно выносить это все в init.php, естественно (сарказм).
Ах да, наверное вы еще посоветуете не выносить обработчики событий в отдельный классы/функции, а прям в анонимной функции фигачить в init.php?
Хотелось бы конечно посмотреть на ваши проекты с вашей "хорошей практикой". Говнище редкостное наверное :)
Эвент диспетчер есть стандартный битриксовый, который вполне все потребности автора покрывает. Зачем нужно было тащить стороний?
Twig - фреймворк
Шаблонизатор. Битрикс по-умолчанию без него, и подавляющее большинство сайтов на Битрикс без шаблонизатора. И если этот чудо-сайт после уйдет кому-то другому на поддержку, то им весело и задорно придется разбираться в этом великолепии. Про документацию я думаю можно даже не мечтать в таких вот наследиях предыдущих разработчиков.
Но мы все знаем, к чему приводит привычка юзать init.php
Все мы это кто, говнокодеры? В init.php максимум, что нужно дак это вызывать 'Loader::includeModule', а все остальное уже размещать непосредственно в include.php модуля и/или доп файлах если include.php разрастается.
Также удручал тот факт, что шаблонизатор можно использовать только в компонентах, хотя это уже лучше, чем ничего.
А где еще вы их собираетесь использовать? Inline на публичных или админских страницах? Использование компонентов в целом хороший подход, когда у вас конкретный виджет (кусок кода) обособлен.
но т.к. опыта создания собственных событий у меня не было, то в силу собственной лени я решил не заморачиваться
Т.е. в целом вам лень написать 1 класс с двумя методами: 'addEventListener' которая добавит в массив колбэк и 'triggerEvent' которая прочитает из массива и выполнит колбэк?
Да, действительно, лень невообразимая, а заморочек и подавно не видно.
Хотя бы стоило добавить в конце листинг куска кода с использования Twig в компоненте
Название "анемичная модель" считаю некорректым, так как Entity - это скорее DTO, которое вполне описывает БД, и не соответствует значению слова "анемичность"
Выдержка из статьи: "Это просто данные, минимум логики". Собственно это и есть анемичная модель: сущности где куча гетеров и сеттеров без какой-либо логики.
Entity можно сделать отдельным низкоуровневым слоем (инфраструктурным). И тогда они будут отделены от слоев выше, где логика приложения, предметная область.
Дак они у вас и сейчас находятся там (правда инфраструктурный слой выше слоя приложения, слой данных вы наверное имели ввиду?), и очень жестко (1 в 1) завязаны на структуре БД и очень вряд ли отражают объекты с точки зрения предметной области.
С одной сущностью может быть связано много разной логики. Ответственность уже разделяется внутри модуля, если нужно. А модуль берет данные из ентити через инверсию зависимости, например. То есть, Entity реализует интерфейс, который определен в модуле. А в интерфейсе могут быть просто геттеры сеттеры, данные, в общем.
Мы все еще говорим про НЕ анемичную модель, ага.
Собственно, это и объясняется в том абзаце, только более подробно.
В том абзаце очень неожиданный вывод, что нужно сделать UserStore, что вообще не вяжется с предметной областью: есть склад, есть товар, который хранится на складе, есть пользователь который ответственный за склад и товары в нем.
А в вашем варианте получается: есть пользователь, есть склад пользователя, есть товар который хранится на складе пользователя. Получается что склад без пользователя/заведующего не может быть?
Если уж дальше разруливать эту ситуацию, то по хорошему должны быть контексты (в рамках статьи наверное модули):
товар, склад и заведующий склада (который никакого отношения не имеет к пользователю, имеет только ид, который в рамках приложения совпадает с ид пользователя)
пользователь который вообще никак не сопрекасается со складом и товарам
Подробнее посмотрите про ограниченный контекст.
Конечно, делать того, о чем вы говорите не стоит. Но можно туда написать хороший код, и тогда практически одним копипастом вы сможете перенести его в любой класс.
Не нужно строить иллюзий, "хороший код, там где не нужно" === "говнокод" :)
Названия слоев довольно условны, их может быть больше или меньше, а может и не быть, если модуль небольшой, например
Вот прям обидно стало за ребят, которые все эти слои "кровью и потом" и своим опытом выводили. А оказывается они условны.
Каждый слой отвечает за конкретную зону ответственности, конкретные действия и сущности, и определенным образом может, или не может, взаимодействовать с другими слоями.
Делаем по-простому, усложняя по мере необходимости. Либо сразу делаем сложно, если знаем, что это может понадобиться.
В целом плохая идея делать "сложно", чем проще система тем лучше. А делать что-то на будущее бред, поэтому что это будущее может не наступить (и скорее всего не наступит). Поэтому нужно делать ровно то что надо, но оставлять возможно для расширения.
Про SOLID не забываем, но тоже применяем по необходимости.
Что простите? Дак не забывать или делать? И что такое "по необходимости", когда это оправдано делать god-object "семирукицсемисис" который делает все что угодно? Или наследовать объекты с разным поведением только лишь для переиспользования кода?
Entity отображают таблицы, ... Это просто данные, минимум логики.
А в чем плюс анемичных моделей в сравнении с моделями домена?
Так мы не привязываем структуру наших классов с логикой к структуре таблиц БД
Именно так и вы привязываете структуру ваших классов к структуре БД, Entity же отражают структуру таблиц из БД из предложения выше.
Например, если логика относится к Product, кладем ее в ProductService. Если сервис будет расти, мы сможем выделить из него, например, ProductStoresService
Лучше бы сразу выделять сервис, возвращаясь к вопросу о SOLID и единственной ответственности, который будет работать только с одной сущностью.
А если будет происходить взаимодействие складов не только с товарами, а с чем-то еще, например, с пользователями, заведующими складами, то может появиться другой StoresService, в другой папке — UserStores
Эээ а зачем? Stores же в любом случае работает с Product и он является его частью. Или у вас склады могут существовать без товаров? Если у вас склад это независимая ни от чего сущность (т.е. может существовать сам собой без User и Product), то выделяйте его в отдельный модуль, иначе (даже по мере роста функционала), где изначально находился сервис там его и оставляется и расширяйте.
Если код небольшой, можно писать его прямо в контроллере. Но можно и в отдельном сервисе или нескольких сервисах
Опять таки, зачем изначально говнокодить? В контроллерах не должно быть бизнес-логики раз уж вы ее в сервисы отправили, иначе вы нарушаете свою же слоистость.
P.S. статье на хватает хотя бы листингов папок, чтобы наглядно видеть о чем речь.
P.S.S. есть подозрение, что вы либо не докрутили, либо целенаправленно не используете старые добрые слои: domain - data - service - infrastructure , и у вас получается кашка из-за этого. Ну и в целом у вас получается этакий DDD (только нет Domain Model (а зря) и разделения на Entity/Aggregate (хотя в целом можно и без него пережить) миксом с CQS (где UseCases это Command).
С наступлением пандемии, когда все ушли на удаленку, для описания задач и фичей мы использовали notepad, textedit, sublime - все, что попадало под руку, чтоб зафиксировать текст.
А таск менеджер использовать, нет? Он вроде и создан для того что копить и структурировать задачи.
А диаграммы нужны проекту для понимая проекта в целом, а не решения конкретно задачи. Т.е. диаграммы нужны всегда, а не только когда стоит какая-то задача.
А статья хорошая и инструмент полезный и нужный :)
Пол статьи убили на то, чтобы описать разницу моков и стабов (сомнительное конечно разделение при том что и то и другое моки) и только к концу главы пришли к примеру CQS, который все расставил бы по полочкам с самого начала. Воды, воды, еще больше воды!!!
Как по мне моки нужны только для ситуаций когда в момет выполнения тестов у нас нет нужной службы, либо она не нужна для теста (бд, брокер сообщение, почтовый сервер и т.д.). В остальном если строить тесты по принципу черного ящика (когда нам без разницы что внутри), то хрупкость тестов ооочень сложно достичь.
Примеры из статьи же:
Creating_a_report - зачем нам проверять сколько раз вызывался "GetNumberOfUsers" ? Нам важем результат, нам без разницы сколько раз вызывалась функция.
Purchase_fails_when_not_enough_inventory - зачем нам проверять что не удалялось именно 5 штук шампуней? Нам нужно убедиться, что вообще ничего не удалялось, т.е. метод RemoveInventory не вызывался (опять таки это зависит от заложенной логики)
Т.е. если подойти с другого бока к тестам нужно относиться (и стараться достичь этого) как к функциональному программированию: при отправке одних и тех же аругментов, мы должны получать ровно тот же результат, и как раз это должны обеспечивать моки (сохранение одинакого состояния от теста к тесту).
Если касаться же подхода проектирования, то на CQS очень хорошо ложатся тесты: каждой команде/запросу все необходимые сервисы/сущности передаются в конструкторе (если конечно передаются и в целом на проекте используется DI) и тестируется ровно один метод (execute/query). Таким образом при написании тестов мы сами контролируем какие зависимости отправлять, мы точно знаем, что должно происходить при выполнении команды/запроса, и нам абсолютно не важно* что происходит внутри, нам важно выполнение команды и один из ее возможных вариантов завершения.
А дополнительные размышления по поводу "хм, это мок или стаб?" только тормозят сам процесс написания теста. Конечно, такое разделение нужно для того, чтобы быстро понять надо ли проверять или нет, НО зачем вводить дополнительные условия (да к тому же еще и 5 вариантов моков), если это все должна диктовать бизнес-логика приложения? Если нам важно с точки зрения выполнения конкретной задачи выполняется тот или иной метод мока - то нужно это проверить. Если нам не важно и это никак не влияет на результат задачи - то нам и надо это проверять. И не нужно вводить дополнительные термины и строить теорию на ровном месте, где она абсолютно не нужно.
*По поводу "абсолютно не важно"небольшая ремарка: если в рамках бизнес-логики должно отправляться письмо клиенту, то это нам конечно нужно проверить (замокать EmailService), но нам точно неважно вызывался ли, и сколько раз, какой-то вспомогательный сервис, который никак не влияет на результат выполнения команды. Например, мы тестируем создание заказа на недостаточное количество товара, нам абсолютно без разницы запрашивалось ли количество товара на складе и сколько раз, нам важно, что заказ не будет создан по причине недостаточности товара (кинет соответствующее исключение или вернет ошибку).
А зачем вообще в целом нужны не пустые коллекции, и что будет с не пустой коллекций когда в ней не станет элеметов (clear вызову)?
Типобезопасность - это конечно великолепно что на doc-блоках держится "типа безопасность", но в чем проблема (хотя бы опционально) добавить проверку типа при обновлении коллекции (set, update)?
filterNotNull - если уже делать по аналогии с имеющимися функциями, то логично было бы сделать логику array_filter, когда при вызове без callback все пустые (да не только null) элементы удаляются
Ковариантность - а что простите в доктрине не так? Объявите такой же докблок и норм, нет?
Иммутабельность - старый добрый clone видимо уже не катит? А то что на каждом вызове будет новая коллекция память засирать, это норм?
HashMap - очередной неоправданный велосипед - SplObjectStorage
Возможно это и не ко мне, поскольку эта «реплика» не отдельным комментом (деревом), а вклинена в комментарий на комментарий, т.е. вырвана из контекста статьи.
А причем тут контекст статьи? Это же ваш комментарий:
Тем и хорош Codeigniter 4, что, помимо прочего, проект можно делать эффективно на железе и софте минимальной конфигурации.
Или комментарий автора статьи на вопрос по статье, не относится к этой статье? Забавно конечно.
Вообще-то «настройке нужным образом» и посвящена обсуждаемая статья.
Вообще статья про Xdebug, если уж на то пошло. А CodeIgniter только в заголовке его очень легко можно убрать. Ровно также как и PHPUnit из заголовка можно смело выкинуть, т.к. про него тут вообще речи нет. Ну и по поводу их связки: Xdebug прекрасно существует без PHPUnit, ровно как и PHPUnit прекрасно существует без Xdebug.
Тем и хорош Codeigniter 4, что, помимо прочего, проект можно делать эффективно на железе и софте минимальной конфигурации.
Вы упорно приписываете CI заслуги, которых у него нет. Если "потянет" PHP, то соответственно потянет и CI, и Yii, и Symfony. Только окружение нужным образом настройте и ок.
Вы либо действительно считаете что это все заслуги CI, в чем ооочень сильно заблуждаетесь. Либо это какой-то самоубийственный способ прорекламировать фреймворк который не столь популярен и заслуг то у него никаких нет, кроме того что это "РНР-фреймворк".
Это в свою очередь позволяет войти в web-разработку любому профессионалу в любой области Soft-Industry без лишних трат на обновление Hard Ware и Soft Ware.
Ну что ж вы так плохо про РНР, любая домохозяйка может установить PHP на пк, создать тестовый файл index.php в нотепадике и после магической ОДНОЙ строки в консоли запустить его.
А можно уточнить что именно? После диагонального чтения доки, я только увидел класс Factory, который напоминает Laravel где за фасадом прячется (да я в курсе что это фабрика)
Маразм крепчал) Видимо вам будет трудно понять, что работая с Битрикс - работаешь на PHP, а вот работая с PHP - НЕ работаешь на Си.
По вашей логике работая со Spring НЕ работаешь на Java?)
Статья интересная (наверное). Но почему прочтения заголовка ожидалось прочитать про SOLID, а не про SOLIDWORKS? Какой-то дешевенький кликбейт получается.
Bitrix - CMS на языке PHP, поэтому ваша фраза "Переход с bitrix на любой универальный язык программирования" крайне неадекватна :)
Немного иронично что в статье "Regex for lazy developers" нет никакой информации про lazy выражения: https://regex101.com/r/id4r4i/1
Достатошно полезная штука, особенно в HTML.
Из каждого угла слышно "выходите из зоны комфорта". Ска, дайте пожалуйста хотя бы зайти в эту зону, прежде чем выходить из нее.
А зачем мучатся? Если ты не можешь ужиться в компании, или компания дерьмо, или у тебя постоянный стресс, то либо меняй себя, либо меняй окружение/компанию. Смысл страдать? Если аргумент "денюшки", ну тогда страдай дальше, раз нет возможности и желания изменить что-то.
Эээ я прям удивлен что я 1% процент счастливчиков, у которых все ок на собеседованиях. Или может дело в том, что когда ты так себе специалист тебе и приходиться проходить миллион собеседования и слышать миллион отказов? И тут даже речь не про то, что я невероятный специалист (наверное), а про то что нужно адекватно себя оценивать.
Веселят такие ребята, которые: "Как это вы не готовы платить мне 100К в месяц за свободный график и удаленку? Я вообще-то студент (или еще круче "я онлайн-курсы прошел"), который только что выпустился и у меня нулевой опыт работы."
Вы наверное сами не понимаете о чем говорите:
И в чем тут проблема? А если модулей несколько, то наверное вместо очередного инклуда модуля (и группирования кода по контексту a.k.a модулю), лучше конечно выносить это все в init.php, естественно (сарказм).
Ах да, наверное вы еще посоветуете не выносить обработчики событий в отдельный классы/функции, а прям в анонимной функции фигачить в init.php?
Хотелось бы конечно посмотреть на ваши проекты с вашей "хорошей практикой". Говнище редкостное наверное :)
Конечно же импортозамещением. Не на маркетинг ведутся, ага.
И на БУС и на Б24 можно поднимать адекватные проекты, если конечно ручки-не-криворучки, но видимо в этом случае как раз они.
Эвент диспетчер есть стандартный битриксовый, который вполне все потребности автора покрывает. Зачем нужно было тащить стороний?
Шаблонизатор. Битрикс по-умолчанию без него, и подавляющее большинство сайтов на Битрикс без шаблонизатора. И если этот чудо-сайт после уйдет кому-то другому на поддержку, то им весело и задорно придется разбираться в этом великолепии. Про документацию я думаю можно даже не мечтать в таких вот наследиях предыдущих разработчиков.
Все мы это кто, говнокодеры? В init.php максимум, что нужно дак это вызывать 'Loader::includeModule', а все остальное уже размещать непосредственно в include.php модуля и/или доп файлах если include.php разрастается.
А где еще вы их собираетесь использовать? Inline на публичных или админских страницах? Использование компонентов в целом хороший подход, когда у вас конкретный виджет (кусок кода) обособлен.
Т.е. в целом вам лень написать 1 класс с двумя методами: 'addEventListener' которая добавит в массив колбэк и 'triggerEvent' которая прочитает из массива и выполнит колбэк?
Да, действительно, лень невообразимая, а заморочек и подавно не видно.
Хотя бы стоило добавить в конце листинг куска кода с использования Twig в компоненте
Выдержка из статьи: "Это просто данные, минимум логики". Собственно это и есть анемичная модель: сущности где куча гетеров и сеттеров без какой-либо логики.
Дак они у вас и сейчас находятся там (правда инфраструктурный слой выше слоя приложения, слой данных вы наверное имели ввиду?), и очень жестко (1 в 1) завязаны на структуре БД и очень вряд ли отражают объекты с точки зрения предметной области.
Мы все еще говорим про НЕ анемичную модель, ага.
В том абзаце очень неожиданный вывод, что нужно сделать UserStore, что вообще не вяжется с предметной областью: есть склад, есть товар, который хранится на складе, есть пользователь который ответственный за склад и товары в нем.
А в вашем варианте получается: есть пользователь, есть склад пользователя, есть товар который хранится на складе пользователя. Получается что склад без пользователя/заведующего не может быть?
Если уж дальше разруливать эту ситуацию, то по хорошему должны быть контексты (в рамках статьи наверное модули):
товар, склад и заведующий склада (который никакого отношения не имеет к пользователю, имеет только ид, который в рамках приложения совпадает с ид пользователя)
пользователь который вообще никак не сопрекасается со складом и товарам
Подробнее посмотрите про ограниченный контекст.
Не нужно строить иллюзий, "хороший код, там где не нужно" === "говнокод" :)
Вот прям обидно стало за ребят, которые все эти слои "кровью и потом" и своим опытом выводили. А оказывается они условны.
Каждый слой отвечает за конкретную зону ответственности, конкретные действия и сущности, и определенным образом может, или не может, взаимодействовать с другими слоями.
В целом плохая идея делать "сложно", чем проще система тем лучше. А делать что-то на будущее бред, поэтому что это будущее может не наступить (и скорее всего не наступит). Поэтому нужно делать ровно то что надо, но оставлять возможно для расширения.
Что простите? Дак не забывать или делать? И что такое "по необходимости", когда это оправдано делать god-object "семирукицсемисис" который делает все что угодно? Или наследовать объекты с разным поведением только лишь для переиспользования кода?
А в чем плюс анемичных моделей в сравнении с моделями домена?
Именно так и вы привязываете структуру ваших классов к структуре БД, Entity же отражают структуру таблиц из БД из предложения выше.
Лучше бы сразу выделять сервис, возвращаясь к вопросу о SOLID и единственной ответственности, который будет работать только с одной сущностью.
Эээ а зачем? Stores же в любом случае работает с Product и он является его частью. Или у вас склады могут существовать без товаров? Если у вас склад это независимая ни от чего сущность (т.е. может существовать сам собой без User и Product), то выделяйте его в отдельный модуль, иначе (даже по мере роста функционала), где изначально находился сервис там его и оставляется и расширяйте.
Опять таки, зачем изначально говнокодить? В контроллерах не должно быть бизнес-логики раз уж вы ее в сервисы отправили, иначе вы нарушаете свою же слоистость.
P.S. статье на хватает хотя бы листингов папок, чтобы наглядно видеть о чем речь.
P.S.S. есть подозрение, что вы либо не докрутили, либо целенаправленно не используете старые добрые слои: domain - data - service - infrastructure , и у вас получается кашка из-за этого. Ну и в целом у вас получается этакий DDD (только нет Domain Model (а зря) и разделения на Entity/Aggregate (хотя в целом можно и без него пережить) миксом с CQS (где UseCases это Command).
А таск менеджер использовать, нет? Он вроде и создан для того что копить и структурировать задачи.
А диаграммы нужны проекту для понимая проекта в целом, а не решения конкретно задачи. Т.е. диаграммы нужны всегда, а не только когда стоит какая-то задача.
А статья хорошая и инструмент полезный и нужный :)
Пол статьи убили на то, чтобы описать разницу моков и стабов (сомнительное конечно разделение при том что и то и другое моки) и только к концу главы пришли к примеру CQS, который все расставил бы по полочкам с самого начала. Воды, воды, еще больше воды!!!
Как по мне моки нужны только для ситуаций когда в момет выполнения тестов у нас нет нужной службы, либо она не нужна для теста (бд, брокер сообщение, почтовый сервер и т.д.). В остальном если строить тесты по принципу черного ящика (когда нам без разницы что внутри), то хрупкость тестов ооочень сложно достичь.
Примеры из статьи же:
Creating_a_report - зачем нам проверять сколько раз вызывался "GetNumberOfUsers" ? Нам важем результат, нам без разницы сколько раз вызывалась функция.
Purchase_fails_when_not_enough_inventory - зачем нам проверять что не удалялось именно 5 штук шампуней? Нам нужно убедиться, что вообще ничего не удалялось, т.е. метод RemoveInventory не вызывался (опять таки это зависит от заложенной логики)
Т.е. если подойти с другого бока к тестам нужно относиться (и стараться достичь этого) как к функциональному программированию: при отправке одних и тех же аругментов, мы должны получать ровно тот же результат, и как раз это должны обеспечивать моки (сохранение одинакого состояния от теста к тесту).
Если касаться же подхода проектирования, то на CQS очень хорошо ложатся тесты: каждой команде/запросу все необходимые сервисы/сущности передаются в конструкторе (если конечно передаются и в целом на проекте используется DI) и тестируется ровно один метод (execute/query). Таким образом при написании тестов мы сами контролируем какие зависимости отправлять, мы точно знаем, что должно происходить при выполнении команды/запроса, и нам абсолютно не важно* что происходит внутри, нам важно выполнение команды и один из ее возможных вариантов завершения.
А дополнительные размышления по поводу "хм, это мок или стаб?" только тормозят сам процесс написания теста. Конечно, такое разделение нужно для того, чтобы быстро понять надо ли проверять или нет, НО зачем вводить дополнительные условия (да к тому же еще и 5 вариантов моков), если это все должна диктовать бизнес-логика приложения? Если нам важно с точки зрения выполнения конкретной задачи выполняется тот или иной метод мока - то нужно это проверить. Если нам не важно и это никак не влияет на результат задачи - то нам и надо это проверять. И не нужно вводить дополнительные термины и строить теорию на ровном месте, где она абсолютно не нужно.
*По поводу "абсолютно не важно" небольшая ремарка: если в рамках бизнес-логики должно отправляться письмо клиенту, то это нам конечно нужно проверить (замокать EmailService), но нам точно неважно вызывался ли, и сколько раз, какой-то вспомогательный сервис, который никак не влияет на результат выполнения команды. Например, мы тестируем создание заказа на недостаточное количество товара, нам абсолютно без разницы запрашивалось ли количество товара на складе и сколько раз, нам важно, что заказ не будет создан по причине недостаточности товара (кинет соответствующее исключение или вернет ошибку).
А что из "новых механизмов" появилось за последние лет 5, которые касались окружения, а не кода?
А зачем вообще в целом нужны не пустые коллекции, и что будет с не пустой коллекций когда в ней не станет элеметов (clear вызову)?
Типобезопасность - это конечно великолепно что на doc-блоках держится "типа безопасность", но в чем проблема (хотя бы опционально) добавить проверку типа при обновлении коллекции (set, update)?
filterNotNull - если уже делать по аналогии с имеющимися функциями, то логично было бы сделать логику array_filter, когда при вызове без callback все пустые (да не только null) элементы удаляются
Ковариантность - а что простите в доктрине не так? Объявите такой же докблок и норм, нет?
Иммутабельность - старый добрый clone видимо уже не катит? А то что на каждом вызове будет новая коллекция память засирать, это норм?
HashMap - очередной неоправданный велосипед - SplObjectStorage
А причем тут контекст статьи? Это же ваш комментарий:
Или комментарий автора статьи на вопрос по статье, не относится к этой статье? Забавно конечно.
Вообще статья про Xdebug, если уж на то пошло. А CodeIgniter только в заголовке его очень легко можно убрать. Ровно также как и PHPUnit из заголовка можно смело выкинуть, т.к. про него тут вообще речи нет. Ну и по поводу их связки: Xdebug прекрасно существует без PHPUnit, ровно как и PHPUnit прекрасно существует без Xdebug.
Вы упорно приписываете CI заслуги, которых у него нет. Если "потянет" PHP, то соответственно потянет и CI, и Yii, и Symfony. Только окружение нужным образом настройте и ок.
Вы либо действительно считаете что это все заслуги CI, в чем ооочень сильно заблуждаетесь. Либо это какой-то самоубийственный способ прорекламировать фреймворк который не столь популярен и заслуг то у него никаких нет, кроме того что это "РНР-фреймворк".
Ну что ж вы так плохо про РНР, любая домохозяйка может установить PHP на пк, создать тестовый файл index.php в нотепадике и после магической ОДНОЙ строки в консоли запустить его.
Ну так и у вас на ПК не полноценный сервер, а максимум локальная копия проекта, чего вам для работы достаточно будет. К чему XAMPP?
Т.е. все сходство, это использование composer всеми перечисленными фреймворками? Ладушки
Дак любой проект, на любом фреймворке расширяем благодаря composer. Это вообще не заслуга CI.
А можно уточнить что именно? После диагонального чтения доки, я только увидел класс Factory, который напоминает Laravel где за фасадом прячется (да я в курсе что это фабрика)