Cześć, postanowiłem podzielić się z Wami moimi odczuciami na temat programowania webowego.

Zajmuję się tym od ponad 15-tu lat. I wiecie co? Od kilku lat wydaje mi się, że jestem w tym cienki. Kiedyś uwielbiałem rozgryzać problemy programistyczne, projektować rozwiązania i dbać o to, żeby mój projekt był jak najlepszy w odbiorze dla publiczności. Ale od kilku lat programowanie webowe to zalew technologii, zalew frameworków i bibliotek. Praca z projektem polega już nie na rozwiązywaniu problemów, tylko na znajomości tej czy innej paczki. I wiecie co? Nie chcę już ich znać.

Jestem zmęczony tą ciągłą gonitwą za zmianami i trendami. Mam dość tych wszystkich package managerów. Mam dość pytań: "czy pracował pan na XXX", gdzie XXX to nazwa jednego z tysiąca frameworków, CMS-ów i bibliotek.

Umiem Laravela na bardzo dobrym poziomie i wiecie co? Czuję się, jakbym nie umiał nic. Poza Laravelem umiem WordPressa, Vue.js, React JS i wiele różnych API i bibliotek. Ale i tak czuję, że robię to źle, bo przecież jest tysiąc różnych narzędzi i bibliotek, klienci co chwilę pytają o te, których nie znam.

Ja chcę tworzyć. Nie chcę bawić się w zlepianie kolejnych gotowych paczek. Dlaczego programowanie webowe nie wymaga już tyle logicznego myślenia, co kiedyś? Teraz wymaga to wiecznego researchu i pamiętania, czego do czego i z czym używać. A mnie się zwyczajnie już nie chce. Mam kiepską pamięć.

Człowiek chce mieć poczucie, że zbliża się do mistrzostwa. W programowaniu webowym to nigdy nie następuje. Zanim się ogarnie jedną technologię do dobrego poziomu, ta technologia staje się już albo przestarzała, albo niewystarczająca. To kołowrotek, a ja jestem chomiczkiem. Czuję, że za kilka lat zamienię dobre pieniądze z programowania na zajęcie, które daje więcej satysfakcji. Chcę być w czymś mistrzem. Tylko tyle i aż tyle.

Ja po napisaniu małego serwisu w Ruby on Rails i jakichś blogów i aplikacji w Django, wróciłem do PHP 7. Zniechęciło mnie kilka przykładów z tutoriala od Django, kody tam napisane po prostu nie chciały działać. Wydaje mi się, że PHP jest jak najbardziej stabilne, a trudno nadążyć za RoR, Django czy tymi nowinkami typu Elixir - Phoenix oraz Crystal. A na pewno za Node. Oracle też ostatnio przyspieszyło i Java wychodzi co kilka miesięcy, ciekawe jak jest z przejściami do kolejnych wersji takich kobył programistycznych jak Spring, przechodząc z Javy 8 do Javy 13. Niedawno już wyszła Java 13. Próbowałem Kotlina, ale jakieś to pokręcone, za dużo lukru i za dużo nowych funkcji. Dla nowych użytkowników to tylko więcej problemów na początku nauki. Na filmach devstyle, autor narzekał, że C# .NET jest coraz bardziej rozbudowane i coraz trudniej się nauczyć tej technologii i ją ogarnąć. Gdyby PHP miało wbudowany taki serwer Railsy czy Django, sporo by to ułatwiło, zamiast posiłkować się XAMPP, czy instalując wszystkie składniki serwera w swoim systemie.

PHP rzeczywiście ostatnio ma dobrą prasę i budzi optymizm, a jeszcze stosunkowo niedawno nic na to nie wskazywało. To również jest jedna z rzeczy, których nie lubię w web devie. Jesteśmy niewolnikami narzędzi, których los nie zależy od nas. Ktoś może poświęcić kilka lat na naukę narzędzia, które wkrótce po opanowaniu go odejdzie do lamusa. Czy wyobrażacie sobie to w innym zawodzie? Czasami zazdroszczę tym, którzy codziennie wstają z łóżka z pewnością, że ich dzień uczyni ich lepszym w ich ukochanej dziedzinie. My tego nie mamy. Ilość informacji, które codziennie przetwarzamy jest niezdrowa. A co więcej, nie wiadomo, czy w ogóle przydatna w dłuższym czasie.

A najlepsze jak klient każe wycenić projekt. Przecież w dzisiejszych czasach jest to niemożliwe. Skąd mam wiedzieć ile czasu zajmie mi używanie tuzina bibliotek, z którymi nie miałem do czynienia? Naprawdę mam ochotę się przerzucić na coś, co każe mi wyzwolić kreatywną moc mojego umysłu, a nie pamięciówkę i zgadywankę. Jestem zmęczony chomikowaniem w mojej głowie pudełek z półproduktami. Dzisiaj mogę powiedzieć, że naprawdę bardzo dobrze znam świat webu. Poświęciłem mnóstwo czasu, żeby pozwolić mojemu mózgowi zrozumieć jak działają podwaliny sieci, czyli HTTP, przeglądarki, serwery, bezpieczeństwo itd. Ta wiedza kiedyś była czymś wspaniałym. Dziś bez znajomości cudzych kobył w postaci narzędzi nie znaczymy nic.

