Spring Data JPA: метод save и границы его применимостиПривет! Меня зовут Семён Киреков , я Java-разработчик и тимлид в Центре Big Data @ МТС Digital и Java-декан в МТС Тета — образовательном стартапе в рамках МТС. На митапе Росбанка и Jug.ru я...HabrROSBANK Вроде хорошая статья про внутреннее устройство Hibernate.
ROSBANK
Вроде хорошая статья про внутреннее устройство Hibernate. Если вы все еще вызываете метод save() репозитория на каждый чих, то рекомендую статью к прочтению.
Посмотрел недавно доклад, который называется "Добровольно принудительный Spring". Доклад мне в целом понравился, хоть я и не узнал ничего нового для себя. И я ожидал практические кейсы, best practices, которые улучшат код. Но доклад оказался больше философско-теоретическим. Суть доклада в том, что современные фреймворки облегчают разработчикам задачу писать
Посмотрел недавно доклад, который называется "Добровольно принудительный Spring". Доклад мне в целом понравился, хоть я и не узнал ничего нового для себя. И я ожидал практические кейсы, best practices, которые улучшат код. Но доклад оказался больше философско-теоретическим.
Суть доклада в том, что современные фреймворки облегчают разработчикам задачу писать некачественный код, нарушая S.O.L.I.D. Как пример, Lombok+Spring, когда вы ставите аннотацию @RequiredArgsConstructor над классом, который принимает 20 параметров в конструкторе, а спринг сам за вас создаст и внедрит эти 20 классов. Так как все это легко просто и много кода не занимает, то в голове у разработчика может и не екнуть, что он делает что-то не так, и зачем ему столько параметров в конструкторе.
Забавный вывод, что мы не далеко ушли от Pascal. В паскале тоже были модули/зависимости. В паскале функции/процедуры, а наш типичный код сейчас это бин, который по факту является мешком функций. То есть никакого ООП по факту нет. Ну и единственное что у нас появилось, в отличие от паскаля, это модульные тесты, а значит нам нужно изо всех сил стараться использовать это, и облегчить себе тесты, а значит:
Спорные утверждения конечно, но что имеем.
В итоге все свелось к тому, что разрабатывать нужно через DDT. Даже дебагер не нужно использовать, потому что его вам заменят тесты.
Мне притно, что начали появляться докладчики, которые признают, что никакого ООП у нас по факту нет, оно возможно есть только в головах у интервьюерах на собеседованиях. Собственно то что проповедует Егор Бугаенко по факту правда.
Только вот подход Егора в том, что надо пытаться учиться писать в стиле ООП, а посыл этого доклада в том, что надо смириться и просто жить с этим, потому что настоящих ООП проектов никто в глаза не видел.
Для меня ближе второй вариант, эволюция она такая, бессердечная.
