Wymasterować framework

Wymasterować framework tzn że znasz na pamięć praktycznie 100% możliwości cora lub potrafisz na tyle szybko zagłębiać się w kod cora że jak nie wiesz czegoś to się dowiadujesz bez grzebania w googlu :) Tak Przynajmniej robią seniorzy laravela których znam. Zamiast szukać w googlu to w pare sekund przeszukają klasy frameworka i już wszystko wiedzą :)

No to długa droga przede mną, bo ja muszę czasami sprawdzać dokumentację lub szukać na stacku :D Z drugiej strony wydaje mi się, że takie wymasterowanie to tylko i wyłącznie idzie wraz z pracą i projektami, bo co projekt to jakieś nowe rzeczy i nowe rozwiązania, a na pamięć to można się uczyć wierszyka w szkole.

Na podobnej zasadzie będę miał egzamin na cert linuxa, możesz korzystać z man w linux, ale nie masz prawa korzystać z przeglądarki :D

W mojej opinii nie warto się uczyć na zapas, nie warto się uczyć dok. na pamięć, tutaj bardziej chodzi o optymalne Know-how i tyle.

Ja na początku uczyłem się komend linux na pamięć, niestety z braku ich używania w mig je zapominałem. Od jakiegoś czasu codziennie sobie klepie w konsoli robiąc różne rzeczy i efekt jest bardzo dobry bo z jak coś trzeba zrobić to polecenia lecą z automatu. Tzn robię całkowity format serwera i stawiam sobie dla treningu na serwerze apache/nginx, mysql, php, dns, postfix/dovecot. ssh, ftp, robię macierz raid + podstawowe zabezpieczenie, taka zabawa na 2-3h ale ilość komend które się kodują w głowie spora. Podobnie może być tutaj, że jak coś często robisz i używasz to z automatu będzie się to pisało.

A laravel to dla przyjemności? Zahacz jeszcze o wordpress :D będziesz najlepszym gościem od wszystkiego za marne grosze w januszsoft :D

Obecnie pracuję jako backend developer w symfony i nie narzekam na to ile zarabiam :) Nie mam zamiaru brać się za Wordpress itp cuda, niestety zbyt bardzo to haczy o front, na myśl o którym dostaję gorączki i całkowity bezdech :D Jeszcze nie zdarzyło mi się, abym musiał cokolwiek pisać w larvie, stąd zastanawiam się w ogóle czy jest sens do niego siadać.

W moim przypadku w pracy symfony + env na linux i nie muszę nikogo prosić o doinstalowanie czegokolwiek na serwerze.

Zastanawia mnie jedna rzecz, co to znaczy wymasterować jakiś framework?

Frameworki są przeznaczone do pracy nad szablonowymi projektami, ale..

Rzeczywistość jest taka, że nie wszystko co robisz będzie szablonowe. Zwykle wraz z większą liczbą użytkowników rosną wymagania i docelowy framework może okazać się, że będzie coraz bardziej ograniczający. Wtedy masz do wyboru przejście na nowy stack albo wycisnąć z frameworka tyle ile się da lub jeszcze więcej. Taka praca skutkuje wymianą części mechanizmów jakie stoją u podstaw wybranego frameworka, by te nowe lepiej zazebiały się z konkretnymi wymaganiami wybranego projektu.

Rozjazd też następuje gdy w firmie masz jakąś starszą wersję frameworka, gdzie migracja do nowej wersji z punktu widzenia kasy byłaby błędem. Dlatego wtedy potrzebny jest odrobinkę większy skill, ponieważ część funkcjonalności jaką znasz z dokumentacji może być niedostępna w pracy, trzeba będzie przyzwyczaić się do innych rzeczy i w razie potrzeb odpowiednik tego czego potrzebujesz.

Czy według Was warto iść w różne technologie, czy lepiej trzymać się jednej?