@SmokAnalog z tego co widzę, to wypaliła Cię freelancerka. Ja jakiś czas temu również się wypaliłem, ale z trochę innego powodu. W powrocie pasji pomogła mi zmiana technologii po godzinach (C++). Dodatkowo, jeżeli chcesz stabilności technologicznej, to zachęcam Cię to zmiany kierunku na tworzenie aplikacji biznesowych. Ale nie takich, które załatwisz wordpressem czy paroma paczkami. Jest dużo pracy z dużymi systemami, gdzie klepie się backend (tak, jeszcze raz: klepie się, a nie instaluje tuziny paczek). Do tego zainteresuj się może architekturą aplikacji i DDD. To jest ciekawa porcja wiedzy, którą (jeżeli nie znasz) będziesz odkrywał i to na pewno da Ci sporo frajdy. Dodatkowo poczujesz stabilizację, bo ta wiedza jest "ponad" technologiami.

Wypalenie przychodzi w każdym zawodzie. Mnie także to spotyka. Że mimo że się dokształcam, to czuję że stoję w miejscu. Dlatego ja np. uczę się Pythona.

Dwa lata temu nauczyłem się Swifta i się zakochałem. Teraz na dokładkę Apple zaserwowało Swift UI, które wygląda obiecująco. Dla samej frajdy programowania poważnie rozważam przebranżowienie lub dobranżowienie się na Swifta. Wady tego wyboru są jednak oczywiste - Swift to tylko Apple.

Druga opcja, którą rozważam, to blockchain. Pociąga mnie budowanie rozwiązań o skomplikowanej strukturze, algorytmika. Ciekaw jestem na ile w świecie blockchaina również trzeba żonglować paczkami, jak w webie. Chciałbym po prostu robić coś, co nie wymaga nieustającego researchu „na zewnątrz”. Bardzo chętnie będę zgłębiał swoją dziedzinę do oporu, ale nauka paczek to niestety nie jest zgłębianie dziedziny, a przynajmniej nie w sensie, o jaki mi chodzi.

@mrc to są dobre rady i rzeczywiście nauka dobrych nawyków, wzorców itd. jest ponadczasowa. Uprawiam to odkąd pamiętam i może dlatego jeszcze nie oszalałem

Może to przez pogodę? Odpocznij, weź sobie urlop albo po prostu zwolnij tempo - przyjdzie jesień, zrobi się chłodniej, bardziej deszczowo to się milej będzie siedziało przy biurku

Obawiam się, że moje żale nie tyczą się wypalenia, ale natury web devu w tych czasach. Prawdą jest, że gdy ogarnie się porządnie jak to wszystko działa i dlaczego, to nauka każdej paczki jest znacznie łatwiejsza. Po prostu wtedy nie programujemy po omacku. Jednak brakuje mi wyzwań. Ilekroć mam studiować nową super cool paczkę, rzygam.

W ostatnim projekcie mamy mnóstwo paczek i fakt - nie mam pojęcia jak to działa, ciężko też analizować kod każdej paczki żeby się tego dowiedzieć tymbardziej, że co kilka dni wychodzi nowy update, a gdyby wziąć pod uwagę też paczki zależne, to pewnie co kilka godzin jest nowa wersja "kodu w całości".

Myślę, że musisz się skoncentrować na finalnej wartości, całości projektu który oddajesz klientowi bez wnikania w szczegóły (nie jest możliwe zrozumienie i poznanie całego kodu w tych czasach). Kodu "łączącego", zależności i narzędzi będzie coraz więcej, typowego prostego kodu coraz mniej - żeby ogarnąć tą całość rzeczy których nie jesteśmy w stanie ogarnąć "manualnie" (czy po npm install nasza aplikacja dalej działa, czy po zainstalowaniu narzędzia XY i dodaniu pluginu do webpacka wydajność aplikacji nie zmalała o 100% itp.) polecam testy unit i dużo testów e2e, wpięcie w CI narzędzi do badania wydajności, zarówno odpowiedzi serwera jak i budowania aplikacji w przeglądarce - mi to daje poczucie spokoju. Nie wiem jak to się odnosi do freelance, gdzie wszystko na szybko trzeba dowieźć - ja się staram pracować w zespołach które pracują nad jednym projektem przez długi czas, często kosztem pensji, ale zyskuje trochę więcej włosów na głowie

Zgodnie z tym co napisał @mrc są rzeczy ponadczasowe których warto się uczyć - sieci, same języki i to jak działają, języki obce, paradygmaty, wzorce, DDD itd.

