You've successfully subscribed to Заметки Разработчиков
Great! Next, complete checkout for full access to Заметки Разработчиков
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info is updated.
Billing info update failed.

middle

Spring Data JPA: метод save и границы его применимости

Spring Data JPA: метод save и границы его применимостиПривет! Меня зовут Семён Киреков , я Java-разработчик и тимлид в Центре Big Data @ МТС Digital и Java-декан в МТС Тета — образовательном стартапе в рамках МТС. На митапе Росбанка и Jug.ru я...HabrROSBANK Вроде хорошая статья про внутреннее устройство Hibernate. Если

Spring Data JPA: метод save и границы его применимости
Привет! Меня зовут Семён Киреков , я Java-разработчик и тимлид в Центре Big Data @ МТС Digital и Java-декан в МТС Тета — образовательном стартапе в рамках МТС. На митапе Росбанка и Jug.ru я...

Вроде хорошая статья про внутреннее устройство Hibernate. Если вы все еще вызываете метод save() репозитория на каждый чих, то рекомендую статью к прочтению.

Рецензия: Добровольно принудительный Spring

Посмотрел недавно доклад, который называется "Добровольно принудительный Spring". Доклад мне в целом понравился, хоть я и не узнал ничего нового для себя. И я ожидал практические кейсы, best practices, которые улучшат код. Но доклад оказался больше философско-теоретическим. Суть доклада в том, что современные фреймворки облегчают разработчикам задачу писать некачественный код,

Посмотрел недавно доклад, который называется "Добровольно принудительный Spring". Доклад мне в целом понравился, хоть я и не узнал ничего нового для себя. И я ожидал практические кейсы, best practices, которые улучшат код. Но доклад оказался больше философско-теоретическим.

Суть доклада в том, что современные фреймворки облегчают разработчикам задачу писать некачественный код, нарушая S.O.L.I.D. Как пример, Lombok+Spring, когда вы ставите аннотацию @RequiredArgsConstructor над классом, который принимает 20 параметров в конструкторе, а спринг сам за вас создаст и внедрит эти 20 классов. Так как все это легко просто и много кода не занимает, то в голове у разработчика может и не екнуть, что он делает что-то не так, и зачем ему столько параметров в конструкторе.

Забавный вывод, что мы не далеко ушли от Pascal. В паскале тоже были модули/зависимости. В паскале функции/процедуры, а наш типичный код сейчас это бин, который по факту является мешком функций. То есть никакого ООП по факту нет. Ну и единственное что у нас появилось, в отличие от паскаля, это модульные тесты, а значит нам нужно изо всех сил стараться использовать это, и облегчить себе тесты, а значит:

  • Никаких private методов. Их нельзя замокать, и поэтому тестировать становится сложнее.
  • Никаких static методов по этой же причине.

Спорные утверждения конечно, но что имеем.

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

Мне притно, что начали появляться докладчики, которые признают, что никакого ООП у нас по факту нет, оно возможно есть только в головах у интервьюерах на собеседованиях. Собственно то что проповедует Егор Бугаенко по факту правда.

Только вот подход Егора в том, что надо пытаться учиться писать в стиле ООП, а посыл этого доклада в том, что надо смириться и просто жить с этим, потому что настоящих ООП проектов никто в глаза не видел.

Для меня ближе второй вариант, эволюция она такая, бессердечная.