Любопытно и противоречиво. Например в части getter и setter. У нас множество сервисов-оркестраторов. Часто надо взять данные из одной части, передать в другую, там сформировать дто вызова и это все в JSON и в REST. У меня тут участвуют минимум 3 дто класса с множество полей и одним назначением - передать информацию между разными участками кода. Так почему бы мне не заменить тонну геттеров и сеттеров аннотацией?
Абсолютно не согласен насчёт утверждения, что в статье представлен пример «дивергентного мышления».
1. Все описание не соответствует критериям дивергентного мышления.
В статье представлен элементарный пример решения с обратной связью. Вы каждый раз давали ИИ обратную связь, то есть уточняли свой запрос. А вот если бы вы единожды четко сформулировали вопрос, получили бы ряд решений (хотя бы одно из которых даже в голову вам не пришло бы) и одно из которых ИИ признал бы лучшим - это уже дивергентное мышление
Дивергентное мышление основано на рефлексии. Но вместо ИИ вы рефлексировали все решения. Так что вы лишь привели пример своего дивергентного мышления
Если код корректно структурирован, к особо сложным участкам есть тест - то комментарий становится бессмысленным. Иначе начинается цирк в стиле - метод createNewClient / комментарий - метод создания нового клиента
Лучше бы заботились о том, чтобы разработчик писал хорошо поддерживаемый код, соблюдая принципы и паттерны. Тогда новому разрабу не придется ломать голову
Безусловно очень правильные и полезные советы, однако: не следил за зубами, пришлось парочку вырвать и заменить на импланты. При этом есть щелчки при открытии челюсти. Но не постоянно, порой целый день может не быть щелчков. Так вот - врачи сказали - надо исправлять прикус. Посмотрели туда сюда и говорят - у вас верхняя челюсть уже чем нижняя, надо расширять. Расширять операцией, вам сломают верхнюю и ввинтят расширитель. будете так жить, потом еще сделаем брэкеты. Суммарно за миллион все вышло. Вот ваша статья декларирует, что все, капец, вскоре буду умирать от дискомфорта. А с другой стороны адская сумма денег, которую никогда не накоплю и неясного рода операция. Я решил проигнорировать советы врачей и поверить в удачу, имплантировали зубы, пока что все ок.
Да, пример unit теста на DTO идеален. Ведь DTO всегда имеют разветвлённую логику. отличный пример, который доказывает, что притянуть в проект ChatGPT - отличная идея.
Вот только один вопрос остался по итогу - вы действительно потратили бы на этот юнит 1-2 часа? Я навскидку однозначно могу сказать, что на Java написал бы его минут за 15 максимум (с проверкой на негативные и позитивные сценарии). Может это конечно специфика PHP, я с пыхой не друг…
У нас на проекте используется mapstruct. И вот типовой пример: один из микросервисов не возвращает атрибут. Чтобы понять - че за фигня - надо раскручивать логи нескольких микросервисов. Время тратится будь здоров. Оказывается что сервис добавления этого атрибута при маппинге данных из соседней системы - не смапился. Потому что у нас это атрибут (условно) userRole , а в смежной системы userTeamRole. Прогер поленился написать тест, чтобы проверить что все мапится корректно и он ничего не упустил. Вы скажите - ну так прогер виноват, он не учёл и не добавил аннотацию. Так и юнит тесты пишем чтобы как раз уменьшить число таких косяков
За два года работы с java кодом Вы ни разу не удосужились изучить Spring? И судя по результатам собесов java core знали посредственно? И рассчитывали на middle? Любопытно
Шёл 2024 год, а LLM все ещё называют ИИ.
С таким же успехом интервью можно было взять у фантазёра с улицы. Почитайте его «предсказания». Дядька пальцем в небо тычет и то каждый раз мимо.
Любопытно и противоречиво. Например в части getter и setter. У нас множество сервисов-оркестраторов. Часто надо взять данные из одной части, передать в другую, там сформировать дто вызова и это все в JSON и в REST. У меня тут участвуют минимум 3 дто класса с множество полей и одним назначением - передать информацию между разными участками кода. Так почему бы мне не заменить тонну геттеров и сеттеров аннотацией?
Абсолютно не согласен насчёт утверждения, что в статье представлен пример «дивергентного мышления».
1. Все описание не соответствует критериям дивергентного мышления.
В статье представлен элементарный пример решения с обратной связью. Вы каждый раз давали ИИ обратную связь, то есть уточняли свой запрос. А вот если бы вы единожды четко сформулировали вопрос, получили бы ряд решений (хотя бы одно из которых даже в голову вам не пришло бы) и одно из которых ИИ признал бы лучшим - это уже дивергентное мышление
Дивергентное мышление основано на рефлексии. Но вместо ИИ вы рефлексировали все решения. Так что вы лишь привели пример своего дивергентного мышления
А как бы вы предложили назвать функцию? hasLoginOnlyLatterInLowerCaseWithUnderacoreAndThrowExceptionIfInvalid?
Если код корректно структурирован, к особо сложным участкам есть тест - то комментарий становится бессмысленным. Иначе начинается цирк в стиле - метод createNewClient / комментарий - метод создания нового клиента
Лучше бы заботились о том, чтобы разработчик писал хорошо поддерживаемый код, соблюдая принципы и паттерны. Тогда новому разрабу не придется ломать голову
Что в качестве альтернативы рекомендуете? Не монолиты же?
Безусловно очень правильные и полезные советы, однако: не следил за зубами, пришлось парочку вырвать и заменить на импланты. При этом есть щелчки при открытии челюсти. Но не постоянно, порой целый день может не быть щелчков. Так вот - врачи сказали - надо исправлять прикус. Посмотрели туда сюда и говорят - у вас верхняя челюсть уже чем нижняя, надо расширять. Расширять операцией, вам сломают верхнюю и ввинтят расширитель. будете так жить, потом еще сделаем брэкеты. Суммарно за миллион все вышло. Вот ваша статья декларирует, что все, капец, вскоре буду умирать от дискомфорта. А с другой стороны адская сумма денег, которую никогда не накоплю и неясного рода операция. Я решил проигнорировать советы врачей и поверить в удачу, имплантировали зубы, пока что все ок.
Да, пример unit теста на DTO идеален. Ведь DTO всегда имеют разветвлённую логику. отличный пример, который доказывает, что притянуть в проект ChatGPT - отличная идея.
Вот только один вопрос остался по итогу - вы действительно потратили бы на этот юнит 1-2 часа? Я навскидку однозначно могу сказать, что на Java написал бы его минут за 15 максимум (с проверкой на негативные и позитивные сценарии). Может это конечно специфика PHP, я с пыхой не друг…
У нас на проекте используется mapstruct. И вот типовой пример: один из микросервисов не возвращает атрибут. Чтобы понять - че за фигня - надо раскручивать логи нескольких микросервисов. Время тратится будь здоров. Оказывается что сервис добавления этого атрибута при маппинге данных из соседней системы - не смапился. Потому что у нас это атрибут (условно) userRole , а в смежной системы userTeamRole. Прогер поленился написать тест, чтобы проверить что все мапится корректно и он ничего не упустил. Вы скажите - ну так прогер виноват, он не учёл и не добавил аннотацию. Так и юнит тесты пишем чтобы как раз уменьшить число таких косяков