не то что у тебя нет dto-шек а то что ты делаешь $event->getEntity()

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

в случае ивентов ты как бы закрыл себе дорогу прокидывать этот ивент куда-нибудь в какую-нибудь шину сообщений

ну и еще нюанс - все бы ничего если бы не глобальный UoW доктрины

а отсутствия DTO плохо потому что я имею доступ с одного слоя апликейшена в третий минуя второй?

Angular/React/Vue.js - вроде эта аббревиатура у всех на слуху + на хабре с завидной частотой появляются статьи об их сравнительном анализе или миграции чела с одного фрейма на другой.

про ember все как-то забыли(

а отсутствия DTO плохо потому что я имею доступ с одного слоя апликейшена в третий минуя второй?

нет, потому что ты сущность прокинул

и кто бы ее не менял все будет сохраняться, только теперь отследить это будет сложнее

ясно

ну и еще - шутки ради можешь попробовать сериализовать сущность) из-за прокси классов и ленивой загрузки доктрины это не так просто как может показаться

и вот тебе уже надо обрабатывать эту ситуацию

или подключать какой symfony/jms serializer

я както только пришол на раьботу и нашол публичний метод в интерфейсе setId() - на что мне тимлид сказал что все люди адекватные тут и нихто его вызивать не будет гне не нужно. и мне стало грусно. А изался он в одном месте которое можна переписать было.

я както только пришол на раьботу и нашол публичний метод в интерфейсе setId() - на что мне тимлид сказал что все люди адекватные тут и нихто его вызивать не будет гне не нужно. и мне стало грусно. А изался он в одном месте которое можна переписать было.

если метод никто не будет юзать - ну так удали

"все люди адекватные тут" пока это не так

не надо оставлять методы которые никто не будет юзать и не надо "на будущее" делать методы

что до setId - если хочешь айдишку извне передавать (это нормальная практика) - пределавай в конструктор

хотя зачем я это говорю, всеравно всем похеру

есть стэйт есть процедуры - живем

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

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

если так проще и быстрее - то может быть и не надо эту проблему чинить

что бы внедрять какие-то решения надо проблему сначала найти)

а плохой код это не проблема?)

дай определение плохому коду

в моем понимании не соотвествия SOLID и Grasp и PSR

ну то есть солид ради солид, грасп ради грасп, psr ради psr

это опять же решения или рекомендации как избежать проблем. а проблемы то в чем?)

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

верно. соблюдение каждого из принцыпов принесут тебе менше боли в будущем при потдержке этого кода

верно. соблюдение каждого из принцыпов принесут тебе менше боли в будущем при потдержке этого кода

то есть ты не знаешь зачем эти принципы нужны)

напоминает интервью)

просто хочу объяснить что SOLID это не решение проблемы, это способ проблему найти.

знаю конешно

соблюсти SOLID невозможно, разве что ты знаешь будущее и можешь учесть все изменения требований, но тогда тебе солид не нужны

попробуй соблюсти open/close)) если что - 100% соблюдение этого принципа будет выражаться в том, что любая новая фича будет добавляться за счет добавления нового кода, никакой код не меняется (могут меняться только конфиги)

сможешь так?)

всегда в вакансиях смущают фразы в требованиях типа "Знание ООП", сразу столько вопросов возникает =\

имеет ли это практический смысл?) всего всеравно не учтешь

да

всегда в вакансиях смущают фразы в требованиях типа "Знание ООП", сразу столько вопросов возникает =\

это стандартные писульки на отъебись.

как и в резюме стандартные "ответственный, целеустремленный" и прочий булшит. Если тебя смешат тексты вакансий - почитал бы резюмехи. вот там тотальный трэш и пиздец. В одной из последних которые я читал у человека который говорит что у него 10+ лет опыта на последнем месте работы 2 из трех пунктов обязанностей (помимо код писать и фиксить баги) было 2 пункта - участие в дэйли митингах (скрам же), и логать время в джиру"

попробуй соблюсти open/close)) если что - 100% соблюдение этого принципа будет выражаться в том, что любая новая фича будет добавляться за счет добавления нового кода, никакой код не меняется (могут меняться только конфиги)

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

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

а весь проект сможешь так сделать?

вообще что бы код никогда не менялся

)))

(багфикс и оптимизации не считаются)

я потяол о чем ты. но это разве не крайности.

просто я подчеркиваю - целесообразность всего этого произрастает из понимания целей применения этих принципов. А цель у них простая - сделать разработку дешевле и предсказуемее

это стандартные писульки на отъебись.

и вообще слово "знание" слишком нагруженная абстракция чтобы понять, чё там хотели-то =\ Ещё в каждой второй "знание PHP не ниже middle". И вот хз чё тут думать я ниже middle или где я? =\

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

и вообще слово "знание" слишком нагруженная абстракция чтобы понять, чё там хотели-то =\ Ещё в каждой второй "знание PHP не ниже middle". И вот хз чё тут думать я ниже middle или где я? =\

yield умеешь?

yield умеешь?

нет =)

плохой пример - это уже на синьеров тянет)))))

(что очень и очень грустно мягко говоря)

я потяол о чем ты. но это разве не крайности.

