Евгений Иванов

Есть много плагинов, но не для IDE, а для браузера. И это правильно, потому что во время разработки код может быть разбросан по разным файлам, из-за чего нет смысла его валидировать. Может быть даже такое, что в одном файле тег открывается, а в другом закрывается.

коде-реформат коде, выровняет блоки по парам, можно сворачивать изнутри наружу проверенные блоки, так как сложно хтмл разметку однозначно определить иногда, где предполагалось закрыть тег. Простые случаи подсвечивает, со сложными может показать неверный корневой тег. В целом - вполне нормально видит ошибки разметки, что не устраивает - не понятно.

В консоли вижу ошибку 500

Логи ошибок пхп смотрите, ну или включите вывод ошибок и смотрите что пишет сервер в нетворке. Хотя может он и пишет, но вы не смотрели респонс...

PS: возможно возврат функции ожидаемого типа Response не совпадает с return 1;? ну и как костыль можно сделать echo 1; exit; вместо ретурна.

Олег уже по сути изложил эту мысль, но я ее перефразирую. Суть DRY, как мне кажется, не в том чтобы бороться с дублирующимся кодом, а в том, чтобы бороться с дублирующимися концепциями. Объясню: какой-то кусок кода в двух местах проекта может быть схожим - появляется искушение вынести его в одну функцию или класс, однако концепции (дальнейшие планы) на эти куски кода могут быть совершенно разными, и в будущем, по мере детализации первоначальной бизнес идеи, эти два куска кода станут совершенно не похожими друг на друга.

В данном случае: если у фирмы, магазина и категории продуктов изначально разный набор параметров, и в будущем есть опасения, что этот набор будет еще более различным, то не стоит эти параметры объединять в какой-то общий класс. Это можно было бы сделать, если, например, стояло бизнес-требования (концепция) реализовать унифицированный набор параметров для всех сущностей. В таком случае да - не стоило бы одну концепцию расчленять на разные части кодовой базы.

Если подытожить: не стоит бояться дублирующегося кода - стоит бояться дублирующихся концепций. В конечном счете не очень существенно сделать код короче убирая дублирующиеся куски - с эти справятся компиляторы или минимизаторы, которые кажется иногда обобщают дублирующийся код для оптимизации и в дальнейшем сводят весь огромный проект к одной длинной строке или бинарнику. С точки зрения архитектора по настоящему важно сделать код понятным и удобным для доработок. Это одна из основных целей программиста, имхо.

Убедится в корректности конфигурирования роутов можно командой:
php bin/console debug:router

Дока

Вы пишите, что настраивали роутинг через yaml файлы? А этот роут вы прописали как аннотацию / атрибут. Может вам надо в конфиге фреймворка указать, что роутинг должен браться из annotations?

Логично создать абстрактный класс с повторяющимися полями и унаследоваться от него. А в каждом дочернем классе добавить что нужно.

Это как раз нарушение solid, а точнее lsp.

А однозначного ответа, тут быть не может, потому как слишком общий вопрос. Читайте DDD

Архитектура бывает двух типов:

• На которой идёт быстрая разработка
  
• Удобная для поддержки проекта
  

Нужно отделять бизнес логику от деталей. Для начала это может быть обращение к интерфейсу, и вам не важно что в дальнейшем у методов этого интерфейса поменяется реализация.

Нужно использовать сервисы и репозитории, в качестве абстракций к моделям. На практике это означает, что у контекста (например аккаунт) есть свой сервис - класс, где сосредоточена бизнес логика, и репозиторий - класс посредник для обращения к базовому репозиторию с методами запроса к базе данных.

Что касательно вашей ситуации, то вам следует опираться на принцип "Единственной ответственности", суть которого в том, что к каждого компонента может быть только одна причина для изменения.

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

Лучше идти от большего к меньшему, то есть сначала использовать дублирование кода в разных контекстах, а потом провести рефакторинг и вынести все что нужно в отдельные классы.

Если вы будете использовать контексты, и выстраивать взаимодействие между ними, через классы посредники, вы поймёте, что дублирования кода нет, так как сам контекст уже содержит в себе логику, к которой обращаются несколько других контекстов.

Меня заклюют, но интернет магазин и классы как вы их понимаете вообще не рядом.
Вы пытаетесь построить классы и связи между ними, чтобы избежать дублирования информации. Но смотрите. Сферический товар:
Просто лежит на витрине.
Участвует паралельно в акции.
Добавлен в корзину.
Стал частью заказа.
Часть фискального чека.
Архив.
Учетная система магазина.
Лежит на центральном складе.
Откупается у поставщика

и прочее и прочее. И в каждом случае у него своя цена
А первое желание у вас как я понимаю было сделать одно поле цена в классе товар ?

TL;DR без четкого понимания что и как будет работать что-то планировать или структурировать бесполезно. Нет универсального решения, надо делать под текущие задачи, с некоторой возможностью "маневра" в плане функционала.

Похоже что вы вообще собираетесь писать что-то свое с нуля, что вообще как бы смысла не имеет, надо брать готовый фреймворк, где отпадет сразу большой пласт проблем с архитектурой.