Możesz być magikem od konkretnej technologii, taka osoba zarabia potencjalnie lepszy hajs i łatwiej może się wypromować jako specjalista. Nie mniej nie jest to lekka praca i generalnie im lepszy jesteś tym gorsze rzeczy w życiu zobaczysz. (PS, ja tak nie robię mam za słabe nerwy).

Znajomość wielu różnych technologii prawdopodobnie da Ci więcej benefitów, gdybyś chciał tworzyć różne rzeczy o zróżnicowanych potrzebach. Tu Cię zmartwię, taka rzecz prawdpodobnie będzie możliwa w przypadku własnej firmy (to moja ścieżka). Programista taki "spec od wszystkiego" raczej cieżej będzie miał w zbudowaniu zarąbistego zaufania i dobrej marki (chyba, że aspirujesz do firm typu januszsoft albo gdy masz spoko produkty - ale wtedy po co Ci etat?). W każdym razie mnogość technologii bardziej przeszkadza w robieniu kariery, możliwe że taka rzecz pozwoli Ci tak jak mówiłem rozkręcić coś własego.

I teraz ciekwszy motów odnośnie kariery, możesz być ekpert w ramach konkretnej technologii, ale swoją wartość możesz lepiej podbić jeśli będziesz specem z konkretnej branży np. finansów, wtedy gościu co zna kilka frameworków Ci nie podskoczy, bo on i tak nie ogarnie potrzeb klienta tak szybko jak Ty.

W kwestii własnej działalności to pracuję na B2B, gdzie na full time pracuję jako backend developer, a dodatkowo ogarniam serwery linux dla innych firm. Przyznam szczerze, że już raz próbowałem zmienić PHP na C#, niestety mimo wszystko cały czas, gdzieś mi tam tego PHP brakowało i było szkoda ponad 5 lat jako PHP Dev, żeby siadać do czegoś nowego.

Pomimo działalności, nie tworzę własnych produktów, chociaż wydaje mi się to strzałem w kolano, bo jednak stały dopływ gotówki jest z b2b, więc o to nie trzeba się martwić i jest czas na własny produkt, tylko w moim wypadku ciężko z pomysłem na produkt :D Z drugiej strony jak mam zrobić byle jaką aplikację, to lepiej nie robić wcale :D

Czy według Was warto iść w różne technologie, czy lepiej trzymać się jednej?

Czemu to ma być albo-albo?

Ja powiem tak:

Warto poznać jakąś konkretną (albo kilka konkretnych) technologii mocniej, żeby móc się w niej poruszać jak ryba w wodzie (to jednak nie znaczy, że trzeba być w niej mistrzem, bo nim i tak nie będziesz, chyba, że jesteś choćby współtwórcą danej technologii i znasz ją od środka).

Ale warto też poznawać różne technologie. Bo to rozwija i łatwiej będziesz mógł wejść w różnego rodzaju projekty, czyli elastyczność. Poza tym znając wiele technologii, można dokonywać bardziej świadomych wyborów programistycznych, jak się widzi zalety i wady każdej z nich, czy jak się poznało różne sposoby rozwiązania tych samych problemów, w zależności od technologii.

No i poznając różne rzeczy, zabezpieczasz się też na okoliczność, że dana technologia wyjdzie z mody albo stanie się mniej opłacalna. Albo po prostu może ci się klepanie w technologii X znudzić. Tym sposobem znając podstawy kilku innych technologii, łatwo możesz "przeskoczyć" na inną.

Ale przede wszystkim warto umieć rozwiązywać konkretne problemy niezależnie od technologii. Lepiej się uczyć praktycznego know how (mając dany problem, odwołam się do swoich poprzednich doświadczeń i zrobię to w sposób X, tak jak zrobiłem to dwa lata temu. Co prawda wtedy używałem innego frameworka, ale przecież know how pozostało mi w głowie), niż wiedzieć, że w wersji 1.238 frameworka metoda się nazywała fooBar a w wersji 1.3 to zmienili i trzeba wywołać fooBazQwerty.

