PHP - rozwojowe miejsca pracy

Chciałbym zapytać Was o doświadczenie z firmami pracującymi w okolicach technologii PHP w polskich realiach, mianowicie które firmy są uważane za wymagające, ale rozwojowe, z odpowiednimi zarobkami? Zastanawiam się czy w ogóle są u nas firmy, które można byłoby wymienić ponad inne / ponad średnią, czy raczej szukacie takowych bezpośrednio za granicą? Lokalizacja w zasadzie przy rynku pracy zdalnej mało istotna.

Pytanie w sumie może być też szersze - nie tyle w kontekście reklamy tej czy innej firmy, co też ogólnych informacji o rynku, na co zwracać uwagę, na co się nastawiać, czego szukać itd. W co ewentualnie też iść technologicznie, utrzymując lata doświadczenia w tej technologii, a jednocześnie iść do przodu. Mam pewne swoje przemyślenia, ale byłoby super poznać feedback ludzi bardziej doświadczonych w temacie, wszelkie informacje wartościowe - dzięki.

Nie ucz się tej technologii, to jeden z najgorszych język programowania jaki chyba powstał.

Bzdura, PHP w wersji 8 wraz z Symfony w kontekście pisania aplikacji internetowych nie odstaje praktycznie od Javy czy .NET. Ma się nijak do realiów sprzed lat 10-ciu. Nic nie blokuje stosowania najlepszych praktyk inżynierii oprogramowania w tym zestawie. Ale ja w ogóle nie o tym, pytam nie w kontekście juniora który nie wie co ze sobą zrobić (wtedy i być może są lepsze wybory), a osoby z kilkuletnim doświadczeniem w pisaniu dużych aplikacji.

proton.x napisał(a):

Bzdura, PHP w wersji 8 wraz z Symfony w kontekście pisania aplikacji internetowych nie odstaje praktycznie od Javy czy .NET. Ma się nijak do realiów sprzed lat 10-ciu. Nic nie blokuje stosowania najlepszych praktyk inżynierii oprogramowania w tym zestawie. Ale ja w ogóle nie o tym, pytam nie w kontekście juniora który nie wie co ze sobą zrobić (wtedy i być może są lepsze wybory), a osoby z kilkuletnim doświadczeniem w pisaniu dużych aplikacji.

Bzdura.

To co weszło w PHP8 to kilka smaczków składniowych związanych z deklaracją typów, match expression, kilka funkcji na stringach, i kilka bug-fixów. Język sam nadal kuleje i to bardzo.

Jeśli masz na myśli, to że kod napisany w PHP8 wygląda podobnie, to masz rację - wygląda. Ale działa zupełnie inaczej.

Żeby PHP8 można było porównać do takich dobrze zaprojektwanych języków jak Java i C#, to musiałoby się stać wiele rzeczy, a przede wszystkim:

• Funkcje i klasy powinny być w swoich namespace'ach, tak jak w Javie i c# (w PHP wszystko jest w namespace \, czyli globalny)
• Powinny być dodane typy generyczne do arrayów i innych klas
• Odnoszenie się do nieistniejących wartości w mapie i obiekcie, powinno się kończyć wyjątkiem
• Funkcje powinny przestać zwracać false, null, -1 lub 0 kiedy jest błąd, tylko rzucać wyjątki
• Starsze zaszłości w PHP nadal zwracają notice/warning/error - powinny rzucać wyjątki jak jest problem, dlatego że try/catch na nich nie działa
• Anonimowe klasy powinny być jedynie w lokalnym scope'ie, bo teraz są deklarowane globalnie.
• Powinna zostać ustandaryzowana konfiguracja runtime'u, bo teraz jest 30 miejsc w którym można zmienić różne konfigi
• Powinny zostać dodane normalne kolejkcje, takie jak List, Map, Set, bo teraz jest tylko array który próbuje być zbitkiem wszystkiego z nich
• 99% funkcji do array'ów powinna być zrefaktorowana, bo każda działa inaczej (część traktuje array jak zbiór, część jak listę, część jak mapę).
• Powinny zostać całkowicie wyeliminowane "Fatal error'y", czyli takie errory które ubijają proces PHP
• Powinno być automatycznie ustawiane error_reporting(E_ALL), i nie możliwość jego zmiany, bo to jedynie wycisza wyjątki.
• Powinien być usunięty operator @ który wycisza wszystkie błędy.
• stringi powinny nie być callable, bo teraz np "strLen" to jest funkcja, którą można wywołać.
• Język powinien przestać być case-insensitive przy nazwach klas i funkcji
• Wszystkie funkcje powinny być nazwane wg. jednej konwencji, czyli albo tylko snake_case jak w Pythonie, albo tylko camelCase jak w Javie. Teraz w PHP połowa funkcji jest tak, połowa inaczej, niektóre mają nawet zlepek jednych i drugich.
• Wyjątki powinny przestać printować się same na standard output, tylko po prostu kończyć wykonanie tak jak KAŻDY INNY JĘZYK NA ŚWIECIE
• Należałoby znacznie poprawić albo usunąć operator ==, dlatego że teraz w PHP "0" == false; // true,
• Powinny zostać usunięte lub znacznie poprawione operatory or oraz and które mają odwrócony priorytet niż || oraz &&.

