Niebezpieczna abstrakcja

Witajcie.
Nie pracuję jako programista, ale uważam się za domorosłego Java dev.
Jednak ostatnio zacząłem się niepokoić i w związku z tym chciałbym zasięgnąć waszych rad.
Na rozmowie kwalifikacyjnej (kilka miechów temu, zanim zrezygnowałem z pracy jako programista) zostałem odpytywany ze Springa ogólnie. Jakieś proste rzeczy o persystencji i wstrzykiwaniu zależności.

Uczyłem się kiedyś Springa konfigurując każdego Beana oddzielnie, krok po kroczku. Potem przeskoczyłem na Spring Boota.

Moje pytanie wynika z tego, że nie wiem jak wygląda praca w prawdziwym projekcie.
Jak to jest z tymi warstwami abstrakcji?
Po co mi znać np. Hibernate?

Encję piszę 5 minut, repozytorium 1 minutę. I tak się zastanawiam po co Hibernate skoro mamy wysoki poziom abstrakcji, który dostarcza Spring Data.
Nie wiem czy się zagolopowałem czy jest ok. Otóż od kilku miesięcy nie zastanawiam się nad irytującą konfiguracją beanów itd. tylko lecę z automatu za pomocą Spring Data.
Czy to jest błąd? Czy powinienem się zagłębiać w to co jest pod spodem?

Druga sprawa np. kontener serwletów. Spring Boot automatycznie nam podkłada Tomcata. I wychodzi na to, że nawet nie muszę wiedzieć, że coś takiego istnieje... Bo to sobie działa i już.

Co o tym sądzicie?
Czy myśląc o przyszłej pracy powinienem rozkładać swoje projekty na czynniki pierwsze i odrzucać abstrakcje?
Czy stosować abstrakcje dopiero po zrozumieniu jak działają podstawy?

Hej!

To zależy od tego jak taka abstrakcja jest zrobiona.
Dobrze zrobiona, to taka, o ktróej tajnikach/szczególach implementacyjnych nie muszisz wiedzieć. W takie się nie zagłębiamy, jeśli tylko robią to co potrzebujemy.

Niestety mało który framework zalicza siedo tej kategorii. Praktycznie wszystkie są cieknące.

Konkretnie w JPA/Hibernate mało kto wie jak działa dirty checking oraz detached i managed entity. Błędy typ unititialized collection itp. to jeszcze pikuś, ale zdażają się po prostu zniknięcia obiektów z bazy danych, czyszczenie kolumn (jakis czas temu jeden znajomy zespół programitów szukał przyczyny takiego znikania przez kilka(!) miesięcy, sam też patrzyłem na ten kod killka godzin i nic nie widziałem - nie było trywialnej przyczyny... ).

W Springu problemem jest cieknace dynamic proxy i thread local. Przesławne wywołanie :this.methodWithAnnotation(...) jest chyba najlepszym przykładem. Tak samo wywołanie niektórych (wiedz teraz któych) metod z innego wątku w jakimś Executorze.

Jak się nie zna działania tych mechanizmów to często zespół dochodzi do ściany - okazue się nagle, że na miesiąc przed deadline wszystko się sypie i nie wiadomo jak naprawić, albo co gorsza znajduje się przyczynę błędu, ale okazuje się, że trzeba przepisac pół systemu, bo wszystko robiliśmy źle. (Mój ulubiony przypadek to używanie beanów session scoped/request scoped - masakra) .

Najgorsze, że większość programistów tego nie zna i niestety sie zagrzebują. Ogólnie wszelkie frameworki, w których kod w testach daje zupełnie inne wyniki niż na produkcji są dla mnie na czarnej liście i podlegaja dyskwalifikacji, jeśli chodzi o zastosowania w projektach zespołowych. To dotyczy właśnie JPA i klasycznego, beanowego Springa. Chociaż są one niezłe do szybkiego prototypowania, jak PHP :-).

Przy okazji Spring i JPA nie sa najgoszymi masakrami - taki JSF to był dopiero framework koszmar. Nie widziałem jednego projektu, żeby nie było w co drugim beanie jakiejś totalnej zwałki, bo programisci nie wiedzą jak to działa. (Ale jak się robi framwork oderwany od rzeczywistości i zupełnie sprzeczny z intuicją, to tak wychodzi).

Co gorsza nawet te frameworki, które polecam jak Ratpack, Spring WebFlux czy JOOQ też nie są idealne. Też im różne rzeczy wyciekają, tylko jest tego trochę mniej i być może można nie wiedzieć jak działają. To jest tylko hipoteza - zobaczymy jak więcej niedzielnych reactive programistów sie do tego dobierze, może być śmiesznie.

@jarekr000000: dowaliłeś mi taki elaborat, że masakra. Dzięki :)
W sumie nie mój poziom te rozkminy, jeszcze dużo wody w rzece upłynie zanim do tego dojdę tym bardziej, że właśnie ja olewam w swoich projektach konfigurację, dodaję trochę propertisów do application.properties i to na użytek takich prostych RESTów wystarcza. poza tym jeśli jakieś błędy tego typu jak opisałeś wystąpią, to nawet nie mam tego świadomości, bo te moje aplikacje nie mają żadnego znaczenia dla biznesu i że 1000000onowa encja wyparuje to nawet tego nie zauważę.
W sumie to dałeś mi do myślenia, że nie wiele jeszcze wiem o wnętrznościach tych frameworków.

Dzięki za wypowiedź. Chyba czas się wszystkiemu przyjrzeć bliżej niż tylko @SpringBootApplication :D