Читал код и архитектуру. Некоторым рекомендациям начал следовать еще задолго до прочтения. Когда начал применять в работе и требовать это от остальных, услышал: «Времени нет, давайте быстрее. Потом переделаем нормально». Вспомнил что в книге и про такое было написано. Вот незадача, эту технику я так и не осилил. Хрен кому что докажешь, а вопить и вспоминать про наследие начинают тогда, когда пройдена точка невозврата.
Был на разных проектах. Где-то ядро исключали из репозитория, где-то его оставляли. Когда нужно был обновить, то поступали так: 1) Разраб обновлял битру локально 2) Пушил изменения в репу (выпускал релиз) 3) Остальные делали аналогично. Затем подтягивали актуальное ядро из репозитория Со стороны выглядит конечно трешево, но со временем привыкли. Да и разрабов было немного.
На проектах, где ядро исключалось, тоже были свои недостатки. Иногда разрабы тупо продолжали сидеть на старых версиях ядра без обновы.
Такой угар, ваше чтиво)))) Работал я с вами на проекте, честно говоря треш полный у вас твориться. До конца даже дочитывать не стал.
Работал в php отделе. Ребята внедряли подобие гексагональной архитектуры в обычный новостной блок с парой форм. Тесты им нахер не нужны, а бизнес логику мы делегируем инфраструктуре потому что так быстрее)))) А вот на хабре поговорим о высоких материях
Планирую брать просто 14700(без К). Стоит недорого и достаточно производительный для рабочих задач и игр. Не вижу смысла гнать. На байт сторонников АМД забил болт. Все орут про 14700к и 14900к, мол они бракованные.Со стороны похоже на бабкины сплетни у подъезда. 10 человек сказало, остальные подхватили. Деградации в основном подвержены виртуальные владельцы. И товарищи не имеющие понятия о взаимодействии процесса и тока.
"Куча возвратов". Куча - это сколько? Указывайте реальные исследования на эту тему, а не результаты экспериментов неудавшихся мамкиных гонщиков
Вот думаю смеяться или плакать... "Лишний select запрос делаем". Ну да у вас же в секунду 100к регистраций будет проводиться... Ещё в комментариях предлагали constrained. Ну тут 50 на 50 в зависимости от того какое приложение. Если новостной блог, то Окей. Если что-то более сложное, то выносить бизнес логику на инфраструктурный слой ошибка.
Прочел ваш комментарий и вспомнил. Пришел я как то на проект, где люди пытались затащить гексагональную архитектуру. И все это непотребство пытался вытянуть один техлид, который до этого писал на С и занимался геймдевом) Человек яро отрицал необходимость чистой архитектуры и SOLID в этом подходе. Постоянно упарывался в преждевременную оптимизацию.
Подобные заявления звучат в духе "Перестаньте молиться на физику и математику". А статьи пишутся ради статей. Люди же до нас были глупые. Взяли и напридумывал принципы всякие. Работаю 5 лет backend разработчиком. За это время имел дело с кодом, который был написан с использованием принципов и без. Ясен пень что работать с кодом, который пыл написан на базе каких-то принципов, приятнее. Возможно когда-нибудь мы начнем писать опираясь не на SOLID, а на другие принципы. И что то мне подсказывает, принципы те будут основаны на базе того же SOLID.
Смысл ДТО в транспортировке данных между слоями. Не понимаю почему в них так и норовят вкорячить логику fromArray, fromRequest... Это ужасно. Ещё не понимаю прикола с репозиториями, которые читают сохраняют данные одновременно. Так же не понятна идея передачей действий из controller в action, чтобы он потом передал в service и repository. Все это похоже на неудачные попытки затянуть фишки луковой архитектуры в трёхслойный MVC минуя нужные слои.
А можно просто взять готовый образ для docker и развернуть в 2 клика. Если понадобятся различные системы типа RabbitMQ, Elasticsearch, то придется вручную накатывать на ОС.
После таких любителей "оптимизировать" внутреннюю кухню языка порой вешаешься на проекте... Давайте будем честными, на небольших объемах данных в 9 из 10 случаев всем будет насрать на сколько там память увеличилась. А если вы пытаетесь изменить что-то в массиве размером со "слона", то вы явно делаете что-то не так. Я даже не могу представить такую ситуацию)
Читал код и архитектуру. Некоторым рекомендациям начал следовать еще задолго до прочтения. Когда начал применять в работе и требовать это от остальных, услышал: «Времени нет, давайте быстрее. Потом переделаем нормально». Вспомнил что в книге и про такое было написано. Вот незадача, эту технику я так и не осилил. Хрен кому что докажешь, а вопить и вспоминать про наследие начинают тогда, когда пройдена точка невозврата.
Я может что-то упустил. От чего наследуются команды? Можно использовать
useSymfony\Component\Console\Command\Command;?Был на разных проектах. Где-то ядро исключали из репозитория, где-то его оставляли. Когда нужно был обновить, то поступали так:
1) Разраб обновлял битру локально
2) Пушил изменения в репу (выпускал релиз)
3) Остальные делали аналогично. Затем подтягивали актуальное ядро из репозитория
Со стороны выглядит конечно трешево, но со временем привыкли. Да и разрабов было немного.
На проектах, где ядро исключалось, тоже были свои недостатки. Иногда разрабы тупо продолжали сидеть на старых версиях ядра без обновы.
От души поржал... Советы от наивного ребенка. Если корпорациям что то нужно, то они это непременно получат. "Используйте временный чат", во даёт🤣
А нельзя использовать хеш от версий от частей агрегата, включая корень? Аля вычисляемое поле.
Такой угар, ваше чтиво)))) Работал я с вами на проекте, честно говоря треш полный у вас твориться. До конца даже дочитывать не стал.
Работал в php отделе. Ребята внедряли подобие гексагональной архитектуры в обычный новостной блок с парой форм. Тесты им нахер не нужны, а бизнес логику мы делегируем инфраструктуре потому что так быстрее)))) А вот на хабре поговорим о высоких материях
Планирую брать просто 14700(без К). Стоит недорого и достаточно производительный для рабочих задач и игр. Не вижу смысла гнать. На байт сторонников АМД забил болт. Все орут про 14700к и 14900к, мол они бракованные.Со стороны похоже на бабкины сплетни у подъезда. 10 человек сказало, остальные подхватили. Деградации в основном подвержены виртуальные владельцы. И товарищи не имеющие понятия о взаимодействии процесса и тока.
"Куча возвратов". Куча - это сколько? Указывайте реальные исследования на эту тему, а не результаты экспериментов неудавшихся мамкиных гонщиков
Не, go тут лишний. Как и php. Это скорее как прикольный проект.
Если ваш код выглядит как примеры из статьи, попробуйте написать что-то на Python без классов или поиграть с Elixir. Это как детокс для мозга!
От структуры папки local уже плохо становится)
Вот думаю смеяться или плакать... "Лишний select запрос делаем". Ну да у вас же в секунду 100к регистраций будет проводиться... Ещё в комментариях предлагали constrained. Ну тут 50 на 50 в зависимости от того какое приложение. Если новостной блог, то Окей. Если что-то более сложное, то выносить бизнес логику на инфраструктурный слой ошибка.
Прочел ваш комментарий и вспомнил. Пришел я как то на проект, где люди пытались затащить гексагональную архитектуру. И все это непотребство пытался вытянуть один техлид, который до этого писал на С и занимался геймдевом) Человек яро отрицал необходимость чистой архитектуры и SOLID в этом подходе. Постоянно упарывался в преждевременную оптимизацию.
Подобные заявления звучат в духе "Перестаньте молиться на физику и математику". А статьи пишутся ради статей. Люди же до нас были глупые. Взяли и напридумывал принципы всякие. Работаю 5 лет backend разработчиком. За это время имел дело с кодом, который был написан с использованием принципов и без. Ясен пень что работать с кодом, который пыл написан на базе каких-то принципов, приятнее. Возможно когда-нибудь мы начнем писать опираясь не на SOLID, а на другие принципы. И что то мне подсказывает, принципы те будут основаны на базе того же SOLID.
Отлично, вы жёстко привязали инфраструктуру к домену
Круто конечно. Но со стороны похоже не костыль обернутый в синтаксический сахар)
Некоторые роутеры вроде поддерживают такую функцию
Смысл ДТО в транспортировке данных между слоями. Не понимаю почему в них так и норовят вкорячить логику fromArray, fromRequest... Это ужасно. Ещё не понимаю прикола с репозиториями, которые читают сохраняют данные одновременно. Так же не понятна идея передачей действий из controller в action, чтобы он потом передал в service и repository. Все это похоже на неудачные попытки затянуть фишки луковой архитектуры в трёхслойный MVC минуя нужные слои.
А можно просто взять готовый образ для docker и развернуть в 2 клика. Если понадобятся различные системы типа RabbitMQ, Elasticsearch, то придется вручную накатывать на ОС.
Не согласен. На данный момент потери минимальные.
После таких любителей "оптимизировать" внутреннюю кухню языка порой вешаешься на проекте... Давайте будем честными, на небольших объемах данных в 9 из 10 случаев всем будет насрать на сколько там память увеличилась. А если вы пытаетесь изменить что-то в массиве размером со "слона", то вы явно делаете что-то не так. Я даже не могу представить такую ситуацию)