Gdyby to się stało, wtedy możnaby powiedzieć że PHP jest tak samo dobry jak Java/C#; a to i tak byłoby przekłamanie na rzecz PHP, jedynie wierzchołek góry lodowej zjebanych cech tego "języka". Większość tych rzeczy nigdy się nie zmieni, bo byłoby to zbyt ogromnym złamaniem kompatybilności wstecz, więc moim zdaniem PHP do końca świata już pozostanie klaunem języków programowania.

proton.x napisał(a):

Ale ja w ogóle nie o tym, pytam nie w kontekście juniora który nie wie co ze sobą zrobić (wtedy i być może są lepsze wybory), a osoby z kilkuletnim doświadczeniem w pisaniu dużych aplikacji.

Wybierz inny język do nauki.

To co piszesz to prawda, ale to wady. Sam język jest jaki jest. Ale PHP jako ekosystem ma też swoje zalety. Nie mam czasu na puste dywagacje do niczego nie prowadzące, bo nie o tym miał być wątek i nie będę tego ciągnął.

Fakt faktem, w dużym skrócie, można w PHP 8, wraz z Symfony, Doctrine utworzyć aplikację która w efekcie będzie równie dobra dla Klienta końcowego, często wręcz efektywniej czasowo i kosztowo, bez negatywnego wpływu języka jako takiego na efekt finalny, poziom architektury systemu czy maintenace - wszystko zależy od umiejętności programistów uczestniczących w pracach. A efekt końcowy jest tym, co interesuje w większości zamawiającego - z całym szacunkiem do tak porażającego argumentu jak istnienie operatora @, którego przez osiem lat programowania w praktyce nie zauważyłem, a różne legacy widziałem. Aplikacje z bardzo wrażliwą logiką biznesową, tworzone dla dużych światowych korporacji również.

Te rzeczy, które wymieniłeś w 90% typów aplikacji internetowych nie mają większego znaczenia dla wspomnianego finalnego efektu, w postaci aplikacji która działa, jest dobrze napisana, a jej rozwój jest efektywny kosztowo. Duża część Twoich argumentów to kwestia "istnienia" czegoś, co da się konfiguracyjne wyłączyć, czego stosować nikt nikomu nie każe i co zostało w celu zachowania kompatybilności wstecznej, możliwości wykonania upgrade-u z wersji 5.6 do 8.1.

I po to właśnie utworzyłem ten wątek żeby poznać ciekawe opcje rozwoju zawodowego, a nie babrać się w archaicznym PHP 5, albo walczyć z argumentami o jego słabości.

proton.x napisał(a):

To co piszesz to prawda, ale to wady. Sam język jest jaki jest. Ale PHP jako ekosystem ma też swoje zalety. Nie mam czasu na puste dywagacje do niczego nie prowadzące, bo nie o tym miał być wątek i nie będę tego ciągnął.

Fakt faktem, w dużym skrócie, można w PHP 8, wraz z Symfony, Doctrine utworzyć aplikację która w efekcie będzie równie dobra dla Klienta końcowego, często wręcz efektywniej czasowo i kosztowo, bez negatywnego wpływu języka jako takiego na efekt finalny, poziom architektury systemu czy maintenace - wszystko zależy od umiejętności programistów uczestniczących w pracach. A efekt końcowy jest tym, co interesuje w większości zamawiającego - z całym szacunkiem do tak porażającego argumentu jak istnienie operatora @, którego przez osiem lat programowania w praktyce nie zauważyłem, a różne legacy widziałem. Aplikacje z bardzo wrażliwą logiką biznesową, tworzone dla dużych światowych korporacji również.