У фирмы есть один главный офис. Есть магазины, принадлежащие этой фирме.

Фирма будет одна? Тогда нет смысла выделять его в отдельную сущность.

В каждом магазине есть категории продуктов - мясо, молочные продукты, крупы.

Во всех одинаковые? Или для каждого будет различный набор?

В каждой категории есть продукты, например говядина.

Тот же вопрос. Плюс еще у вас будет куча нюансов, типа - наличие/в резерве/на складе/в доставке/цены/скидки... И свойства разных товаров, которые у одних типов есть, а у других нет или сильно отличаются...

В чем практический смысл тестирования?

Уменьшить количество багов.

где оно нужно, когда даже крупнейшие компании допускают явные баги на главном экране игры

Где исправлять баг дороже, чем его отловить.

Например, вы программируете микроконтроллер. Случился критический баг - покупайте новый.
Или вы делаете базу данных. Баг = утечка данных пользователей = всем наплевать...
Или вы разрабатываете нейросеть, а потом в международном журнале вас уличают в обмане и тормозят научную карьеру.

Какие тесты нужно было сделать, чтобы предотвратить этот баг?

Такие дефекты, обычно, отлавливаются при помощи ручного тестирования.

Но искать визуальные баги в тексте в играх - это очень дорогое занятие, тк нужно сценарии прогонять на десятках разных конфигураций (разрешение экрана/масштабирование интерфейса/язык)
=> поиск такого бага до выпуска новой версии будет занимать много времени => это будет очень дорого.
Что вообще не соотносится с его критичностью.

Ещё можно попробовать скриншотное тестирование - может быть будет дешевле в плане человеческих ресурсов, но всё равно очень дорого в плане железных ресурсов и не гарантирует надёжность (скриншотные тесты известны своей нестабильностью), да и не очень популярны они в играх (ибо инструментов нет), и из-за обилия анимаций они будут очень сложны в поддержке.

А так да - тут скорее архитектурная проблема и дизайнер не учёл, как должно работать переполнение строки в этом случае.

Так в чем практический смысл тестирования? Где оно нужно, когда даже крупнейшие компании допускают явные баги на главном экране игры (а там про команды с миллионными бюджетами).

Ты не учитываешь множество других, более критичных дефектов, которые не попали в релиз как раз благодаря тестированию.

Игры тут не самый лучший пример, тк их тестирование несколько отличается от тестирования обычного ПО своей количественной (очень много чего может сломаться) и качественной (много что сложно проверить) сложностью, а также количеством различных граничных значений.
+ в играх есть рандом, который может в неожиданных местах всё сломать.

У багов есть разный impact. Или степень влияния на качество продукта. Вот какое влияние сдвинутых иконок?
Я думаю их увидели только жители стран которые используют перевод с английского и этот перевод оказался на несколько символов длинее оригинала из-за чего произошел развал дизайна. Можно сказать что аудитория некоторых стран ощутила легкое неудобство.

Тоесть impact - так себе.

А что будет если программист 3Д графики допустил ошибку, которая приводит к крашу игры? Тут влияние посильнее. Я-бы сказал что это провал релиза. Как такое пропустили тестировщики (автоматизаторы или ручники) неважно) - ХЗ. Но тут важно срочно бежать в студию и выкладывать на steam экстренное обновление игры. И счет идет не на недели а на считанные дни. Кое-кому из отдела разработки и тестирования придется провести несколько безсонных ночей перед багфиксом.

Вот в этом и есть практический смыл тестирования. Тестировать важные части логики.

Смотрю ролики по программированию. Заинтересовали ролики Немчинского (хотя некоторые вещи он объясняет крайне непонятно для новичка).

Немчинский - популист и популяризатор своей собственной it-школы. Обычно в каждом видосе - реклама.

У него есть контр-образовательная позиция. Он например считает что после 1 курса универа надо сразу идти работать и наплевать на диплом вообще.

Во многих роликах Немчинский говорит, что надо использовать классы через интерфейсы.
....
У меня есть класс 1, в нем есть методы. Класс 1 используется в классе 2. Зачем интерфейс?

Не смотрел видео. Но в этом вобщем-то есть смысл для создания слабой зацепленности и InversionOfConrol.
Новичку такое объяснить нельзя. Нужны месяцы и годы чтобы понять. Желательно не на синтетических
уроках а на реальных боевых проектах где МНОГО кода. Именно обилие кода и требование проводить
сложны рефакторинги, замены движков одни на другие и цикл постоянной доработки - мотивируют к
внедрению базовых интерфейсов вместо классов.

То что ты не понял с 1 раза - это нормально. Я тоже когда изучал ооп и полиморфизм на примере Borland Pascal
тоже подумал что это туфта и я это использовать никогда не буду ибо незачем.

Можно привести пример на php и показать выгоду такого подхода?

Тут я не уверен. Вроде в PHP OOP есть с 5 версии. А есть ли там механики полиморфизма - ХЗ.
Пускай знающие прокоментируют. Но если есть - то хороший пример переключения
функционала например с Db MySQL на Postgresql без переписывания бизнес-логики.
В идеале у вас переключение должно произойти в 1 строчке кода. Если удалось - значит
метод работает.