W kwestii własnej działalności to pracuję na B2B, gdzie na full time pracuję jako backend developer, a dodatkowo ogarniam serwery linux dla innych firm. Przyznam szczerze, że już raz próbowałem zmienić PHP na C#, niestety mimo wszystko cały czas, gdzieś mi tam tego PHP brakowało i było szkoda ponad 5 lat jako PHP Dev, żeby siadać do czegoś nowego.

Ale to nie jest tak, że tracisz te 5 lat.

@semicolon: jeśli robisz projekt pokroju allegro to zrozumiem, oczywiście oni tez zaczynali od czegoś szablonowego. Natomiast jeśli to mniejsze rzeczy, to nie zrozumiem. - mr_jaro

**Przykład #1 - renerowanie
**
Jak renderujesz z frameworkiem? Ja znam tylko dwa sposoby. Pierwszy to wystawienie API i renderowaniem zajmuje się klient pisany w react, a drugi sposób to statyczne renderowanie po stronie frameworka z użyciem języka szablonów typu jinja2.

Najszybciej mi się pisze statyczne renderowanie po stronie serwera, bo taka rzecz jest od razu wbudowana w framework. Z drugiej strony czasem mam dynamiczne komponenty na stronie, które są wręcz potrzebne, muszą być interaktywne - i w ich przypadku jquery to za mało. Czy to oznacza, że przechodzisz od razu na wystawianie samego REST API? Cóż.. gdybym miał kasę i 2 zespoły to nie zastanawiałbym się i podzieliłbym to na front i backend.

Jednak w przypadku trochę mniejszych nakładów lepiej iść w kierunku hybrydy. Ja robię tak, że w 1 języku mam komponenty zarówno dynamiczne jak i te statyczne. Mogę je renderować z poziomu serwera i tak robię przez dłuższy czas, bo tak szybciej mi się koduje. Natomiast tam gdzie będzie dynamiczny stan po stronie użytkownika tam wpinam się i podpinam jakiś komponent (mogę podmienić cały widok, ale też mogę podmienić wybrany komponent), który powinien być dynamicznie obsługiwany.

Co jeśli będzie coraz więcej dynamicznych elemnetów - żaden problem, po prostu kod który był renderowany po stronie serwera, od razu mogę wykorzystać bez żadnych przeróbek po stronie frontu. Czy moje podejście jest nienormalne?

Ja chętnie używałbym django, ale ono w tym przypadku jest dobre, gdy zdecyduje na wystawianie API restowo. Nie mniej takie django nie da mi: współdzielenia tych samych funkcji po obu stronach, współdzielenia stałych - i musiałbym pewne rzeczy dwa razy pisać i oczywiście pamiętać, by zmieniać wartości po obu stronach jeśli zajdzie taka konieczność.

**Przykład #2 - baza
**
Frameworkowy ORM taki jaki jest w django, pozwala budować składać rozmaite querysety stosując fluent api, do tego ma świetnie wspieracie w przypadku migracji, ma kilka narzędzia związanye z importem/eksportem, no i też takie modele fajnie się spina w adminie. To super narzędzie - o ile robisz dwutygodniowy projekt, tak na szybko.

W innych przypadkach taki ORM wnosi na pokład straty. Jakie? Przede wszystkim zakłada Ci na oczy czarną szmatę przez którą patrzysz na bazę. Baza to nie jest OOP i te dwa tematy za bardzo nie współgrają.

W django obiekt modelu jednocześnie jest kolekcją reprezentującą całą tabele do której wrzucasz sobie zmiany. Niektórzy do tych modeli dopisują biznesową logikę, co w ogóle jest szalone, bo ten obiekt to wiele nie ma wspólnego z abstrakcją - co to za obiekt skoro wszystkie pola ma publiczne? 

Jak myślisz o klasach to masz też drugi problem, bo klasy w najprostszych przypadkach rzeczywiście mapują się 1 model na 1 tabelkę, ale z drugiej strony pisząc z ORM mało kto myśli o integralności. Mistrzowie ORM robią takie byty jak model, który ma pole w stylu kind, a ten kind opisuje rodzaj modelu, które obsługuje różne przypadki. Oczywiście część pół musi zostać nullable, by przeszło.

