Kiedy skończyć z chodzeniem na randki z bibliotekami i zawrzeć małżeństwo z frameworkiem?

W obecnej chwili trochę kończą mi się opcje nauki rzeczy technologicznie niezależnych.
Opanowałem w miarę bazy danych, algorytmy, architekturę oprogramowania i teraz testy.
Staram się uczyć jeszcze o pisaniu obiektowo w Pythonie. Tutaj jest to trudne i wymaga po prostu doświadczenia.

Czy to już moment na naukę frameworka typu Dajngo lub rozwinięcie się w uczeniu frameworków typu Spring/Jakarta EE (Python chyba nie bardzo się nadaje do pisania aplikacji)?

Kiedy przychodzi ten moment że programista chce wejść w związek małżeński z biblioteką?
Przecież nie można cały czas chodzić na randki bo bibliotekę można wymienić a framework już niekoniecznie.

Do tego władza jak w małżeństwie i na randkach:
Ty wywołujesz bibliotekę - czyli to Ty chcesz się spotkać na randkę
To Ciebie wywołuje framework - czyli żona decyduje gdzie jedziecie na wakacje.

Marcin Marcin napisał(a):

Przecież nie można cały czas chodzić na randki bo bibliotekę można wymienić a framework już niekoniecznie.

Wszystko zależy od tego, jak tego używasz, a nie jak to jest nazwane :P

Możesz napisać aplikację tak, że framework będzie tylko luźno powiązany z corową częścią aplikacji, a możesz tak, że absolutnie z każdego zaułka łypią na Ciebie zależności do frameworka. Czasami mniej lub bardziej osobliwe.

Z bibliotekami tak samo - zależy do czego są i jak ich używasz. Zmiana biblioteki może oznaczać 2/3 aplikacji do przeróbki, jeśli się do niej wcześniej przyspawałeś.

Do tego władza jak w małżeństwie i na randkach:
Ty wywołujesz bibliotekę - czyli to Ty chcesz się spotkać na randkę
To Ciebie wywołuje framework - czyli żona decyduje gdzie jedziecie na wakacje.

Dlatego jak ciskasz wywołaniami na prawo i lewo, to i tak nie zmienisz łatwo biblioteki na inną.

Z frameworkiem to samo - jak dasz frameworkowi sterować absolutnie każdym szczegółem tego, jak aplikacja jest składana do kupy i uruchamiana, no to jasne że nie będziesz mógł go łatwo wymienić. Natomiast jak ograniczysz jego użycie do ściśle określonych miejsc (te słynne hexy, porty i adaptery, clean architecture czy jak to zwał) to masz nad tym jakąś kontrolę.

Przykład:
Kiedy używać Dajngo a kiedy Flaska lub kiedy żadnego z nich i korzystać z biblioteki?

Kiedy używać czystej Javy a kiedy Jakarty EE lub Springa?

Chyba najlepiej zacząć kiedy chcesz. Też miewam różne dylematy, lecz w kwestii frameworków po prostu używam i nie zastanawiam się czy "to już ten czas". Miałem zrobić tutorialowe API w Expressie nie znając JS to zapoznałem się z podstawowymi konstrukcjami języka i później od razu ruszyłem na Expressa. Przyszła kolej na użycie Pythona (znałem trochę składni) to wziąłem Flaska i napisałem. Aktualnie współpracuję z C# i tutaj do APIs, microservices, webservices (jak zwał tak zwał) mamy ASP.NET. Piszę i tyle. Brzydki i tutorialowy kod, ale jest. Nie wiem czy nauka miałaby polegać na tym, że najpierw przerabia się miliardy problemów za pomocą samego języka z biblioteką standardową...

Marcin Marcin napisał(a):

Kiedy używać czystej Javy a kiedy Jakarty EE lub Springa?

Ale co to jest według Ciebie "czysta" Java, lub czysty język X? Bez frameworków? Bez bibliotek? Bez "magii" tzn. spinania aplikacji z frameworkiem przez różne dziwactwa pokroju skanowania classpath, orania reflekcjami, dynamic proxy, AOP?

Jak chcesz pisać w oparciu wyłącznie o bibliotekę standardową tzn. bez zewnętrznych zależności, to proszę bardzo, tylko nie wiem co to ma do tematu biblioteki vs frameworki. Tyle tylko, że jedne i drugie dostarczają abstrakcji na to, co oferuje "czysty" język. Ewentualnie abstrakcje na abstrakcje itd. W dodatku są reużywalne (dlatego ktoś zrobił z nich biblioteki). Czemu chcesz z tego całkowicie rezygnować?