To nie jest tylko problem web, wiem, że dev-ops ma podobnie i podejrzewam, że większość "odłamów programowania" ma z tym problem tj. narzędzia > kod. Tylko czy to faktycznie problem? Ludzie dążą do automatyzacji wszystkiego a narzędzia miały w tym pomagać i pewnie finalnie pomagają (przy okazji psując trochę krwi), wystarczy, że spróbujesz napisać sobie kolejną aplikację dla klienta bez użycia tych narzędzi i porównasz efekt końcowy.

Ze swojego doświadczenia powiem tak: jest webdev i webdev. Owszem, główny nurt związany jest najczęściej z pogonią za najnowszymi trendami i wykorzystywaniem akurat popularnego frameworka. Ale równocześnie istnieją też nisze (jak choćby tworzenie RTE), w których tej pogoni nie ma i tam wykorzystuje się sprawdzone od lat, stabilne technologie, a problemy rozwiązuje się po staremu, bo… nikt inny dotąd ich nie rozwiązał. Ot, po prostu wystarczy nieco zboczyć z głównej drogi i na zarośniętej krzewami ścieżce znaleźć nieco ukojenia

Na pewno masz rację, Comandeer. W moim przypadku też do pieca dowala to, że zdecydowałem się być senior full-stackiem freelancerem. To na mnie zwykle ciąży odpowiedzialność dobierania technologii do projektu no i oczywiście implementacja. Bardzo często też nie mam się z kim skonsultować, bo albo jestem jedynym devem w projekcie, albo pracujemy w różnych strefach czasowych. Kiedy mam z kim pogadać, od razu jest inaczej. A jak nie, to pytam oczywiście na Stack Overflow i forach, ale to nie to samo.

Mnie ostatnio zaciekawił Rust i Cargo. Język programowania do pisania systemów komputerowych RedoxOs, silników przeglądarek www, przeglądarek Firefox, Basilisk Browser(Goanna). Można też w nim pisać ciężki backend strony jako alternatywa Go, Swift czy Scala w mikroserwisach. https://rocket.rs

Drugi język programowania który mnie zaciekawił to Crystal, jest to lepsza, nowsza i szybsza wersja Ruby. Jest kompilowany, ma odśmiecanie pamięci, brak nulla i brak wskaźników, do tego jest prosty w nauce jak RoR. Posiada już kilka frameworków webowych. Czekam tylko jak to wszystko się ustabilizuje i wybije się jeden główny framework, jak Ror czy Django. Wtedy można w nim pisać wydajny sklep internetowy, czy porównywarkę produktów. Jest kompilowany, więc powinien być wydajniejszy nawet od Javy.
https://amberframework.org
http://kemalcr.com
https://luckyframework.org

Ja jestem full backend w PHP do tego czasami coś klepię w Javie 8 (mikroserwis w projekcie), do tego Python na potrzeby toolsa niższego poziomu. Dodatkowo Sysops/Devops. Nie nudzę się w pracy a wręcz brakuje mi czasu na realizację pomuysłów (wiadomo że sprint leci i trzeba zrobić plan)

Także kwestia znalezienia sobie czegoś co Cię kręci.

Pyton, może jak ktoś się nie brudzi frontendem to nie szaleje

A w Pythonie jest szansa, że nie trzeba się uczyć tych różnych frameworków, Django, Angular, React, PostgreSQL i być fullstackiem? To niby taki język klejowy, ale czy jest lepiej w tym natłoku technologii jak w Javie i JavaScript? Raczej jedynie C/C++ nie wymaga żadnego frameworka, piszesz jakiś kod w czystym języku do mikrokontrolerów, gry, sterowniki.

Gry bez frameworków, ciężko to widzę, no chyba, że masz kilkaset programistów albo robisz tetrisa

Sądziłem, że używają tylko jakiegoś silnika graficznego napisanego w C++, ewentualnie te duże produkcje jakiegoś Pythona Lua jeszcze do oskryptowania. Raczej ci chodzi o lekkie gierki czy przeglądarkowe i takie silniki jak rubygame i godot?
https://godotengine.org
http://rubygame.org
Popatrz na grę Dzieje Khorins, jest czysty Python i C++.
https://www.youtube.com/watch?v=-EFYQ4ZN5Ss

I dlatego szukają programisty od języka skryptowego silnika Gothica

Żadna praca nie da ci tyle satysfakcji i spełnienia jak praca dla siebie. rób coś po za pracą, jakiś swój własny komercyjny projekt... Ja stety czy niestety już o 6 lat ogarniam zupełnie inną branże - własny biznes, programuje tylko dla przyjemności. Web to nadal mój as w rękawie, programuje co się da : ) W ten oto sposób stałem się 100% autorem systemu do sterowania automatyką grzewczą kotłów na pellet, który działa na całym świecie i ma obecnie ponad 10k kotłów online i ciągle rośnie (kwestia dystrybucji niezależnej ode mnie)- z czego garnę profity za abonamenty. Buduje teraz dom, oprogramuje co się da, mam zajawkę i dobrze się przy tym bawie. W swoim czasie nawet tworzyłem z szwagrem grę na unrealu ale odpuściłem bo to robota głupiego w 2 osoby, w każdym razie jak robi się to dla siebie i na własną korzyść, satysfakcji multum niezależnie w czym się klepie. Mimo iż mógłbym teraz "pisać" u kogoś kod za niezłą kasę - śmieją się ze mnie że tego nie robię zawodowo, to jednak szkoda mi czasu. Na swoim to na swoim.