Te rzeczy, które wymieniłeś w 90% typów aplikacji internetowych nie mają większego znaczenia dla wspomnianego finalnego efektu, w postaci aplikacji która działa, jest dobrze napisana, a jej rozwój jest efektywny kosztowo. Duża część Twoich argumentów to kwestia "istnienia" czegoś, co da się konfiguracyjne wyłączyć, czego stosować nikt nikomu nie każe i co zostało w celu zachowania kompatybilności wstecznej, możliwości wykonania upgrade-u z wersji 5.6 do 8.1.

I po to właśnie utworzyłem ten wątek żeby poznać ciekawe opcje rozwoju zawodowego, a nie babrać się w archaicznym PHP 5, albo walczyć z argumentami o jego słabości.

Jak sobie czytam Issues na githubie np takiego Laravela, albo PhpUnit to tam bohatersko pokonuje się przeciwności, które w innych językach nie istnieją.

Still. Moja rada - nie idź w PHP.

PHP dojrzewa jest bardzo popularny i wg mnie jest przed nim wiele świetlanej przyszłości. Jeszcze kilka lat temu tak samo nabijano się z JavaScript.
Nie jest językiem do wszystkiego jak C, C++ czy Delphi oraz ma swoje ograniczenia. Jednak ilość usług, w których znajdzie zastosowanie wciąż będzie rosła.
Dlatego warto się go nauczyć.

katakrowa napisał(a):

PHP dojrzewa jest bardzo popularny i wg mnie jest przed nim wiele świetlanej przyszłości. Jeszcze kilka lat temu tak samo nabijano się z JavaScript.
Nie jest językiem do wszystkiego jak C, C++ czy Delphi oraz ma swoje ograniczenia. Jednak ilość usług, w których znajdzie zastosowanie wciąż będzie rosła.
Dlatego warto się go nauczyć.

Tak myślisz?

Źródło (na wniosek @katakrowa): google.com

@proton.x:

To, że na łodzi z trzciny pokonano Atlantyk, to dowodzi wysokiej jakości trzciny, i że każdy student szkutnictwa musi się uczyć tej technologii ?

Still, wymieniasz rzeczy istotne dla technologicznego purysty (nie krytykuję, zgadzam się generalnie z argumentami, ale stwierdzam fakty). I drugorzędne w kontekście produktów dla Klientów, zwanych aplikacjami internetowymi. Plus niekoniecznie istotne akurat w tym konkretnym wątku. Bo wątek dotyczy wyłącznie tych, którzy chcą przy PHP zostać - taki był tegoż wątku cel :)

proton.x napisał(a):

Still, wymieniasz rzeczy istotne dla technologicznego purysty (nie krytykuję, zgadzam się generalnie z argumentami, ale stwierdzam fakty). I drugorzędne w kontekście produktów dla Klientów, zwanych aplikacjami internetowymi.

Purystą bym był, gdybym powiedział że PHP nie jest obiektowy i funkcyjny, albo że nazwy funkcji są nieintuicyjne, albo masę innych pierdół które nie mają znaczenia. Ale te rzeczy które wymieniłem w poście, w bardzo przyziemny sposób przeszkadzają wytwarzać oprogramowanie.

Pracuję w PHP od jakichś 10 lat, ilekroć coś robię to narzekam na jezyk - nie dlatego że mi się nie podoba, nie dlatego że jest brzydki albo źle zrobiony - tylko dlatego że to jedno z najgorszych narzędzi do wytwarzania oprogramowania. Nierzetelne, nieprecyzyjne, nie odporne na błędy, zastawiające pułapki na programistę, wydłużające czas developmentu, nie pozwalające nic znaleźć w dokumentacji, dostarczane rozwiązania są tak złe, że są dosłownie "worse than useless", wielokrotnie napisanie swojego rozwiązania jest lepsze niż korzystanie z tego które PHP dostarcza.

Jedną z dużych wartości programisty jest umiejętność znalezienia dobrego rozwiązania i narzędzia do danego celu. Polecam każdemu ją nabyć.

Riddle napisał(a):

