#dmdev_code_review
Недавно наткнулся на примерно вот такой код.
Здесь происходит сериализация Java объекта в xml (обычная строка) с помощью библиотеки jaxb.

Как думаешь, что не так с методом serialize? Или все так?
PS. Предположения/идеи пиши в комментариях

1. Параметр marshaller изменяется внутри метода.
Best practices:
- clean code (всегда есть доступ к исходным параметрам функции)
- pure function/immutable (не изменяешь входные параметры, а значит безопасно вызывать такие функции извне)

2. Объект класса Marshaller - не потокобезопасный. Как и говорил в посте по code review выше - нужно всегда обращать внимание на работу кода в многопоточности. Поэтому лучше сделать вместо параметра - локальную переменную через jaxbContext (локальные переменные и jaxbContext точно потокобезопасны).

3. Многие писали про закрытие потока StringWriter. Но это не обязательно для данной реализации Writer, потому он что содержит внутри обычный объект типа StringBuffer.

4. <T extends Serializable> - тоже не следует делать для объекта сериализации, ибо ограничений у jaxb библиотеки на реализацию этого интерфейса тоже нет.

5. На null все параметры проверять и пробрасывать исключение тоже не имеет смысла - все методы будут громоздкие и неуклюжие. Используй Optional или обычные @NonNull аннотации, которые генерируют подобные проверки автоматически согласно fail fast principle

#dmdev_code_review

Как и обещал, выложил вчерашний уже третий выпуск live code review, где были разобраны 2 проекта, написанные на стандартном стэке технологий: Apache Maven, JUnit 5, Hibernate, Spring.

Также использовалось множество различных дополнительных библиотек:
- lombok для генерации boilerplate кода
- quierydsl для более удобного написания sql запросов с фильтрацией
- testcontainers для поднятия PostgreSQL в docker контейнере в интеграционных тестах
- liquibase для миграции баз данных
И многие другие, что были разобраны и объяснены на курсах dmdev.

Так что кто не смог участвовать, но очень хотел посмотреть - вот ссылка

#dmdev_code_review

👀 О чем этот канал и кто находится по ту сторону экрана?

Сразу скажу - этот канал не является сухой теорией о Java, потому что, во-первых, это скучно, а во-вторых, есть мои курсы DMdev, где теории с практикой более чем достаточно как для начинающих, так и для Senior разработчиков.

Начать знакомство с Java и DMdev можно с бесплатного курса на YouTube💻

Кто я такой и почему мне можно доверять?

Меня зовут Денис Матвеенко - и в первую очередь я не блогер, не предприниматель, а Software Engineer в Google. (именно поэтому, да простите меня подписчики, контент здесь не по расписанию, а по вдохновению и свободному времени😅)

Еще пару фактов обо мне:
- 10+ лет практического опыта в качестве Java разработчика
- работал в 7 различных компаниях: как аутсорсинговых, так и продуктовых
- 5+ лет преподаю Java: для начинающих и не только

#my_little_story - по этому хештегу рассказываю подробно свою историю с момента зарождения мысли "хочу стать программистом"

🗣 В этом канале я планирую делиться своим опытом, знаниями, идеями, своим видением мира и своими мыслями, которые могут быть интересны разработчикам любого уровня и не только.
Ибо выучить Java по телеграм каналам, давайте будем честны друг с другом, можно невозможно.

Моя суперспособность: умею декомпозировать и структурировать информацию + объяснять сложное человеческим языком

Моя слабость: у меня не очень хорошая память (а информации в программировании много), поэтому я предпочитаю ПОНИМАТЬ, а не ЗАПОМИНАТЬ

🗝 Секрет моего карьерного роста: любовь к программированию и ничего более

👉 Кстати, в этом посте поделился, как росла моя зп с самого начала карьеры

И еще несколько интересных постов для тебя:

1️⃣ Почему я предпочитаю инженерный подход в программировании?

2️⃣ Cдвиги парадигм, которые происходят у изучающих Java

3️⃣ Почему логирование ошибки и сразу ее пробрасывание дальше - является антипаттерном?

4️⃣ Best practices in code review

#dmdev_code_review - ищем ошибки в коде и разбираемся, как их исправить
#dmdev_qa - отвечаю на ваши вопросы

Задать анонимный вопрос можно тут:
https://forms.gle/FLHEHQ7GcSNjmtku5

В качестве подарка - забирай дорожную карту джависта - Java Roadmap с нуля до Senior🎁

Сode review н-нада?

Многие поддержали данное предложение, что ж, давайте попробуем реализовать его!

Кто хочет, чтобы я провел code review вашего кода - присылайте ссылку на github в комменты под этим постом.
Я рандомно выберу один проект и в следующем посте опубликаю краткое резюме по коду с ссылкой на код с моими комментариями

Условия участия:
- Проект опубликован на github
- Весь код в виде одного пул реквеста или коммита
- Чем больше кода - тем больше добавить описания о нем в README файле (чтобы я понимал о чем проект)
- Не удалять пул реквест или коммит после code review
- Согласие на то, что ваш разбор попадет в этот канал
- Ссылки жду до 6 мая включительно

P.S. Если зайдет рубрика, то можем ввести ее на постоянной основе, например, каждое первое число
#dmdev_code_review

#dmdev_code_review
Как и обещал, выбрал одного из участников, чтобы провести code review.

Хотелось бы отметить общие частовстречаемые ошибки, которые в то же самое время очень важны:

1. Не следует изменять статические поля в нестатическом контексте. Чаще всего это приводит к ошибкам в многопоточности или попросту неверно работает код.

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

3. Не стоит писать код на исключениях - клиентский код потом становится громоздким с кучей try/catch блоков. Пробрасывать исключения следует тогда, когда действительно произошла ИСКЛЮЧИТЕЛЬНАЯ ситуация, которую никак не избежать. Например, гораздо приятнее возвращать true/false в методе delete вместо пробрасывания исключения, если такой сущности не оказалось по переданному id.

4. Связанно с предыдущим пунктом: не нужно проглатывать исключение, пробрасывая свое кастомное - иначе теряется stacktrace рутовой ошибки и будет очень сложно понять что произошло. Если нужно обернуть одно исключение в другое - просто передавайте его как параметр в конструктор: new DatabaseException(sqlException)

5. Разумно подходить к использованию Optional & Streams. Какой-то код лучше писать в функциональном стиле, какой-то в императивном, какой-то в комбинации двух предыдущих. Но в любом случае стоит граммотно использовать все подходы. Возьмем простой случай: возвращать Optional из метода, который может вернуть null. И, наоборот, если метод всегда возвращает объект - то не стоит оборачивать его в Optional, ибо это доставляет неудобства клиенту.

6. Давать хорошие имена переменным, методам, классам - всему в коде. Иначе очень сильно усложняется чтение кода, на которое программист тратит большую часть своего рабочего времени. Особенно избегать таких имен, которые подразумевают только ЧТЕНИЕ, а по факту там происходит изменения состояния объектов - т.е. ЗАПИСЬ. Например, findProduct(productId) - а внутри изменение состояния объекта Product.

P.S. Весь список комментариев по code review можно найти в пул реквесте по ссылке

P.P.S. Если есть вопросы по коду/моим замечаниям, что я оставил - то можете задавать их прям здесь под постом в комментариях