Trafiłem na taki wykres, ankietę dotyczącą PHP i uważam, że sporo zaniżyli udział Sublime Text dając im tylko 7%. Sam używam Sublime Text 3 do PHP. W komercyjnych projektach zawsze używacie płatnego PHPStorm, czy Eclipse, NetBeans, Aptana, Atom też się pojawia?
https://www.jetbrains.com/lp/devecosystem-2019/php/

A możesz nie zasyfiać mojego tematu takimi pytaniami?

Jesteś zwykłym chamem i prostakiem z głupim avatarem i tyle w temacie.

Po naszych pizzowych rozmowach wydaje mi się, że dobija Cię typ pracy jaki wykonujesz. Freelance ma swoje zalety, ale niestety w większości robisz tam proste i powtarzalne projekty. Pracując w firmie masz kilka pozytywów:
- kontakty społeczne
- wymiana doświadczeń / możliwość pracy z lepszymi od siebie
- większe projekty, gdzie potrzeba wielu kompetencji z różnych dziedzin

Mam porównanie z pracą na freelansie i pracą z większymi projektami. Jednym z głównych elementów, które spowodowały, że chciałem iść do pracy w firmie była świadomość, że utknąłem w rozwoju - ciągle powtarzałem swoje błędy, nie miałem wizji rozwoju, przytłaczała mnie ilość rzeczy do nauczenia i żadnej nie mogłem poświęcić tyle czasu ile bym chciał.

Teraz mam swój backend, w nim się bawię w architekturę, poznawanie PHP itd i tego oczekuje się ode mnie w pracy. A w wolnych chwilach hobbystycznie bawię się nowymi zabawkami - np. obecnie Reactem a w planach już jest Jenkins, DDD i inne rzeczy. Ale to robię dla siebie, żeby mieć większy obraz całości. Ogólnie teraz mam trochę jak Pyton, że w głowie pełno pomysłów tylko czasu brakuje.
Na freelansie faktycznie zawsze jest pogoń bo musisz wiedzieć wszystko i w niczym nie możesz przez to się wyspecjalizować. Ciągle tylko lepisz gotowce bo klient już stoi ze stoperem, a zamiast programować szukasz w Google jak w tej konkretnej bibliotece obsłużyć jakiś edgecase.

Ogólnie mam wrażenie, że bycie fullstackiem w dzisiejszych czasach to droga do nikąd. Technologii jest tyle, że życia nie starczy aby je opanować. Można być fullstackiem hobbystycznie - założyć sobie, że backend robisz w technologii X, frontend w Y i w tym się rozwijać, ale komercyjnie trudno jest skakać pomiędy vue, reactem, angularem, wszelkimi dialektami javascriptu i jednocześnie nadążać za zmianami w backendzie.

Czasami czytam sobie ogłoszenia dla backendowców i mam wrażenie, że nie znam często połowy technologii z ogłoszenia. Rozmawiam z kolegami seniorami i mają podobnie. W ogłoszeniach często są jednocześnie 3 wiodące frameworki, kilka baz noSQL, kolejki, systemy CD/CI, kilka rozwiązań typu WP/Magento itd. Trudno ZNAĆ te rzeczy jednocześnie, ja z wieloma miałem do czynienia, rozumiem ideę, kiedyś nawet użyłem w jakimś projekcie (i już często zapomniałem), ale trudno mi uczciwie powiedzieć, że znam technologię X.
Kluczem do szczęścia jest chyba aby trafić do pracy, gdzie masterujesz 2-4 rzeczy + masz styczność z wieloma innymi, w których masz ludzi, od których możesz się uczyć.

Powiedziałbym, że z tymi powtarzalnymi projektami jest dokładnie na odwrót. Freelancerka, a szczególnie małe projekty (bycie zaangażowanym do zrobienia czegoś, czego nie umie zrobić zespół klienta) to ciągle nowe zadania. W ostatnich projektach np. musiałem zrobić system do rejestrowania domen, a w innym postawić i dostosować system reklam google i facebooka. Na powtarzalność narzekałem w firmach, bo mieliśmy swój stack i po prostu robiliśmy wiele stosunkowo podobnych projektów.

Ja z bycia full stackiem nie zrezygnuję, bo dla mnie zarówno frontend i backend to światy, w których się duszę po kilku dniach. Oba lubię i lubię się przestawiać z jednego na drugi. Problem, o którym tu piszę dotyczy obu, choć oczywiście w znacznie większym stopniu dziś frontendu. Nie wydaje mi się, by bycie full stackiem coś tu zmieniało, bo na upierdliwość świata frontu narzeka dziś większość. Nawet nie chodzi tyle o poczucie przytłoczenia, co o nudny i upierdliwy proces tworzenia. Za dużo zapamiętywania, za mało myślenia logicznego.