Pracuję w PHP od jakichś 10 lat, ilekroć coś robię to narzekam na jezyk - nie dlatego że mi się nie podoba, nie dlatego że jest brzydki albo źle zrobiony - tylko dlatego że to jedno z najgorszych narzędzi do wytwarzania oprogramowania. Nierzetelne, niewydajne, nie odporne na błędy, zastawiające pułapki na programistę, wydłużające czas developmentu, nie pozwalające nic znaleźć w dokumentacji, dostarczane rozwiązania są tak złe, że są dosłownie "worse than useless", wielokrotnie napisanie swojego rozwiązania jest lepsze niż korzystanie z tego które PHP dostarcza.

Straszne masz przeżycia podczas pisania programów. Naprawdę żal mi Cię. Ja piszę w PHP prawie 15 i jest bardzo przyjemnie (w innych piszę dłużej). Na początku było trudno jak znałem tylko języki kompilowane ale od kiedy się go nauczyłem to PHP jest moim ulubionym choć doskonale rozumiem, że nie jest wydajny. Do wydajnych rozwiązań używam innych języków. Jego słaba wydajność wynika z jego architektury podobnie jak z Pythonem czy JavaScript. Jednak jak się to rozumie to nie jest to problem.

Jedną z dużych wartości programisty jest umiejętność znalezienia dobrego rozwiązania i narzędzia do danego celu. Polecam każdemu ją nabyć.

Dokładnie, spróbuj jeszcze dopuścić do myśli, że dla każdego to może być coś innego.

ZrobieDobrze napisał(a):

@proton.x:

To, że na łodzi z trzciny pokonano Atlantyk, to dowodzi wysokiej jakości trzciny, i że każdy student szkutnictwa musi się uczyć tej technologii ?

Nie bardzo wiem czego dotyczy ten komentarz? Nikogo nie zmuszam do nauki tej technologii, nikomu jej nie polecałem w tym wątku, a argument o łodzi z trzciny jest z czapy, bo wymienione wady PHP (z którymi się zgadzam) mają się nijak do kwestii najistotniejszej. Czyli stosunku ceny do jakości i finalnego produktu dla Klienta zamawiającego oprogramowanie. Te rzeczy, które wymieniacie są prawdziwe. Ale jakie ma znaczenie typ bugów w PHP Unit dla Klienta końcowego, zamawiającego oprogramowanie? I inne wymienione?

A to jest clue naszego zawodu - efektywność i jakość finalnego produktu dla Klienta. W tym kontekście 95% to umiejętności programistów realizujących projekt, zarządzanie, wycena, terminowość itd. Fakt, czy w PHP da się zrobić małpę ukrywając błędy lub czy dana funkcja zwraca false a nie null to nieistotny margines w kontekście finalnej jakości oprogramowania. Większy sens miałoby porównywanie Symfony do Spring czy Doctrine do Hibernate - to ma dużo większe przełożenie na finalny produkt, a tu PHP jako ekosystem źle już nie wypada.

Pomijam fakt, że w dobie SPA sam PHP czy nawet Symfony jest jakimś tam jednym elementem całości finalnego produktu, w przypadku większych produktów. A sam PHP-owiec to już raczej fullstackowiec, więc sama dyskusja o PHP jako kiepskim wyborze, w kontekście wątku, jest mało istotna.

@proton.x: nie słuchaj użytkowników, którzy wylewają swoją frustrację życiową na forach :)

Z tego co kojarzę to The Software House może być względnie wysoko technicznie (wnioskuję po blogu jedynie).

Aha no i unikaj Wordpressow, laravela, magento i tym podobnych stworzeń.

Szukaj tam, gdzie pisze się apki od podstaw głównie w Symfony, z jakimiś zagadnieniami typu hexagonal arch, CQRS, ddd itp. Szukaj tego w ofertach i na rozmowach pytaj szczegółowo jak to wykorzystują, czemu, jaką mają z tego korzyść itp.. z rozmowy rekrutacyjnej jestes w stanie dowiedzieć się dużo o sposobie pracy w danym zespole.
Jak czujesz ze coś kręcą pod nosem typu: No, cqrs tak, testy piszemy w zależności od potrzeb, blabla, ddd tak (to pytaj czy wiedza co to jest agregat i jak podchodzą do projektowania go, wyznaczania granic)
Pytaj, a będziesz wiedział czy warto iść czy nie.
Ostatnio odbyłem kilka rozmów to było widać kto pisze czysty kod, a kto kręci pod nosem.