Natomiast taki ORM to nawet durnego złożonego PK pozwala zrobić, nie wspominając o tym, że upserty czy CTE to muszę na około kodować Czy mając ORM tracę? Pewnie TAAAAK, bo mam 70% zapytań, które mogę z zamkniętymi oczami napisać w surowym SQL, a te które najbardziej się dla mnie liczą piszę tak jakbym prezerwatywę nałożył sobie na głowę bo tak podobno jest bezpieczniej :D

**Przykład #3 - przepływ sterowania
**

Jak wczesnej mówiłem django jest dobre do wystawiania Restowego API. Co jeśli w projekcie pojawi się potrzeba posiadania websocketów? A no wtedy można użyć django-channels, pozwalają napisać synchroniczny kod który będzie czekał na asychroniczne zdarzenie. Inaczej mówiac piszesz blokujący kod do asynchronicznego przepływu, nie muszę tutaj tłumaczyć, że coś takiego rypnie przy większym obciążeniu, bo asynchroniczne workery same się zablokują.

Ty pewnie w PHP podzieliłbyś kod na dwie usługi. To co websocket ma robić wystawiasz w kierunku node, a resztę nadal kontynuujesz w php. Tyle, że takie rzeczy są bardziej problematyczne niż gdybyś wszystko robił w jednym języku, od teraz musisz kordynować projektem z perspektywy dwóch języków i do tego część robisz synchronicznie, a drugą część asynchronicznie.

A co zrobi taki PHP, gdy okaże się, że mieli dużo danych? Nawet jak masz node u boku to oba języki dany temat średnio wspierają. Node ułatwi Ci pukanie w API, PHP ułatwi Ci pobieranie danych z bazy, ale ogólnie kalkulacje, przetwarzanie xmli czy też kordynacją między bazą, a API od klienta zacznie Ci się powoli sypać, bo te języki nie zostały pomyślane do takich zadań. Przy większej współbieżności kod PHP wygląda tragicznie. W pythonie to nawet pamięciowo wygląda słabo, bo threading chodzi na jednym rdzeniu więc musisz mieć więcej procesów - co zjada dużo więcej pamięci niż gdybyś odpalił tłuściejszy jvm.

**Przykład #4 - złożona logika
**
Jak wygląda modelowanie logiki w takim PHP czy Pythonie? A no programiści idą w klasy, modelują sobie wymagania biznesowe, Ci lepsi to nawet SOLID stosują i też testy piszą, ale ostatecznie kod to mutowalne grafy, które zależą od baz, kolejek, api klienta. Wykonasz modyfikację w jednym miejscu, i nigdy nie wiesz czy to nie zacznie skutkować problemem w drugim miejscu. Czytając kod nie możesz się odciąć od reszty kodu, bo one ze sobą współgrają i są powiązane, a mało ostrożne zmiany będą skutkować kolejnymi problemami. Jeszcze gorzej jest gdy ciągniesz za sobą problemy z przykładów 2 i 3.

Problemy od 1 do 4 są stopniowym przejściem od najtańszej aplikacji w kierunku takiej, która będzie coś znaczyć. Jeśli framework to postawa to powinna z Ciebie zdjąć te 4 marginalne tematy, powinien dać Ci ramy, które pozwolą Ci pisać logikę. Natomiast Ty piszesz mi o jakiś jakiś core i pluginach, które rozsypią się przy ociupinkę większych wymaganiach niż miałeś na początku.

Oczywiście jeśli robisz dla kogoś projekty hurtowo to podejście frameworkowe jest spoko. Nie dość, że szybciej złapiesz więcej klientów, budujesz sobie reputacje, szybciej pokażesz im coś działającego. Natomiast jak klient wróci z większą liczbą nowych wymagań to już tym razem więcej zapłaci, bo dodawanie kolejnych rzeczy już nie będzie takie łatwe (właśnie czemu?). Nie tak jest?