Pierwsza minuta-dwie:

Masz kilka różnych kawałków softu, sklejasz je do kupy i masz większy kawałek softu. Potem z takich większych kawałków ktoś skleja jeszcze większe klocki i tak dalej aż do kompletnych aplikacji. Jasne, możesz to odrzucić i pisać od zera, ale tym samym chcąc zbudować aplikację musisz stworzyć cały ten stosik samemu.

@Marcin Marcin:

Ok wyobraź sobie @superdurszlak że jesteś małym durszlaczkiem i masz sobie sprzed kilku lat wyjaśnić kiedy mały durszlaczek ma używać biblioteki a kiedy frameworka. Jak to zrobisz?

Mały durszlaczek prędzej upierałby się przy tym, że w danej sytuacji trzeba używać biblioteki albo frameworka.

Przecież to zależy, jakimi kryteriami się kierujesz, a nie wskazałeś żadnych - poza "wiązaniem się" z jednym lub drugim, do czego już się odniosłem.

Nie chcesz się uwiązać na stałe z jakąś zależnością? Używaj jej w taki sposób, by po ewentualnej wymianie do przepisania był fragment aplikacji, a nie całość.

Chcesz używać, żeby się nauczyć i mieć potem pracę? Patrz na ogłoszenia i używaj tego, czego firmy używają. Nawet, jeśli to głupie i niewygodne, to przynajmniej za to zapłacą.

Chcesz dla zabawy napisać sobie od zera serwer HTTP i na nim hostować stronkę? A proszę bardzo, możesz nawet w czystej Javie, nawet pisząc na pętlach, wątkach i socketach.

Nie chcesz oddawać się magii frameworka i tracić kontroli nad tym, jak całość aplikacji jest składana do kupy, jak działa routing itd? No to użyj jakichś bibliotek które tego nie wymagają.

Jesteś leniwy i wolisz posklejać wszystko frameworkową magią, bo tak jest szybciej? To tak zrób. Patrz punkt o używaniu tego, czego używają firmy.

To brzmi jak doświadczony durszlak :P

Etap fascynacji frameworkami to naturalny moment rozwoju programisty, jak pryszcze u nastolatka. Na razie weź jakikolwiek, który akurat jest popularny w twoim wybranym języku i zacznij go wszędzie używać. Dostałeś piękny młotek, świat jest pełen gwoździ...! Jak cię zaś jego niedoróbki, ograniczenia i udziwnienia zaczną wystarczająco wnerwiać to znak, że dorastasz.

Narzędzia dobiera się do problemu. Nie ma prostej odpowiedzi kiedy użyć X a kiedy Y. Jak potrzebujesz wystawić prosty restowy endpoint który pozwala zawołać jakąś złożoną logikę obliczeniową, to pewnie nie ma sensu brać do tego Django, bo można to samo osiągnąć 2 linijkami z flaskiem czy fastapi. Analogicznie jak potrzebujesz zrobić sporą aplikacje, która ma np. pozwalać na auth 17 różnymi metodami to pewnie wygodnie wziąć Springa bo "samo się zrobi", niż próbować to ręcznie ogarnać z jakimś RatPackiem.

Zależy jaki masz cel. Jak chcesz zrobić aplikację, to dobierasz narzędzia, które się do tego najbardziej nadają i które już znasz / masz możliwość szybko poznać. Jeżeli się uczysz to już w innym wątku pisałem - mam złe doświadczenia z ludźmi "programista [dowolny framework]". To mój bardzo subiektywny punkt widzenia, po prostu fascynuje mnie jak ludzie z doświadczeniem w jakimś frameworku, wywalają się na zadaniach przez brak wiedzy jak ten framework działa, albo szukają przez tydzień "jak to zrobić w [dowolny framework]" zamiast siąść i w 2 godziny napisać przy użyciu podstawowych funkcji języka. Przykłady to np. brak umiejętności podłączenia się do kolejki bo "w Springu to nie działa", albo ciągnące się w nieskończoność zadanie, bo ktoś próbuje skonfigurować ORM'a zamiast napisać pojedyncze, banalne zapytanie SQL.
Żeby uniknąć niepotrzebnej dyskusji, uważam frameworki za przydatne narzędzia, czasami nadużywane, ale trudno, mogę z tym żyć. Mam za to problem z ludźmi korzystającymi z tych narzędzi, a nie mającymi pojęcia jak one działają.
Bardziej specyficzna propozycja dla ciebie - ucz się podstaw języka, popularnych bibliotek, jak uznasz, że znasz podstawy, to napisz prosty projekt we frameworku, który chcesz poznać, poznaj jego podstawy (czyli 90% tego co potrzeba). Doczytaj skrót reszty (np. spis treści z dokumentacji), żeby w razie potrzeby wiedzieć, że jakiś tam framework ma w sobie narzędzia do łączenia z bazą danych, czy IAM. Jak będziesz potrzebować, to się nauczysz. Ważne, żeby wiedzieć jaka jest architektura narzędzia, co ono oferuje, mieć swoją opinię jak wygodnie ci się z niego korzysta.

