с ходу что увидал в контроллере.


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

1) далее, по сервису. ты как то странно создаешь инициальные тестовые данные )) это лишнее ) мог бы просто утиль написать или там скуэль скрипт какой. вообще это имхо лишнее в задании. ты еще и дто в конструктор сервиса передаешь (шта?)
2) ты файндолл делаешь с пагинацией по 200 )) а потом из полученной паги тащишь стримом переборку на совпадение. это лишнее от тебя ждали или там джейпиэй типа repository.findByNameLike("whateverString") - это вообще ОДНА строчка на ВЕСЬ МЕТОД вместо твоей требухи,
либо же простым жпкл запросом типа "select entity e where e.name like :param" либо вообще простым скл нативным запросом (как Вадя любит). - всё-равно одна строка.

3) нейминг в целом. но это может я придираюсь. я бы сделал стандартную структуру папок контроллер, сервис, репозиторий, домейн. ну или как то так.

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

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

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

сорян по первому пункту.. там оказывается дао а не дто.
впрочем, я не сторонник подвязывать всё через конструкторы, я бы сделал с аннотацией автоваер но это холиварный топик. так что пофигу.

TsyklopandreykaT1) далее, по сервису. ты как то странно создаешь инициальные тестовые данные )) это лишнее ) мог бы просто утиль написать или там скуэль скрипт какой. вообще это имхо лишнее в задании. ты еще и дто в конструктор сервиса передаешь (шта?)


пример?

andreykaT2) ты файндолл делаешь с пагинацией по 200 )) а потом из полученной паги тащишь стримом переборку на совпадение. это лишнее от тебя ждали или там джейпиэй типа repository.findByNameLike("whateverString") - это вообще ОДНА строчка на ВЕСЬ МЕТОД вместо твоей требухи,
либо же простым жпкл запросом типа "select entity e where e.name like :param" либо вообще простым скл нативным запросом (как Вадя любит). - всё-равно одна строка.


1. Я использую не Spring Data JPA, а Hibernate. У него нет repository.findByNameLike , тут все писать ручками надо.
2. Вы наверно не читали условия. Фильтровать только в Java, в SQL нельзя.

andreykaT3) нейминг в целом. но это может я придираюсь. я бы сделал стандартную структуру папок контроллер, сервис, репозиторий, домейн. ну или как то так.


а сейчас разве не так? controller, dao, service, entity. что не так? dao для хибера, для Spring Data JPA пишут repository.

andreykaT3.1) я не думаю что отдавать ентити как есть клиенту это хорошая идея - я бы заюзал маппер и перекатывал бы ее поля на дтоху которую бы и отдавал. но это наверное и не требовалось.


тут согласен, не учел.

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


Какого такого опыта? в чем именно опыта нет? пытаюсь понять это.

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

и почему repo.findByNameLike -- это не джава аппроач? )) ни одной скл строки тут я не вижу. раз нет скл - значит не скл.

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

но если нельзя скормить регексп репозиторию и нельзя юзать натив скл, то вариант один -- стримы перебором и ВСЁ. вот совсем всё. если этот олень оценщик в комменте к твоему коду говорит что это "неэффективно" то пусть скажет че он хочет вообще? ты или перебираешь это (окей можно на потоки разбить и перебирать в некоей условной параллели) -- или делаешь склом. других вариантов НЕТ. от слова совсем.

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

TsyklopandreykaT1) далее, по сервису. ты как то странно создаешь инициальные тестовые данные )) это лишнее ) мог бы просто утиль написать или там скуэль скрипт какой. вообще это имхо лишнее в задании. ты еще и дто в конструктор сервиса передаешь (шта?)

пример?

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

HettРеализовать какой-то поиск с временной сложность о(1) тут наверное вообще не реально. Так что основное время будет тратиться на матчинг регуляркой.
лол. тут поиск будет если несортированные данные - N, если сортированные то логарифм, о да, я кэп. чудес не бывает.

и да... оценщик не умеет писать -тся -ться. за такое надо из рогатки убивать еще в детском саду.

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

типа такого.