Właśnie to jest problem, że duże firmy z góry narzucają pewne projekty, powtarzalne, a małych firm mimo że mają możliwość na większą politematyczność nie stać na lepszy zespół, albo tak jak moją firmę stać tylko na jednego programistę. Gdyby chcieli dwóch, to musiałbym się podzielić swoją wypłatą.

Dlatego mam trudny wybór, bo z jednej strony podobają mi się projekty firmy, a z drugiej brakuje towarzystwa, brakuje konsultacji, dyskusji nad problemami. Co za tym idzie, wydajność, szybkość wdrażania danego podprojektu spada.

Z drugiej strony, będąc w domu nie chce zbyt dużo czasu poświęcać na samodokształcanie, bo chciałbym ten czas poświęcać na inne moje sprawy. Chociaż bardzo lubię małe projekty od firm/osób z zewnątrz, które można stworzyć w jeden, dwa wieczory - przed spaniem.

@smokanalog - to mi się właśnie przejadła taka praca "wszystko po trochu". Skacząc z kwiatka na kwiatek miałem ciągle poczucie, że się nie rozwijam, tylko chaotycznie poznaje podstawy z różnych dziedzin. Gdy ostatnio rozmawialiśmy to miałem właśnie takie wrażenie, że Ciebie też to męczy. Oczywiście w takiej pracy są fajne rzeczy - np. konieczność poznawania różnych domen problemów biznesowych. Zawsze będzie coś za coś.

Na szczęście są jeszcze projekty prywatne ;-)

Najlepiej byłoby zorganizować grupę freelancerów i funkcjonować jak zespół Ja nie oddałbym wolności freelancerskiej już teraz, choć może zatrudnię się w jakiejś firmie na chwilę, żeby liznąć czegoś nowego.

Jak załatwisz ciekawe zlecenia to wchodzę w to ;-) Dla mnie jedyny poważny argument za freelansem to to, że można pracować dla zagranicznej firmy za znacznie lepszą kasę niż w PL. Trochę to załamujące jak moja firma bierze 150-200$ za godzinę, a ja nawet o takiej kwocie w złotówkach nie mogę pomarzyć ;-) Fajnie byłoby mieć projekty z USA i robić je w grupie na własny rachunek.

Ja bardzo źle znoszę rutynę, więc dla mnie argumentów przemawiających za freelance’owaniem jest znacznie więcej. Ale ogromnym, OGROMNYM minusem jest brak towarzystwa.

Zawsze można połączyć 2 światy - np. w firmie być osobą dochodzącą jak są zlecenia (lepsza stawka godzinowa przy okazji) + freelans. Póki dzieci nie ma można się bawić w takie rzeczy bo potem to już się najbardziej stabilizacja liczy i ta rutyna, której tak chcesz unikać.

Ja pracuje w firmie gdzie ludzie są, ale jestem jedynym programista, ostatnio poprosiłem w firmie o towarzystwo, bo nawet nie chodzi o to ze nie wyrabiam sięm ale o to, że mam dość samemu stawianie sobie pytań i odpowiadanie na nie. Czasami człowiek musi się utwierdzić, że to co robi jest dobre lub jest to ślepa uliczka. Koleżanka z pracy dała fajny przykład. Przed zaproszeniem znajomych w celu zagrania w jakąś grę siedziała 4h studiując jej zasady. Następnie ona wytłumaczyła im zasady w 15min. Oni wiedzieli dokładnie tyle samo co ona, a byli te prawie 4h do przodu. I to jest dla mnie minus pracy w 1 osobowym zespole. Nie ma możliwości szybkiego zdobywania wiedzy. Masz coś do zrobienia. Sam musisz wszystko sprawdzić i przetestować, a przecież czasami wystarczy spytać się kogoś kto spotkał się z danym problemem. Ja rozważam odejscie z pracy własnie z tego powodu, że mam dość rozwiązywania problemów i pierdółek bo nie mam nikogo innego kto mógłby mi pomóc, nakierować i muszę udawać, że jestem Panem Złota Rączka.

Zależy jak na to spojrzeć. Jeśli jako freelancer zarabiam dwa razy tyle co w firmie (a w rzeczywistości ponad dwa razy tyle), to mogę sobie pozwolić na pracę 6 miesięcy w roku za te same pieniądze, a pozostałe sześć miesięcy np. spędzać z dziećmi. Temat freelance vs. firma jest dość mocno dyskusyjny.

Tylko w wadą wolnych strzelców jest to że samemu trzeba poszukiwać projektów, a w firmie ktoś inny zajmuje się pozyskiwaniem klientów.

przyznam, że wybitnym programistą nie jestem, ale czuje podobnie,
zacząłem od webdevu i c++, ale jednak w webdevie zostałem, z czasem doszedł Node/React/Mongo/podobne, no i zaczęły się paczki z npm, kto do cholery to wszystko ogarnia, pewnie nawet nie znam połowy sensownych paczek,
pracuje dla firmy jako senior, 2 lata temu zrobiłem szybki projekt, "nieco" się rozrósł, teraz połowę każdego dnia nad nim spędzam :/ dołujące