без этой крайности сложно объяснить что соблюдать solid на 100% невозможно. Это вообще те принципы которые хорошо работают только в ретроспективе. когда ты написал чуть-чуть кода и посмотрел соблюдаются ли все еще эти пригнципы или нет

и вообще слово "знание" слишком нагруженная абстракция чтобы понять, чё там хотели-то =\ Ещё в каждой второй "знание PHP не ниже middle". И вот хз чё тут думать я ниже middle или где я? =\

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

не спроста solid в книге дяди Боба идет после рефакторинга а не до

(что очень и очень грустно мягко говоря)

Не будь пессимистом

Не будь пессимистом

а ты в елды умеешь?

как и в резюме стандартные "ответственный, целеустремленный" и прочий булшит. Если тебя смешат тексты вакансий - почитал бы резюмехи. вот там тотальный трэш и пиздец. В одной из последних которые я читал у человека который говорит что у него 10+ лет опыта на последнем месте работы 2 из трех пунктов обязанностей (помимо код писать и фиксить баги) было 2 пункта - участие в дэйли митингах (скрам же), и логать время в джиру"

да я вот хз, если не писать ответственный и целеустремлённый, то наверное и работу не найдёшь. Я вот не писал - по итогу сосу лапу. Видимо придётся писать =( Резюме-то делается для HR-а, а шо HR может?

без этой крайности сложно объяснить что соблюдать solid на 100% невозможно. Это вообще те принципы которые хорошо работают только в ретроспективе. когда ты написал чуть-чуть кода и посмотрел соблюдаются ли все еще эти пригнципы или нет

понял спс

а ты в елды умеешь?

Вай нот? Не слишком хитрая штука

да я вот хз, если не писать ответственный и целеустремлённый, то наверное и работу не найдёшь. Я вот не писал - по итогу сосу лапу. Видимо придётся писать =( Резюме-то делается для HR-а, а шо HR может?

открою тебе страшную тайну - никто не читает такие резюме

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

Вай нот? Не слишком хитрая штука

вай нот - это значит умеешь?) ты считаешь себя синьером или что-то рядом хотя бы?

вай нот - это значит умеешь?) ты считаешь себя синьером или что-то рядом хотя бы?

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

грустно - потому что yield не очень сложная штука, но среднестатистический php-ник не знает как это дело юзать

хорошо если для удобной работы с итераторами будет применять...

вай нот - это значит умеешь?) ты считаешь себя синьером или что-то рядом хотя бы?

Я считаю что такие базовые вещи и джунв вроде меня должны знать

Я считаю что такие базовые вещи и джунв вроде меня должны знать

поддерживаю, но реальность удручает

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

ну ты-то и не HR. А моё резюме скорее всего HR-фильтр как раз не проходит. Хотя вообще-то оно у меня плохо написаное, наверное =\

ну ты-то и не HR. А моё резюме скорее всего HR-фильтр как раз не проходит. Хотя вообще-то оно у меня плохо написаное, наверное =\

они часто даже опыт работы не особо читают)

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

смотри аккуратнее с елдами, а то у вас там гейропа рядом вот это вот всё :D

а на твое скромное "ответственный, быстро учусь" им похеру вообще

проще просто это не писать а больше разукрасить именно свой опыт работы

они часто даже опыт работы не особо читают)

блин, мне стабильно раз в месяц приходит вакансия на сеньор фронтендера

блин, мне стабильно раз в месяц приходит вакансия на сеньор фронтендера

потому что у тебя где-то бутстрап какой затесался или js

мне на C++ пару раз присылали)

ангулар и вью

надо пойти выбросить html/css из скиллов

проще просто это не писать а больше разукрасить именно свой опыт работы

а чё там разукрасить, агрегатор - фигачил данные туда-сюда, говнокодили по чёрному всей командой :D

ангулар и вью

Ну вот) уже сеньор фронтенд)

ангулар и вью

в целом тебе до синьер фронтендера это только сделать хипстерскую прическу и разобраться с webpack)

(я шучу если что, фронтэнд нынче это так же сложно как и бэк)

(я шучу если что, фронтэнд нынче это так же сложно как и бэк)

оно просто по-другому сложно

так же в том смысле что 2/3 пересекается ;)

(я шучу если что, фронтэнд нынче это так же сложно как и бэк)

потдерживаю.. стек намного увеличисла запоследние годы

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

как и в резюме стандартные "ответственный, целеустремленный" и прочий булшит. Если тебя смешат тексты вакансий - почитал бы резюмехи. вот там тотальный трэш и пиздец. В одной из последних которые я читал у человека который говорит что у него 10+ лет опыта на последнем месте работы 2 из трех пунктов обязанностей (помимо код писать и фиксить баги) было 2 пункта - участие в дэйли митингах (скрам же), и логать время в джиру"

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

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

не вижу ничего странного

все завичет что тебе нравится

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

Не всем менеджерские должности нравятся

Ну так программист тоже менеджер

занимается менеджментом кода

руководящяя должность ето 20% кода и 80% менеджерских обязаностей

не всегда

я лично знаю людей которые с тимлидов просилися назад в синеры

занимается менеджментом кода

с кодом проще - он подчиняется законам интерпретатора, о которых ты явно что-то знаешь

да заебет после 10 лет то код писать