@piotrpo: uczę się pythona, dobrym pomysłem jest przeczytanie jego dokumentacji zamiast uczenia się z kursów/książek?

@Marcin Marcin: Pythona ucz się jak chcesz (polecam książki). Frameworków moim zdaniem tak jak pisałem - wymyślasz sobie prosty projekt, robisz go przy użyciu jakiegoś Django, czy co tam macie. Poznasz 90% tego co jest wykorzystywane w trakcie normalnej pracy. Doczytaj co jeszcze jest we frameworku. Bez zakuwania, po prostu wiedz do czego możesz go użyć. Jak chcesz, to pobaw się dalej ciekawszymi rzeczami, jak nie chcesz, to zaczekaj aż ktoś ci zapłaci za takie eksperymenty.

Polecasz jakąś konkretną książkę na poziomie zaawansowanym/eksperckim?
Co do frameworków nie chcę zaczynać nie znając biegle języka.
Najpierw programowanie obiektowe, czytelny kod, testy i CI/CD w modułowym monolicie :)

Marcin Marcin napisał(a):

Polecasz jakąś konkretną książkę na poziomie zaawansowanym/eksperckim?

Ramalho oraz Beazley-Jones.

Ja podchodzę do tego inaczej:
Zobacz na oferty pracy. Jeśli X jest popularne w nich dla Twojego języka (i tego co chcesz z nim robić, np w web pewnie inne rzeczy są popularne/potrzebne niż w Data Science) to ucz się X. Nie ważne czy to framework czy biblioteka. Jak biblioteka i w następnej pracy zamiast X będą używać Y, to pewnie i tak będzie warto znać koncepty dlaczego się tego używa a i użycie może być podobne. Np jeśli piszesz standardowe testy jednostkowe i masz do wyboru 3 różne biblioteki, to ich użycie będzie w standardowych przypadkach w 90-99% takie same, z różnicą słów kluczowych.

I nie skupiaj się czy X to framework czy biblioteka, ale czy powinieneś to znać/umieć używać czy nie. I czy to daje Ci coś nowego. Np jeśli teraz umiem tworzyć aplikacje desktopowe, a chcę się przenieść na web, to czego się do tego używa w moim języku? Albo jeśli dziś nie piszę testów to czego się do tego używa? Zauważ że w takim podejściu uczysz się nie jako na dwóch płaszczyznach. Z jednej strony uczysz się wykorzystywać narzędzie, z drugiej uczysz się robić coś nowego do czego tego narzędzia używasz.

@Shalom:

Analogicznie jak potrzebujesz zrobić sporą aplikacje, która ma np. pozwalać na auth 17 różnymi metodami to pewnie wygodnie wziąć Springa bo "samo się zrobi", niż próbować to ręcznie ogarnać z jakimś RatPackiem.

Piekny przykład - niedawno miałem zrobić security oparte o uwierzytelnianie w zewnętrznych Oauth2, ale w oparciu o wystawiany potem specyficzny JWT token, który nie byłby bezpośrednio tokenem z Oauth2. (mamy kilku dostawców, po uwierzytelnieniu chcemy jeden specyficzny dla aplikacji JWT token).
Czyli po dostaniu code od Oauth2 dostawcy, sprawdzamy co za gość dostając przy tym JWT i na tej podstawie tworzymy nasz własny.
Ręcznie napisanie tego zajęło tak~16 godzin (na ktor) - zaskoczyło mnie ile to trwało (dłużej niż myślałem).
W Springu do dziś nie jest gotowe - kolejne zwały wychodziły (łącznie z tym, że akurat specyficzny komponent do Azure ma dupie, że chcemy JWT token i i tak na siłę tworzy sesje). (To się udało obejść wywalając wsparcie springowe do Azure i korzystając z generycznego oauth2).
W końcu coś wyszło - Hacki, na hackach na hackach. Stwierdziłem, że ja takiego security to nie puszcze na produkcje, bo bardziej to lepiankę przypomina. Bardzo prawdopodobne, że czegoś nie znalazłem, nie doczytałem. Problem taki, że na samo czytanie poświęciłem istotnie więcej czasu niż na gołą implementację bez springa.