vitya_brodov

Для проверки кода https://codereview.stackexchange.com

Для опенсорс проектов:
https://www.codetriage.com
https://www.broadleafcommerce.com/

ну и github

У code review должна быть цель. В моей практике обычно проекты небольшие и там нет отдельных тестировщиков. Получается, что code review отвечает на три вопроса:

1. Соответствует ли функционал ТЗ?
   
2. Создает ли код проблемы команде?
   
3. Есть ли тут какой-то специфичный для проекта опыт, который лучше задокументировать, пока мы еще в контексте?
   

Получается что-то такое:

• До выполнения задачи: проводится анализ задачи, формулируется ТЗ. Бывает, что нужно подключиться и помочь с требованиями, с контекстом, в котором все делается. Чем более подробный анализ мы делаем и чем лучше мы понимаем контекст на этом этапе, тем больше вероятность, что потом весь процесс выполнения задачи пойдет как по маслу и code review будет чистой формальностью в конце.
  
• До ревью: линтеры проверяют код на соответствие стилю, на отсутствие синтаксического бреда.
  
• Дальше - проверка на соответствие функционала ТЗ. Это защита от глупых ошибок в продакшене, которые коснутся пользователей.
  
• Потом - на сответствие принятым соглашениям по коду, если они есть в проекте. Обычно это архитектурные паттерны и что-то про зависимости, смотрим не создает ли код проблем окружающим, а то разные глупости порой случаются. Особенно это важно в коде, который не сам в себе, а затрагивает много чего вокруг. Иногда возникает конфликт интересов, когда что-то явно устарело, и соглашения дополняются чем-то. Чем лучше был анализ в начале, тем меньше вероятность, что тут будет, что обсуждать.
  
• Дальше уточняющие вопросы по странным местам, если они есть. Это больше с целью узнать контекст задачи, почему приняты те или иные решения. Происходит передача специфичных для проекта знаний в сторону команды. Возможно там же будут какие-то рекомендации по поводу практик, на что стоит обратить внимание в следующий раз. Это будет передача опыта от команды.
  

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

var dateString = "202208";
        var inFormat = new SimpleDateFormat("yyyyMM");
        var date = inFormat.parse(dateString);
        System.out.println(date);  // Mon Aug 01 00:00:00 MSK 2022

        var outFormat = new SimpleDateFormat("yyyy MMMM");
        var dateFormatSymbols = new DateFormatSymbols();
        dateFormatSymbols.setMonths(new String[]{"Папа", "у", "Вити", "силен", "в", "джаве.", "Работает", "Август", "папа", "за", "Витю", "весь", "год"});
        outFormat.setDateFormatSymbols(dateFormatSymbols);
        System.out.println(outFormat.format(date)); // 2022 Август

operation_[A-Z]

Можно. Разрешаю.

ВЫ получаете деньги? на них кушаете? содержите семью... ЗП устраивает? в чем проблема?? бухните, отдохните, развейтесь.. в конце коцнцов закажите "девочку" если все плохо с этим..
Нет каши не будет,разные языки. Изучайте как хобби
Не допустить каши - уметь "переключаться" и "фильтровать информацию". но это нарабатываемый навык

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

Итак, насколько я вас понял, то вы хотите обновить существующую запись на основе данных, которые прибежали из контроллера в виде DTO.

Во-первых, в данном случае стоит использовать PutMapping (full updates) или PatchMapping (partial updates)
Читаем подробно тут:
https://www.baeldung.com/http-put-patch-difference...

Во-вторых, после того, как вы получили DTO вам необходимо его замаппить в Entity и обновить в БД. Однако, могут быть поля, которые не были заполнены в DTO и вы не хотите, чтобы они были применены, как null, так?

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

Вам не нужно дозаполнять поля сконвертированного entity. Вам необходимо:
1) найти этот entity по идентификатору.
2) Если не хотите, чтобы null поля были применены к сущности, то при маппинге (см. ниже) сделать null check и если поле DTO null, то не сеттить его к сущности.
3) сохранить сущность.

Что касается маппинга:
1) Вы можете использовать интерфейс Converter<S, T>. И для каждого из полей сделать проверку типа (псевдокод):

if (fieldValue != null) { entity.setField(fieldValue); }

2) Если вы используете какую-либо библиотеку для маппинга (modelMapper, MapStruct и др.), то используйте возможности либы. Например, для modelMapper:

modelMapper.getConfiguration().setPropertyCondition(Conditions.isNotNull());

https://stackoverflow.com/questions/45451025/how-t...

Также прокомментирую ваши комментарии из другого ответа:

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

Можно настроить кеширование и тогда, обращения к БД не будет.

Это базовая ситуация, с которой сталкивается каждый. Допустим у меня entity Person с атрибутом даты рождения, которую я не хочу отображать в PersonDto. Когда пользователь пришлем мне PersonDto по API для, допустим, операции обновления, то как мне при конвертации в entity вернуть эту дату рождения, чтобы я мог сохранить новую сущность?

Обратите внимание на то, что может быть несколько DTO.
Например,
PersonCreationRequest - dto, которое заполняется из фронта при создании юзера
PersonCreationResponse - dto, которое заполняется из бекенда после создания юзера
PersonUpdatingRequest - dto, которое заполняется из фронта при обновлении юзера
PersonUpdatingResponse - dto, которое заполняется из бекенда после обновления юзера
PersonDto - общее dto, которое заполняется из бекенда для других нужд.
Могут быть и другие DTO...
Соответственно, ответ на ваш вопрос - используйте разные DTO.

Не знаю насколько точно смог ответить на ваш вопрос.

Java EE - это набор стандартов. Причём актуальный. На этих стандартах Spring и построен. Можно не учить, и дело не в том, что будет тяжело, просто профессионалом не станешь. Будешь подобен девочке, знающей про свою машинку только то, что они красненькая и в неё иногда надо бензин заливать.

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