Приходишь такой в дружелюбную команду и начинается. А чо вы

php-cs-fixer не используете? 100 замечаний в ревью и все про синтаксис.
А нафига вы формы в апи используете? А нафига контроллеры состоят из одной строчки $handler->handle($request)?
Через несколько таких нафига о дружелюбии можно забыть )

никто не пишет в объявление о поиске кандидатов: "В королевство жаб и гадюк требуется свежее мясо (с)"

мне кажется, это можно на собесе выяснить отчасти

Лучше бы ничего не писали, а то нальют воды как в диплом)

Можно, но идеальный код всё равно не найдёшь. Да и смысла нет искать, тут вопрос не в коде, а в том что люди привыкли делать фигню, а отучить сложно. Особенно если лида толкового нет и в команде демократия, где голосуют за то как привыкли)

проблема с идеальным кодом в том что даже если ты его найдешь - подожди недельку и посмотри - ты ошибся и можно было лучше. don't make it greate, let them upgrade

Вообще в целом ещё вопрос что хуже, плохой код или не эффективные процессы

а какой он, этот идиальный код?

не, ну тут должно быть всё в разумных пределах

ты считаешь свой код идиальным?

код проще фиксить, особенно когда процессы эффективные

Ага, а если все привыкли перед релизом ждать недельных регрессов, такие фиксить пару лет)

а для тебя?

хотя бы поэтому

совершенству нет предела ))

годно) как показывает практика к этим выводам команда или определенные люди должны еще дойти

А действительно, нафига тебе контроллер из одной строчки? Он прросто лишний, сразу роут на хендлер направляй и ок.

Кто-то где-то когда-то услышал, что логики в контроллерах быть не должно. Поэтому всё что с приставкой *Controller теперь return $this->handler->handle($request) Контроллер есть, а логики нет. Миссия выполнена

Нахера он тогда нужен вообще

Контроллер это ж хттп адаптер в приложение

Точки входа проще искать с наличием контроллеров

karser karser
скорей всего речь идет об отделении бизнес логики ...

Интересно каким образом тут отделение от фреймворка идёт если хендлер принимает на вход объект Symfony\HttpFoundation\Request, а внутри себя вызывает $this->symfonyFormFactory->createForm()->handle($request)

karser karser
скорей всего речь идет об отделении бизнес логики ...

Зачем фреймворк менять?

Культ карго

Кто-то где-то когда-то сказал что framework agnostic code это круто

Фреймворк это то, что вызывает вас. а то, что вызываете вы - уже библиотеки. Т.е реквест это часть фреймворка. А симфони формы - это зависимость хендлера.

Ну я так стараюсь писать, но отнюдь не для смены фреймворка)))

Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers

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

как там про чужой монастырь?)

действительно)

Бывает такое, что фреймворк бросают, например angularjs. если у вас логика отделена от контроллеров, то перейти на другой будет легче. Также, логику, вынесенную в хендлеры, которые не зависят от реквеста, можно запускать и в CLI command, и в queue worker. Еще в тестах это удобнее. Логику, отделенную от фреймворка можно протестировать сотней тест кейсов, которые выполнятся за 200мс. Если логика находится в контроллере, то 1 тест кейс может выполняться несколько секунд, каждый раз поднимая ядро фреймворка. Тестировать логику, а не фреймворк. Хотя логику + фреймворк тестировать тоже надо, но это функциональные тесты, они проверяют только критический путь.

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

Ели в приложение есть следующие кейсы: один и тот же бизнес сценарий может быть запущен в результате - http запроса от АПИ - в результате http запроса в результате отправки формы(формат данных отличается от того что в АПИ) - есть несколько разных версий АПИ, которые отличаются по формату, но дергают одну и ту же бизнес логику - в результате обработки сообщения из очереди - в результате soap запроса - и т.д. то выделять бизнес логику в сервис (usecase, интерактор) - так или иначе придется. Фактически в приложение появляются слои - слой обработки http /soap / grpc и т.д. - слой в котором инкапсулированы бизнес сценарии - слой в котором инкапсулировано знание о сущностях ну или нарезка на слои может следовать какой либо другой логике. От слоев есть практическая польза когда они имеют явно выраженные границы: - т.е. верхний слой знает о слое нижнем (но не знает о следующих слоях), - а нижележащий слой не знает ничего о верхних слоях (по аналогии - сетевой карте должно быть без разницы, отправляет она udp или tcp пакеты, и уж тем более без разницы кто шлет эти данные - браузер, или телеграм) такая изоляция требует появления специальных контейнеров данных которые нужны для передачи информации между слоями- т.е. появляется Data Transfer Object - DTO. Если dto не вводить , а фигачить через все слои тупо один объект (например http request), то фактически это про протекание слоев. Т.е. все эти слои они решают вполне конкретную задачу - сделать код устойчивым к изменениям: - пришел клиент дал много денег что бы склепали апи на каком то некрофильском бинарном протоколе -пожалйста -> слой бизнес логики не трогаем, делается отдельный контроллер в нем логика по тому как смапить данные из протокола на dto для сервиса, и как из dto ответа сервиса - создать ответ в формате протокола - решили поменять реализацию бизнес сценария - ну например раньше в рамках бизнес сценария состояние сущностей хранилось в бд, а потом пришли микросервисы - и вот реализации бизнес сценария поменялось - в нем теперь не с сущностями работа идет, а дергуются другие апи. - тогда можно не переписывать все контроллеры/консольные команды/обработчики сообщений , а поменять реализацию интерфейса класса в котором инкапсулирвоана логика бизнес сценария Другое дело что решаемые задачи характерны далеко не для всех приложений. Контроллер в одну строчку - имхо, это следствие не понимания какая именно задача решалась при вынесение бизнес логики в отельный сервис (отсюда и кривая реализация в виде пробрасывания http request внутрь сервиса)

да, так и есть. Хорошо, если четко понятно, когда проект это однодневный прототип, а когда большое приложение

пример с ангуляром не очень удачный. чтобы без проблем с того же ангуляра на реакт прыгнуть это прям дофига работы. то что можно отделить это слой апи, так он в идеале должен вообще генерироваться. ну и нам том же реакте ты код в отрыве от фреймворка не сможешь писать ну вот никак. 90% будет завязано на то как работают хуки и тд на счет логики которая используется в cli, консумерах и других вариантах типа grpc, или даже банально в других модулях - однозначно да, лучше отделять. а если это простой модуль состоящий из крудов, то какой смысл усложнять? пусть в контроллерах и остается тесты это отдельная тема. там совсем "it depends"