в кавычках название процедуры.
это скл? (ну в смысле в понимании тестирующего).

авторТребует доработки:
1. Использование String.matches для каждого контакта - неэффективно. // Я переделал на Pattern/Matcher
2. Вычитывать все записи из базы на каждый запрос от каждого пользователя неэффективно
3. Захардкодженый pageSize // В условиях задания об этом ничего не говориться
4. Поиск в базе из миллионна записей занимает 5 минут
5. Отсутствуют тесты. // Тесты более менее написал. Хоть что-то. Ибо сути их все равно понять не могу И что именно тестить тоже.

1. интересно, обосновать сможет в устной беседе?
2. почему? а если у нас от запроса к запросу данные могут меняться? или не могут?
3. художник так видит. ну и чо? впрочем, я бы вообще пейджсайз не мутил. хотят джаву - на тебе стрим без скип тейков и наслаждайся
4. лолшто? а че он хотел то?
5. ну тут да.. тесты тестируют что 500 не приходит можно было бы добавить там разные поиски паттерны и т.п.

Hettавтор1. интересно, обосновать сможет в устной беседе?
Регулярка будет поятоянно компилироваться, или нет?
да. ну там паттерн просто тоже надо правильно написать чтоб он регулярно не компилился )) у тса все верно. )) так просто вопрос на уверенность знаний.

ну да по стилистике тз писал человек какой-то не технический, с навыками литератора.. "огромное предполагаемое количество контактов" )) што? ) фильтр обязательно применять в java коде не использовать возможности SQL -- снова што??
ну точно литератор. у меня на прошлом проекте девочки-писилявки и то лучше тз излагали на бумаге.

fixxerandreykaT,

Это не ТЗ, это тестовое задание, оно по определению должно быть позаковыристее или нечетко сформулированное, потому что заодно проверяет, как вы работаете с информацией и какие дополнительные вопросы задаете. Задание, кстати, неплохое, отлично отсеивает тех, кто за пределы букваря по спрингу, хиберу и SQL никогда не выходят.
это формальные требования к законченному продукту. они должны быть сформулированы ясно, однозначно и непротиворечиво. это как минимум, указывает на качество тех кто поставляет требования. тут мало того, что требования написаны каким-то потомком пушкина, так еще и с ошибками. и да, у меня было бы некоторое количество вопросов по такому "заданию". а если потом такой гражданин тебе задания будет выставлять каждый день то может и не стоило туда бы идти? ))

чел просит искать стримами миллион записей а потом говорит ой чот медленно работает... эээ, слыш, ты чо больной чтоле?

Андрей ПанфиловandreykaTлол. тут поиск будет если несортированные данные - N, если сортированные то логарифм, о да, я кэп. чудес не бывает.
Поиск типа "строка не содержит букву 'а'" - причем тут сортировка?
а какая разница бинарному поиску между искать есть ли строка или искать нет ли строки? это ж одно и то же

HettАндрей Панфиловпропущено...
на create контракта в ТЗ нет, поэтому 200 там вполне себе, более того, там никаким PUT и не пахнет, поэтому про 201 не может быть и речи.

А задание и ставится с недоговорками, чтобы человек не пошел и не нагуглил (например там не слова про регулярки, а они есть).
В задании сказано вообще про стандартные коды ошибок http (не понятно только как это с заданием связано), могу предположить что это опечатка, и не "коды ошибок" а "коды ответов" имелось в виду.

Если разработчик работал с rest сервисами, то уже "по привычке" сделает все с более подходящими под случай кодами ответа и даже не задумается. При неверном запросе же будет ответ 404, а не 200, почему тогда при создании 200, а не 201?
Я даже не говорю про restful, где для создания и получения сущности должен быть один эндпоинт.

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

кстати, еще одна придирка - у него в ендпоинтах не указано каким методом. т.е. вместо гета можно делетом
с параметрнами получить ответ список клиентов ))

да и структура не очень. имхо, хелло там лишнее. надо только один явный гет\контактс на весь контроллер и всё. если конечно мы хоть как то хотим держать архитектуру реста.