Czytajac wasze wszystkie posty mozna normalnie popasc w depresje

@nospor, nie dołuj się

Ja z kolei mogę powiedzieć, że ostatnio czuję duży boost pod kątem architektury aplikacji biznesowych i w zasadzie nie widzę tego problemu "przepaczkowania" w backendzie u siebie (Symfony here)

@nospor
Depresję? Mnie dodały powodów do zmian w życiu, a nie stanu życia (1:0)

@tomplus no coz, niektorzy czerpia inspiracje z bolu i problemow innych

Po paru latach milczenia na forum postanowiłem się wypowiedzieć, bo okazuje się, że nie jestem sam w swoim rozumowaniu.

Zauważyłem, że od paru lat (w zasadzie od ZF2 czy SF2) webdeveloperka idzie na siłę w kierunku bycia pro. Coś co parę lat temu można było zrobić dużo prościej aktualnie jest niepotrzebnie komplikowane, a wszystko to w imię pro. Jestem programistą, który (według mnie) swoje najlepsze zawodowe lata miał w okolicach 2010/2011. Wówczas faktycznie byłem zadowolony ze swoich projektów. Jestem typem purysty, który lubi mieć wszystko pod kontrolą, dlatego wszelkiej maści udogodnienia (typu chociażby Composer) na dzień dobry mnie odrzucają. Najlepiej programowało mi się w Kohanie. Prosty framework ale dający duże możliwości. Dlaczego duże? Bo to tylko narzędzie. Miałem swoje ulubione dodatkowe biblioteki, które dołączałem do projektów, miałem pod nie napisane proste moduły w Kohanie. Wiedziałem wszystko co i jak, nie było w tym żadnej magii. Obecnie króluje Symfony i Composer. Gdzie nie spojrzeć - Symfony i Composer. Żeby wrzucić projekt na serwer konieczny/bardzo zalecany jest dostęp do konsoli. Ja wolałem po prostu wgrać pliki na FTP, poustawiać dostępy i po temacie. Proste jak budowa cepa.

Czy projekt napisany w Kohanie jest mniej pro od projektu w Symfony? Według mnie nie można tak tego określać. Framework z założenia to tylko narzędzie, więc od samego programisty zależy jak go wykorzysta i co na nim zbuduje. Chcąc odnowić lakier w aucie jeden może zaopatrzyć się w najdroższą maszynę polerską i odstawić fuszerkę, a drugi za pomocą ręki i szmatki wyprowadzi lakier na błysk.

Mam wrażenie, że obecnie panuje trend, że im bardziej skomplikujemy sobie życie tym będzie bardziej pro. Nawalimy 5 klas, dowalimy 17 interfejsów - nooo, teraz jest pro. Sro a nie pro. W pracy pracujemy nad wewnętrznym projektem, który ma już ok. 10 lat. Częściowo bazuje na własnym frameworku pierwotnego twórcy, a w większości na ZF1. Około 2 lat temu do pracy przyszła "świeża krew", która przeforsowała wprowadzenie Symfony (tak, projekt działa na 3 frameworkach!). Jest pro? Według mnie nie. Jest bajzel. Pomijając już kwestię 3 frameworków to moim zdaniem, żeby móc powiedzieć że projekt jest pro trzeba pisać go w narzędziu, które się zna. Wtedy można prawidłowo i efektywnie z niego skorzystać. Widzę natomiast po sobie i po kolegach, że rzeczy w Symfony powstają na zasadzie "o, działa, nie dotykać". To co w przypadku chociażby ZF1 przerabialiśmy po parę razy żeby w końcu być zadowolonym z kodu (efekt działania taki sam) zostawiamy w Symfony na etapie "o, działa". Tu dodaj to, tam dopisz to, jeszcze tu, wygeneruj to, zrób tamto - jak dla mnie chore.

Męczy mnie całe to przekombinowanie, utrudnianie, na siłę udowadnianie, że PHP też może być pro. Chciałbym znowu wziąć framework i z niego korzystać. Czego nie znajdę w dokumentacji to znajdę w kodzie źródłowym nie musząc przebijać się przez 38 plików. Wszystko jednak idzie do przodu. Symfony ma bardzo dobry marketing i według mnie tym się przebija. Pozostałe frameworki próbują dorównać bo przecież liczy się bycie pro. Świeżak wchodząc w świat frameworków nie ma zbyt dużego wyboru - skupi się na tym, co jest popularne (czyli na Symfony, no ewentualnie Laravel bo w tym momencie cała reszta się już nie liczy). I będzie się bawił w tworzenie encji i repozytoriów, a w efekcie i tak będzie operował na tablicach, a jeśli już na obiektach to tylko dla zapisywania zmian w polach. Ale będzie pro bo pisze w Symfony.

