Miért csak gány munkák vannak php-ban?

Címkék
Miért csak gány munkák vannak php-ban?
2022-11-16T19:22:14+01:00
2022-11-28T16:12:51+01:00
2022-11-28T16:30:30+01:00
  • Folyamatos adat import a db-be, akar 1 millios elemszamu xml feldolgozas atalakitas, normalizalas.
    Mutasd a teljes hozzászólást!
  • memoria kezeles heap vs stack-re gondoltam, hogy hova is kerul a lokalis valtozo, es a new operator hol hoz letre.
    Mutasd a teljes hozzászólást!
  • Igazából a stack akkor is előjön, ha fagyizol...
    Mutasd a teljes hozzászólást!
  • Egy PHP fejlesztőnél előjönne ilyesmi?

    Éppenséggel akár elő is jöhet, ha valami minimálisnál nagyobb adatmennyiséget szeretnél feldolgozni PHP-ban, és ez a feldolgozás nem csak egy végigiterálás. PHP-nál azért találkozol ezzel ritkán, vagy inkább egyáltalán nem, mert jellemzően minimális adatot menedzselnek a PHP-ban írt programok (itt most nem az adatbázisok méretére gondolok). De jöhet olyan feladat, amit nem tudsz delegálni az adatbáziskezelőnek pl, és akkor hamar előkerülhet a téma.
    Mutasd a teljes hozzászólást!
  • Egy PHP fejlesztőnél előjönne ilyesmi? Én az elmúlt 15 évben el voltam enélkül. A PHP fejlesztők többsége egy webshopot vagy valamilyen összetett CRUD alkalmazást fejleszt. Tök mindegy hogy amit értékesít a cég az egy bicikli, vagy egy utazás, repülőjegy, vagy épp egy társkereső, az mind mind egy webshop. Egy terméket kell értékesíteni. Ezt már 15 millió féleképp lefejlesztették, de az alapja ugyanaz, vannak vevők, vannak készletek, termékek/szolgáltatások és ez van össze vissza kavargatva már vagy 30 éve. Mivel 2-3 évente kijön egy egy új keretrendszer, még akkor is ha ugyanazok gyártják (láthatod mat383 hozzászólásából is, amit nekem irt), hogy a fejlesztők mindenáron úgy érzik hogy ezt mindig egy újabb köntösben de úja és újra el kell készíteni. Ez ad munkát nekik, de hogy ehhez valami egyre bonyolult adatszerkezettel kellene megismerkedniük, nem hiszem.
    Én már azt is megtapasztaltam a keretrendszerek kapcsán hogy ezeknek is van egy evolúciója. Előszőr egy alig használható, de viszonylag lightweight keretrendszer készült el. Aztán ez egyre bonyolódik, és ahogy egyre bonyolódik, megjelenik a következő, ami megint elég lightos. Aztán amikor annyira bonyolult lesz, hogy csak néhány kiválasztott érti, akkor elengedik, és a többség ráugrik arra a következő könnyűre, ami emiatt el kezd bonyolódni és jön a következő kör. Na most ez nem csak keretrendszerekre igaz, hanem sajnos a programozási nyelvekre is.
    Mutasd a teljes hozzászólást!
  • A stack és heap alatt memóriaterületeket értett. A nagyon egyszerű definíció az, hogy minden a stack-en van tárolva, ami nem dinamikus memóriaallokáció által jön létre (C-ben malloc). Pl. minden egyszerű típus, a struct, a pointer mind-mind stack-en tárolódik, míg az objektumok heap-en. A kettő között az a különbség, hogy a stacken tárolt adat addig él, amíg az a hatáskör (kódblokk) véget nem ér, amelyben deklarálva van. A heap-en tárolt adat túléli a hatáskörét, ezért van a memory leak, ha nem szabadítod fel, vagy garbage collectort használó nyelvekben a reference counter értéke 0 nem lesz.
    Mutasd a teljes hozzászólást!
  • Tuti használtál :) Nem hiszem, hogy az adatstruktúrákra gondolt. Egyébként az ismertebb adatstruktúrákról van értelme beszélgetni interjún, mert amikor adattal kell dolgozni, akkor előjönnek. Persze nem úgy, hogy implementáld le, hanem hogy milyen aszimptotikus, és egyéb tulajdonságaik vannak, mit mire használunk.
    Mutasd a teljes hozzászólást!
  • Mi a stack, és mi a heap?

    Soha az életben nem használtam még heapet. A quicksortot se tudom fejből lekódolni papíron. Lehet, el kéne engedni a 20 éve nem releváns interjúkérdéseket.
    Mutasd a teljes hozzászólást!
  • A probléma kettős:
    1. hiányzik a tudás. sok ember hiszi magát senior php fejlesztőnek, és akár fejlesztést vezet
    2. hiányzik a feltétel. "php-ban gyorsan lehet fejleszteni" ezért minden gyorsan kell, és csak 50-70%os megoldások vannak. Nincs pénz arra, hogy leálljon a cég, és újból kifejlesszünk mindent.

    1.
    Egy magyar cégnél vagyok CTO, és én felvételiztetem az embereket. Sok olyan fejlesztő volt, aki magát Seniornak vallotta (bérben nem volt szegyellős), utólag azt mondanám, hogy átlag feletti php fejlesztő volt. A kérdésre. hogy "Mi a stack, és mi a heap? Melyiket mire használod (mire használódik)? Mi a stack overflow?" A válasz az volt, hogy nem tudja, Ő még sosem használta. Ez sztem több, mint gáz. Nincsennek meg az alapok. Ha egy ilyen fejlesztő önállóan, felügyelet nélkül megkap egy feladatot, megoldja gyorsan. Aztán idővel gyűlnek az adatok, lassú lesz, és lehet rossz is.

    2.
    Senki nem akar gány rendszert összerakni, és senki nem akar ilyet venni, csak apránként azzá válik.
    A főnök gyorsan kéri, el is készül egy gyors megoldás. Majd ha időnk lesz megcsináljuk rendesen. Sosincs, mert újabb gyors megoldás kell. És elérkezik az a kód, adatbázis állapot, amikor újra kell írni. Már senki nem nyúl szívesen adott részhez. Kis módosítás se jön össze csak harmadjára, és sokáig tart. Mivel sietni kell, nincs tényleges tervezés, megbeszélés. Dől az egész, de még pakolunk a tetejére, hadd dőljön gyorsabban.
    Itt a felelősség kettős. Egyrészt a fejlesztő nem szól vagy nem elég karakán, hogy bár jónak tűnik, de nincs kész, és vissza kell rá fordulni. Másrészt a managerek azt mondják, hogy egyszer már kifizettük, nem fizetünk még egyszer érte. 

    A folyamatnak része kell legyen a folyamatos refactor. Amikor megcsináltad, még nem tudhattad a körülményeket, az újabb igényeket (mert még nem is volt). Ha most kellene megírni, akkor másképp kódolnád.

    Mi már nem veszünk fel semennyi pénzért olyan fejlesztőt a gányolós csapatból, folyamatosan keresünk fejlesztőket, akik TUDNAK tiszta kódot produkálni SOLID elvek mentén. És nagyon keveset találunk. A nálunk levő régi motorosok is, ha nyomás van rajtuk rögtön visszakapcsolnak gány üzemmódba, mert ott tudnak gyorsan, stabilan fejleszteni. Most folyamatosan átírjuk, frissítjük a régi kódot, ha bármi ok miatt módosítani kell.

    - 1 hónapos on boarding folyamatban vannak fixen videók, amiket meg kell nézni.
    - minden nap van egy órás meet az újakkal, ahol értékeljük az aznapi videókat, és megbeszéljük miért jó ez.
    - amikor úgy érzem, hogy hogy tud SOLID, tesztelhető kódot írni, akkor mehet éles kódra. 

    Egyszer a végére érünk. Akit érdekel ilyen munka (remote is), az keressen privátba.

    csatoltam egy kb 20 éves könyvből egy oldal képét. Ismerős?
    Refactoring to Patterns (Addison-Wesley Signature Series (Fowler)) 1st Edition
    Mutasd a teljes hozzászólást!
  • akkor javítsuk a kódot, küldjünk pull requesteket!
    hátha lesz belőle valami jó kód !
    és community supportként, szeretetből.
    :)
    Mutasd a teljes hozzászólást!
  • Telegrammon is fent van, vagy volt,
    bárki letölthette,
    de akkor valaki kirakta githubra is.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Miért csak gány munkák vannak php-ban?

    Nem csak azok vannak.

    A helyes kérdés: miért csak gány munkákkal találkozol PHP-ben? És ez nem valamiféle lehúzás, hanem tényleg a helyes a kérdés, amire neked kell megfejtened a választ.

    Pl. simán lehet, hogy egyszerűen csak nem a megfelelő módon keresel vagy hiányoznak bizonyos ismereteid, hogy jobb munkákat ajánljanak pl. LinkedIn-en. Ha értesz valamelyik népszerű keretrendszerhez, akkor nagyon jók az esélyeid egy jó pozícióra.
    Mutasd a teljes hozzászólást!
  • Hol lehet megnézni a Kréta forráskódját?
    Mutasd a teljes hozzászólást!
  • Legyen hobby project-ed, ami csak a tiéd, abban kiélheted a valódi kreativításodat, és a technikai hozzáállásodat is tükrözi.

    Na de evvel pont az egésznek a sava-borsa vész el, a kódfejtés és kódrégészet, a "megértettem, hogy mire gondolt az örült zseni elődöm" és a többi finomság
    Mutasd a teljes hozzászólást!
  • Hasonlo. Ahogy irtak is annak a bizonyos iskolai rendszernek a kodjat nekem is volt szerencsem latni es bedolgozni, meg ehhez hasonlo nagyobb projectekben latok iszonyu elavult es vagy gany megoldasokat. Egesz egyszeruen akik zold mezos projectet elkezdenek azok olyan veteranok, akik azelott pont ugyanolyan a piacra termelest mindenek elott tarto sokszor technikailag is elmarado eszkozokkel alitottak elo futoszalagon. Elenyeszo az aki ez mellett otthon munka utan meg nekiall hobbibol projectezni szepen, tisztan, szarazon, sportszeru kihivasbol.
    Mutasd a teljes hozzászólást!
  • na de mit kell belenyúlni?

    Tegyük fel, hogy nem refaktorálsz, csak az új kódot már az új paradigma szerint írod.
    N*100K soros JS alkalmazás, tele nested callbackkel. Megjön a promise támogatás a nyelvbe... a régi dolgokhoz nem nyúlunk, azok jók, ahogy vannak. Viszont az új cuccokat már légyszi promise-szal csinálja mindenki, ne tákoljunk a callbackezéssel!
    Oké, eltelik pár év. A kódbázis fele callback hell, a másik fele promiseolgatás. Megjön az async-await. Frankó, a régi dolgokhoz nem nyúlunk, azok jók, ahogy vannak. Viszont az új cuccokat már légyszi async-awaittel csináljuk, ne tákoljunk a promiseozással!
    Egy év múlva a függvények harmada 26 callbacket passzolgat ide-oda, a másik harmada promiseokra vár, a harmadik harmada async-await, de try-catchelve, mert valahogy integrálni kell a callbackes függvényekkel.
    Mindemellé a kliensoldalra jön a React, ami három hetente megváltoztatja a paradigmát, így az alkalmazásod fele class componenteket használ, a fele hookokra van már átírva, a fele meg már eleve nextjs-ben van, mert az a jövő, a felét meg vanilla js-ben újraimplementáltad, mert úgy 30x gyorsabb.
    Közben az egész egy 10 éves foundationt használó PHP szerverrel kommunikál, kivéve egy pár servicet, ami változatos módokon express, next, svelte, fastify, mikor melyik toolkit fejlesztő épp mit talált megfelelőnek. Az adataid fele relációs adatbázisban van, a fele nosql, a fele meg txt fájlokban a szerveren.

    Vagy ez van, vagy van kiválasztott technológia és paradigma, de ha valamelyik megváltozik (ami JS-nél tényleg kb. évente van, ha hatékony és modern akarsz maradni), szépen újra kell írni mindent.
    Mutasd a teljes hozzászólást!
  • Ez vajon más területen is így működik? Pl Java, .Net, nodejs... 

    Persze, hogy így van. A platform csak egy technikai dolog. A forráskódok spagettivé transzformálódása, a régi kódok - szükségszerű - tákolása, karbantartása, és műkődtetése pedig pénzügyi. Ebből él meg az adott cég. Valójában ha logikusan belegondulunk mindenféle olyan eljárás, ami a kód minőségét próbálja meg folyamatosan javítani, fenttartani - code review, tesztek írása, stb. - egy nagyon szép technikai megoldás, de a valós életben ezek mind időbe - sok időbe - és pénzbe kerülnek. De mivel egy cég a profitot keresi, éppen általában az idő az, amiből soha sincs elég. Erre találták ki a különféle agilis módszertanokat, de ha mélyen átgondoljuk az egész ökószisztémát, ahogy ez műkődik, az agilis módszertanok sem mások, mint a gyors munkavégézés szép köntösbe csomagolása. Azt a célt szolgálják, hogy a maszeknak minden gyorsan elkészüljön, és át lehessen adni a kész terméket a megrendelőnek. Ilyenkor jön a kérdés: ebbe meg akkor hogyan fér bele a normális code review, meg a tesztek? A válasz: általában minimálisan, vagy sehogy sem. Majd kijavítják később, vagy akkor, ha éppen az problémát okoz, vagy ha kérik...és kifizetik. És ebből levezetve az jön ki, hogy a kód csak szépen dagad és spagettizálódik, ráadásul jönnek-mennek rajta a fejlesztők, és minden új harcos hül*ének nézi azokat, akik korábban dolgoztak a programon. Előállnak az ötleteikkel, átírják a kódot - közben 10 másik részt, ami addig valahogy műkődött elrontják (mert azt sem tudták, hogy ott van egy hivatkozás) - és ez az egész az idő előrehaladtával csak folyamatosan romlik. Ezért van az, hogy sokan - néhány év után - kiégnek, és a munkát már csak hegesztésnek, tákolásnak tarják. Vannak akik ez miatt váltanak, de kis idő után rájönnek, hogy az új helyen is ugyan ez a favágás megy, és megint csalódnak.
    A keretrendszerek meg gyorsan változnak, de a régi kódókat felhúzni rájuk megint idő és pénz, így inkább hagyják a fen*be, tákolják, és azt foltozzák.

    Legyen hobby project-ed, ami csak a tiéd, abban kiélheted a valódi kreativításodat, és a technikai hozzáállásodat is tükrözi. A munkahelyi kódólás sokszor csak gányolás, az igazi programozás ott kezdődik, amit maganak csinálsz. És nem azért, mert nem akarod elvégezni a munkádat a munkahelyeden, hanem egyszerűen azért, mert a környezet erre nem ad lehetőséget. Persze vannak azért olyan munkahelyek is, amelyek adnak a kód folyamatosan, és hosszú távú karbantartására, ott lehet szép megoldásokat látni, akár évtizedes fentállás alatt is, de rendszerint ezeket nem a magyar KKV szektorban, és főleg nem a PHP alatt kell keresni. De biztos, hogy van itt is kivétel. :)
    Mutasd a teljes hozzászólást!
  • Vagy nem írsz újra semmit, szépen fut az a közel 6 éves angularjs nálunk is. Még van PHP Symfony 1.4-es projekt (8 éves), meg Cakephp 1.3 (13-14 éves). Az utóbbiba már én is útálok belenyúlni, na de mit kell belenyúlni? Múltkor kellett egy új lekérdezést csinálni a SOAP felülethez, kemény 3 filet kellett módosítani, és kb.6-8 sor volt. Most ehhez tényleg újra kéne írni mindent is?  Sosem értettem, hogy mitől lesz jobb, hogy ha újraírjuk. Közben egy másik modult még simán irhatok akár Vue3-ban is, ha úgy gondolom. Ez sem jelent problémát. Sőt a backend lehet akár ugyanaz az api. Dockerrel ezek már akár egymás mellett elmennek ugyanazon a vason, vagy VPS-en. Nyilván ebből az következik hogy lesz  pár keretrendszer, plugin és modul, amit használtunk már az elmúlt 15 évben. De minden egyes alkalommal újra kellene írni mindent, ha kimegy a divatból? Akkor is, ha amúgy megy minden szépen különösebb probléma nélkül? 

    Persze nem fontos hogy ilyen céghez menjen az ember dolgozni. De ez a cég, aminek tizenx éves programjai vannak még 20 év múlva is működni fog, az új startup meg lehet rendesen be se indul. Ráadásul a legtöbb ilyen régi cégnél nincs is igazi hajtás, nem az a lényeg hogy tegnapra legyél meg valamivel, hanem hogy rendesen működjön, hogy 10 év múlva se kelljen hozzányúlni. Csak akkor kell hozzányúlni ha kell bele valami új, de az se kell elkapkodni, majd jó lesz az akkora, amikor jó lesz.
    Mutasd a teljes hozzászólást!
  • OFF
    1. nekem azért nem teljesen tiszta, hogy az éles KRÉTA forrásáról van-e szó vagy sem
    2. de viszont aki de viszont-al kezd mondatot és a nagy tam-tam után mégsem közli az exploitot az egy eléggé kisszerű script-kiddie-nek tűnik...
    ON
    Mutasd a teljes hozzászólást!
  • Láttad már a KRÉTA forráskódját? Szóval ja, nem csak PHP-ban lehet gányolni.
    Mutasd a teljes hozzászólást!
  • Igen, abszolút telitalálat
    És ugyanolyan lelkesedéssel állnak hozzá az újabb küldetésnek, mint Artúr király lovagjai, miközben a Szent Kelyhet keresik és vélik megtalálni újból és újból (és újból)...
    (Szegény PHP meg ehhez képest kompatibilis visszafelé hosszú éveken keresztül és egyes megátalkodottak képesek voltak natív mysql drivert csinálni a 7-es meg 8-as verziókhoz...)
    Mutasd a teljes hozzászólást!
  • Annyival jobb a helyzet mas teruleteken, hogy a WP/Joomla/Drupal jelleggu CMS-ek kevesbe nepszeruek, helyettuk inkabb keretrendszerekre (Spring, ASP.NET) epitkeznek. Ennek szerintem nem elsosorban nyelvi okai hanem tortenelmi gyokerekre visszavezetheto gazdasagi okai vannak: a php fejlesztok olcsobbak tehat ha egy testreszabott CMS is kielegiti a megrendelo igenyeit akkor felesleges egyedi fejlesztest kifizetni.
    Mutasd a teljes hozzászólást!
  • Esetleg tapasztal még valaki hasonlót .net, java, javascript oldalról?

    JS-ben jellemzően pár évente elavul a teljes stack és újraírsz mindent
    Frissítsd a böngésződet
    (Ez amúgy humor, de tényleg így van.)
    Mutasd a teljes hozzászólást!
  • Ez vajon más területen is így működik? Pl Java, .Net, nodejs...
    Mutasd a teljes hozzászólást!
  • Szerintem valami zöldmezős projektet kéne keress magadnak, mert hát egy 10-20 éves cég már csak így működik, hogy viszik magukkal a sok legacy kódot és azt tákolgatják. Mi is pontosan látjuk, hogy a tíz éves keretrendszerünk miért rettenetes, de 1-2 ügyfélért tuti nem fogjuk az egészet újraírni, refaktorálni, vagy az újba migrálni, ha éves szinten 10-20 munkaórával megússzuk azt, hogy működőképes maradjon... Ez valóban nem túl lélekemelő, de hát egy cégnél vannak a bevételek, meg vannak a munkaórák, szóval öncélúan senki nem fogja arra fordítani az erőforrásokat, hogy kicsit szebb és kicsit gyorsabb legyen az, ami tíz éve megvan és működik.
    A programozási paradigmákról pedig csak annyit, hogy szerintem azt is mindig csak előrefelé lehet bevezetni, nem visszamenőlegesen, ráadásul úgy, hogy megtalálod az adott csapat adott struktúrájához legjobban passzoló modellt. Egy ismerősöm meséli, hogy beszállt egy másik programozó mellé egy állami multimédiás szoftver továbbfejlesztésébe. Teljes munkaidős állás és elvileg korlátlan idő- és erőforrás áll a rendelkezésükre a régi "tákolmány" újraírásához, nekem azért mégis vannak fenntartásaim, hogy MVC szemlélet és OOP meghozza-e a várt eredményt és a szoftver valóban szebb, gyors és rugalmasabb lesz-e ettől az újraírástól. Nyilván igen, valamennyire az lesz, de nagy kérdés, hogy a befektetett erő és energia mikor is térülne meg piaci körülmények között.
    Mutasd a teljes hozzászólást!
  • Ma már fontosabb a soft skill a hardnál, ez van. Műkörömépítőből átképzett jó dumás, nyelveket tudó embereket hamar felvesznek, a végeredményen meg úgyse látszik semmi mi lapul a "motorháztető" alatt. "Mindegy hogyan, de működjön!".
    Mutasd a teljes hozzászólást!
  • Immáron 15 éve vagyok PHP fejlesztő. Végigkövettem a nyelv fejlődését, lépést tartottam vele. Most a még ki sem jött 8.2-es feature-jait is tudom, és ámbár azért 100%-kig nem használtam ki (pl. fork-olást nem csináltam), azért nagyrészt kihasználtam a dolgait. MVC, keretrendszerek, optimalizálás. Memcache, redis, rest api, elastic. Tervezési minták, GoF könyv olvasása, unit tesztelés.

    Az előző helyemről azért jöttem el, mert elegem lett a kb. eljárásorientált, WordPressre épülő, OOP-t nagy ívben mellőző kódok tákolgatásából. Inkompatibilis, félkész, 46 millió ex kolléga hátrahagyott gányjai. Ha valami modernebbet használtam volna, névtelen osztályok/függvények, néznek rám értetlenül. És minden csak tegnapra kell.
    Na és ahová csöppentem? Ugyanez! U gyan ez! Sok felhasználó, nagy terheltségű oldalak, aztán wordpress. Felvételi eljárásban kérdezgettek pl tervezési mintákat. Na, azokat dobhatom ki a csukott ablakon. Architektúra, MVC? Az mi? Ird csak a 20000 soros functions.php-ba az újabb hook-ot! Ez nem programozásról szól, hanem tákolásról! Épeszű admin felület? Ugyan, beégetett azonosítók! Aztán meg localon nem lehet vele dolgozni, mert egy oldalletöltés 40 másodperc. Persze élesen gyors, mert 3 féle cache van, de azért riaszt már az erőforrásmérő. 60 query fut le, 300 megával, tudunk rajta segíteni??

    Esetleg tapasztal még valaki hasonlót .net, java, javascript oldalról? Hogy tanul valamit egyetemen, vagy önmagától, aztán szájbavágja a valóság, a kiégés?
    Mutasd a teljes hozzászólást!
Címkék
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd