Переведу для остальных: "я навайбкодил что-то, что работает. Я этому рад и делюсь с вами своей радостью. Мне известен принцип его работы, но если что-то сломается - я надеюсь лимиты у меня еще есть"
Спасибо за статью. Правда. Приятно понимать, что еще не все сошли с ума на хайпе ИИ и есть трезвомыслящие люди которые осознают, что что-то идет не так.
Подписываюсь под всеми вашими словами. Лень, хайп, заблуждение, алчность - вот фундамент сегодняшней системы разработки с псевдоИИ (подозреваю, что на последнее место куда я собесился меня не взяли из того, что я на вопрос об отношении к разработке и ИИ, ответил, что крайне им не доверяю и вынужден проверять каждый шаг. Привет Газпром)
На самом деле там все просто) при отсутствии явного ордеринга перехватчики будут выставлены по алфавиту)) То есть сначала CacheInterceptor потом TransactionInterceptor а AspectJAroundAdvice преобразуется в InstantiationModelAwarePointcutAdvisorImpl и будет последним в очереди
С посылом статьи на 100% согласен, к оформлению доказательств вопросы...
КОД каждого участника в студию! А так субъективному оценочному суждению привык не доверять, уж извините.
И мидла незаслуженно унизили) Ему задачки закрывать надо, быстро и более менее качественно. Ну нет у него 2-3 часа на неспешные раздумия, на таких как он IT держится.
И по соотношениям время исполнения/качество/цена работы в час он явно будет впереди.
А этому в принципе не верю (Сеньор с нейросетью 10 минут Все преимущества, что и без нейросетей 9/10 Все преимущества, что и без нейросетей). Нейросеть то та же. А значит выдаст тот же примитив. Ну и если сеньор за 9 минут 30 секунд реализовал все как боженька, то я Жанна Дарт Вейдер))))
Но вы почему-то делаете из сеньора какого-то зазнайку. Он по вашему постоянно съезжает с темы, начинает погружаться туда, куда не просили и действительно, как написано выше в комментах, забалтывать вопрос.
И не смотря на то что в статье действительно много полезных фактов в целом она не несет какой-то ценности для любого грейда кроме понимания - "Если сеньор такой - то я не сеньор"
Спасибо за код. Если это действительно из собесов, то тут поле не паханное))
Каюсь, сначала нашел не то что вы указали)
Но предлагаю в список добавить и эти (сори не читал комментарии может уже что-то есть):
Отсутствие версионирования (/v1/payments) - API без версии ломает обратную совместимость при любом изменении. Клиенты, завязанные на этой версии, перестанут работать. Вообще показывает способность к расширению
ResponseEntity<?> сырой дженерик теряет информацию о типе тела ответа. В Swagger/OpenAPI это превратится в object, клиенты не смогут сгенерировать типизированные модели
@RequestBody Map<String, Object> теряется контракт API. Нет @Valid, нет документации полей, нет контроля типов. Любое изменение структуры ломается в рантайме ClassCastException
new Date() java.util.Date - мутабельный, устаревший класс, не рекомендуется к использованию хотя и допустимф
p.setStatus("PENDING") строковый литерал для статуса - это нонсенс. Опечатка ("PENING") не будет поймана компилятором, думаю выводы сделаете сами)
!"OK".equals(r) Не совсем плохо но лучше - !Objects.equals("OK", r), более явно проверяет что r != null
Вызов kafka.sendбез обработки результата метод асинхронный, но исключения теряются. Нужно добавить callback или использовать синхронную отправку.
RuntimeException - слишком общее исключение. Оно не говорит вызывающему коду (и глобальному обработчику) о том, что именно пошло не так. Лучше - кастомную
Далее более архитектурная проблема:
@Transactional на методе контроллера и отсутствие сервисного слоя Когда вы ставите @Transactional на контроллер, контроллер берёт на себя ответственность за управление транзакциями - это нарушает принцип SR Что ждет с таким подходом: - нормально не протестировать - придется кучу зависимостей тянуть и все либо мокать либо подымать - невозможно переиспользовать логику, для написания похожей обработки - новая ручка - расширение приведет только к росту проблем
Вы утверждаете, что проблема сводится к двум спискам которые не влезают. Я показал, что даже когда список один, GC начинает деградировать задолго до OOM.
Разве это противоречит вашему тезису?
Нет, оно его дополняет. Это два уровня анализа одной проблемы - вы говорите о причине (два списка), я - о процессе (как именно это убивает JVM).
Оба наблюдения верны, и оба есть в статье.
Я учту все рассмотренные нюансы и сделаю следующий эксперимент чище
Переведу для остальных: "я навайбкодил что-то, что работает. Я этому рад и делюсь с вами своей радостью. Мне известен принцип его работы, но если что-то сломается - я надеюсь лимиты у меня еще есть"
Спасибо за статью. Правда. Приятно понимать, что еще не все сошли с ума на хайпе ИИ и есть трезвомыслящие люди которые осознают, что что-то идет не так.
Подписываюсь под всеми вашими словами. Лень, хайп, заблуждение, алчность - вот фундамент сегодняшней системы разработки с псевдоИИ (подозреваю, что на последнее место куда я собесился меня не взяли из того, что я на вопрос об отношении к разработке и ИИ, ответил, что крайне им не доверяю и вынужден проверять каждый шаг. Привет Газпром)
Вы скопировали мои мысли
"Всяк кулик свое болото хвалит"
Жаль, а я надеялся в статье найти реальный кейс. Хотя и работы то нет...))
Вот одного не понял - а Java где?
На самом деле там все просто) при отсутствии явного ордеринга перехватчики будут выставлены по алфавиту))
То есть сначала CacheInterceptor потом TransactionInterceptor а AspectJAroundAdvice преобразуется в InstantiationModelAwarePointcutAdvisorImpl и будет последним в очереди
Вариант - "А у него длинее...", аххах)))))
Спасибо на добром слове) Не было комментариев - думал уже ерунду написал что-ли))))
Поразмышлял над вашей статьей еще раз.
Оформил экспериментус. Дипсику скормил хороший промпт и вашу задачу.
Вот что он мне выдал
Скрытый текст
Теперь вывод: у сеньора промпт лучше. За 10 минут он еще кофе с сигаретой прикончить успел.
Полюбому
С посылом статьи на 100% согласен, к оформлению доказательств вопросы...
КОД каждого участника в студию!
А так субъективному оценочному суждению привык не доверять, уж извините.
И мидла незаслуженно унизили) Ему задачки закрывать надо, быстро и более менее качественно. Ну нет у него 2-3 часа на неспешные раздумия, на таких как он IT держится.
И по соотношениям время исполнения/качество/цена работы в час он явно будет впереди.
А этому в принципе не верю (Сеньор с нейросетью 10 минут Все преимущества, что и без нейросетей 9/10 Все преимущества, что и без нейросетей).
Нейросеть то та же. А значит выдаст тот же примитив. Ну и если сеньор за 9 минут 30 секунд реализовал все как боженька, то я Жанна Дарт Вейдер))))
Хоть это больше и реклама, спасибо за труд.
Но вы почему-то делаете из сеньора какого-то зазнайку. Он по вашему постоянно съезжает с темы, начинает погружаться туда, куда не просили и действительно, как написано выше в комментах, забалтывать вопрос.
И не смотря на то что в статье действительно много полезных фактов в целом она не несет какой-то ценности для любого грейда кроме понимания - "Если сеньор такой - то я не сеньор"
Хорошая статья, немного затянутая, но подробная. Могу посоветовать эту серию видео где данная Observabilty (в т.ч.) разбирается.
Спасибо за код. Если это действительно из собесов, то тут поле не паханное))
Каюсь, сначала нашел не то что вы указали)
Но предлагаю в список добавить и эти (сори не читал комментарии может уже что-то есть):
Отсутствие версионирования (
/v1/payments) - API без версии ломает обратную совместимость при любом изменении. Клиенты, завязанные на этой версии, перестанут работать. Вообще показывает способность к расширениюResponseEntity<?>сырой дженерик теряет информацию о типе тела ответа. В Swagger/OpenAPI это превратится в
object, клиенты не смогут сгенерировать типизированные модели@RequestBody Map<String, Object>теряется контракт API. Нет
@Valid, нет документации полей, нет контроля типов. Любое изменение структуры ломается в рантаймеClassCastExceptionnew Date()java.util.Date- мутабельный, устаревший класс, не рекомендуется к использованию хотя и допустимфp.setStatus("PENDING")строковый литерал для статуса - это нонсенс. Опечатка ("PENING") не будет поймана компилятором, думаю выводы сделаете сами)
!"OK".equals(r)Не совсем плохо но лучше - !Objects.equals("OK", r), более явно проверяет что
r != nullВызов
kafka.sendбез обработки результатаметод асинхронный, но исключения теряются. Нужно добавить callback или использовать синхронную отправку.
RuntimeException- слишком общее исключение. Оно не говорит вызывающему коду (и глобальному обработчику) о том, что именно пошло не так. Лучше - кастомнуюДалее более архитектурная проблема:
@Transactionalна методе контроллера и отсутствие сервисного слояКогда вы ставите
@Transactionalна контроллер, контроллер берёт на себя ответственность за управление транзакциями - это нарушает принцип SRЧто ждет с таким подходом:
- нормально не протестировать - придется кучу зависимостей тянуть и все либо мокать либо подымать
- невозможно переиспользовать логику, для написания похожей обработки - новая ручка
- расширение приведет только к росту проблем
В чем выгода по сравнению с кейклок или аутентик?
Я бы порекомендовал для затравки статьи описать проблему которую вы решили применением данного решения. Пока ценность только в отказе от спринга.
Это уже реальность. Ты опоздал с ожиданиями
Я не вижу причин продолжать это обсуждение.
Вы частично правы, но не до конца.
Вы утверждаете, что проблема сводится к двум спискам которые не влезают. Я показал, что даже когда список один, GC начинает деградировать задолго до OOM.
Разве это противоречит вашему тезису?
Нет, оно его дополняет. Это два уровня анализа одной проблемы - вы говорите о причине (два списка), я - о процессе (как именно это убивает JVM).
Оба наблюдения верны, и оба есть в статье.
Я учту все рассмотренные нюансы и сделаю следующий эксперимент чище
Уважаю вас, за вашу настойчивость.
Так упорно доказывать свою точку зрения не пытаясь вникать в даваемые ответы - достойно восхищения. Вы нашли "новые ворота".
Наверно уже все кто читал и не читал данную статью поняли вашу точку зрения. Да, и я тоже.
Да, вариант того что разработчик загрузит 1.5 миллиона записей в память ужасен, ненормален и всячески осуждаем.
НО! НЕ НЕВОЗМОЖЕН...
А это значит все последующие обсуждения глубоко бессмысленны...
Спасибо за идею про статью о выносе аллокаций из hot path — возможно, я её реализую
Очень профессиональный комментарий, да...