Kosmiczna abstrakcja bazy danych? Mamy zapomnieć, że korzystamy z bazy? Ma to być transparentne? Nie zgodzę się. Korzystamy z danego typu bazy danych to wykorzystajmy maksymalnie jego możliwości. Dlaczego narzędzie ma nas ograniczać jedynie do tego, co jest "wspólne" dla różnych silników bazodanowych? Moja baza ma typ pola idealny pod moje potrzeby - chcę z niego skorzystać. Mogę przerzucić część logiki na samą bazę tworząc X triggerów na jedno zdarzenie - też chcę. Niby mogę ale lepiej nie - bo przenośność...

Nie twierdzę, że Symfony to jedno wielkie zło. Nie przepadam za tym frameworkiem ale wiem, że są magicy, którzy potrafią w tym czynić cuda. Bo się na tym znają. Tak jak ja (moim skromnym zdaniem) swego czasu w Kohanie. Zdaje się jednak, że cała brać PHP-owa idzie w kierunku tego co na topie, a to dalej nakręca koniunkturę.

Naprawdę liczę, że w końcu nastąpi powrót do korzeni i pojawi się prosty framework all-in-one. Taka nowsza Kohana czy ZF1. I w końcu projekt wraz z frameworkiem zajmie 3-5 MB, a nie kilkadziesiąt MB. Że znowu zaczniemy myśleć jak rozwiązać dany problem, a nie jak rozwiązać go w danym narzędziu. Że przestaniemy dostosowywać schemat bazy danych do ograniczeń biblioteki. Jeśli nie - trudno, żyć za coś trzeba. Ale sentyment pozostanie :)

Najśmieszniejsze jest to, że znajomość frameworka już naprawdę nie czyni z nikogo profesjonalisty. Tak było może w 2013-2014 roku. Moja znajomość Laravela (który jest takim samym typem frameworka jak Symfony, czyli teoretycznie bazą do wszystkiego) jest moim zdaniem bardzo dobra, a i tak czuję się często jak leszcz.

Zespół, w którym pracuję pracuję, to rasowy devops. Oznacza to, że oprócz klepania głupot (bo deadline, do zmieniły się przepisy i trzeba się dostosować, itd.) jestem wystawiony na pokaźną dawkę wiedzy z zakresu ops. Jak wcześniej jarało mnie grzebanie we frontendzie (kiedyś byłem fullstackiem), tak teraz jara mnie dłubanie daleko za backendem Obecnie pracuję nad projektem, gdzie mam styczność z takimi technologiami jak docker, kubernetes, terraform, ansible, aws. Na dokładkę jest python i skrypty zarządzające całym tym grajdołkiem, a wszystko okraszone grzebaniem w najgłębszych odmętach plików konfiguracyjnych. Jakby tego było mało w domu pracuję na prywatnym projektem, który składa się z serwera websocket, aplikacji slack i wiadomości typu pub-sub.
Dlaczego o tym piszę? Ponieważ, jeśli lubisz swoją pracę, zawsze znajdzie się coś ciekawego do zrobienia. Znajdź coś, co chciałbyś robić i to rób. Napisałeś, że spodobał Ci się Swift. Napisz apkę, opublikuj ją, opisz na blogu (lub w innym publicznym miejscu) wyzwania jakie Ciebie spotkały oraz co odkryłeś. Rozbuduj apkę o dodatkowe funkcjonalności, zapakuj reklamy by zarobić na opłaty. Na każdym etapie będziesz musiał nauczyć się czegoś nowego.

Owszem, tylko stawianie tak sprawy to jest zamienianie problemu w postać zero-jedynkową i nie prowadzi do żadnych sensownych konkluzji. To, że osobnik A za każdym razem musi poświęcić 5 sekund na naukę nowych rzeczy nie jest tym samym problemem, co osobnik B zmuszony do poświęcenia trzech godzin. Ludzie często stosują ten zabieg retoryczny, by umniejszyć skalę problemu lub kogoś pocieszyć, podczas gdy to nie ma żadnej wartości praktycznej.

W czasach PHP4 też ciągle używało się nowych funkcji, bo język sam w sobie jest rozbudowany. Problemem jest ILOŚĆ tej nauki dzisiaj, a nie fakt, że ta nauka w ogóle jest potrzebna.

Nie chodziło mi o uczenie się nowych rzeczy dla samego uczenia się. Jeśli uważasz, że frontend idzie w złym kierunku, zmień obszar swoich zainteresowań na taki, który nie będzie dla Ciebie problematyczny, np. wspomniany Swift. Sama znajomość języka to nie wszystko, do tego dochodzi nauka Xcode, w przypadku aplikacji iOS będziesz musiał opanować storyboards, nie zapominajmy o testach, wersjach beta (TestFlight) oraz CocoaPods. Zanim zaczniesz publikować aplikacje w AppStore będziesz musiał nauczyć się jak to robić, a jeśli będziesz chciał zarabiać na tych aplikacjach, dochodzi kolejny element układanki - reklamy, subskrypcje, itp. Jak widzisz temat jest obszerny i pozwala na dalszy rozwój w kierunku, który nie składa się z nauki api kolejnej biblioteki.

Podsumowując:

Uważam, że frontend idzie w bardzo dobrym kierunku, tylko trochę okrężną drogą. Technologia przeglądarkowa powinna być bardziej elastyczna, a nie że kompilujemy trudne wymagania na stosunkowo proste języki, obchodząc przy tym wiele przeszkód świata webu.

Marzy mi się programowanie w pięknym języku (jak Swift), który byłby w miarę samowystarczalną dziedziną IT. Albo tworzenie czegoś bardzo kosmicznego, jak praca z blockchainem Utknąłem trochę w tym webie, robię to już tak długo, że trudno mi się wydostać. Ale nie ukrywam, że web mnie fascynuje na maksa. Pracujemy w najbardziej odjechanym medium ze wszystkich, jesteśmy królami świata hehe.

Też czasami mam takie wrażenie. Dlatego za każdym razem gdy dopadają mnie takie myśli, zajmuję się czymś innym. Kiedyś bawiłem się w aplikacje mobilne, potem frontend, obecnie jest to devops. Z każdej takiej odskoczni wyciągam coś ciekawego co daje mi motywację do dalszej pracy, np. jakiś czas temu przerzuciłem się na pythona.

Co do wypowiedzi phpion'a. Ja też pracowałem w Kohanie i pokochałem ten framework za jego prostotę. Działałem z kodem, gdzie klasy miały po 8k linijek, a metody po 500. O fuckup nietrudno. Dopiero kiedy zacząłem interesować się testowaniem automatycznym backendu to zrozumiałem, że prostota Kohany ma wiele drobnych zalet, ale również wady, które niepozwalają mi jako profesjonaliście na dalsze korzystanie z tego frameworka. Dziś jestem o wiele, wiele dalej. Wiem, co robię i że robię to dobrze. Mój kod jest testowalny, dzieli się na drobne kawałki, które łatwo jest wydzielić, otestować i zrefaktoryzować bez dotykania innych części kodu. Od pewnego czasu o błędach nie mówi mi klient, mimo że ciągle piszę w PHPie

Nie ma czegoś takiego jak doskonała testowalność kodu w dzisiejszych czasach. Języki są na to zbyt sztywne, zbyt dużo „dobrych praktyk” wykonuje się sztuczkami. Choćby taki dependency injection. Przecież w PHP tego nie ma, robimy to albo parametrami konstruktora lub metod (które przecież służą do czegoś innego), albo magią jak fasady w Laravelu.

Mam wrażenie, że ludzie trochę za bardzo dzisiaj są skupieni na stosowaniu tak zwanych dobrych praktyk, a stosując je często narażają projekt na dodatkowe błędy, bo niekiedy stosowanie tych praktyk bardzo komplikuje kod.

100% testów nie da radę osiągnąć - zgadzam się. Całego świata nie otestujemy Nie piszmy testów dla testów. Piszmy testy, które dają nam gwarancję, że nasza logika robi to, co powinna robić.

@SmokAnalog, sorry za offtop

@phpion
Ja bym jeszcze dodał że nie wolno się ze mnie śmiać tylko dlatego że zamiast pobierać bibliotekę composer która na 10 klas i 15 interfejsów, no i do tego zależy od 8 innych bililotek wolę napisać jedną funkcję która ma 10 linijek kodu i robi dokładnie to samo.

Ja właśnie tego nauczyłem się od szefa.
Jeśli chcemy coś prostego to napiszmy to samemu.
Spełnia zadanie - mamy wykonanie zadanie, idziemy z biznesem do przodu.
Co by było gdybyśmy skorzystali z zaawansowanej biblioteki?
Nauka biblioteki, implementacja biblioteki, ogarnięcie przypadków, które biblioteka w tym przypadku nie ogarnia, utrzymanie zależności (weź spróbuj zaktualizować inną bibliotekę, a wszystko się wysypie...), a potem za każdym razem wracaj do dokumentacji gdy chcesz zmienić czy poprawić jedną rzecz. Więcej czasu spędzamy na analizowaniu i czytaniu dokumentacji biblioteki niż samym rozwijaniu produktów.



Ja również zacząłem więcej pracować z mocnym backendem, tzn. docker, skrypty bash czy python. O wiele przyjemniejsza praca.
Najwięcej płaczu było gdy pracowało się z pakietami NPM. Tam to dopiero jest kosmos, a ile to cholerstwo waży...


Na początku mój świat programowania chciał być idealny. Ale nauczyłem się w pracy, że tak nie da rady, a po prostu trzeba iść do przodu - ale najważniejsze aby to było przyjemnością.
Dlatego właśnie trzeba nauczyć się rozdzielać te wszystkie aspekty i mądrze decydować by praca szła do przodu, ale też była z tego frajda - w tym rozwiązywanie problemów swoich, a nie innych osób (bibliotek).