Angular alkalmazások teljesítménynövelése [példakódokkal]

Címkék

Kiss Balázs előadása a HWSW free! meetup-sorozat 2023. március 23-i Angular tematikájú állomásán hangzott el. A meetupon a megszokottal ellentétben csak Balázs adott elő, így lehetőség volt a témában mélyebben elmerülni - 90 percben. Sokan kritizálják az Angular keretrendszert amiatt, hogy a framework méretéből fakadóan rátelepszik a benne írt webalkalmazás sebességére. Ez koránt sincs így! Megnézzük, hogyan tudjuk ezt mérni, illetve milyen eszközök állnak rendelkezésre a performancia növelésére az Angular keretrendszerben. A körsétánk során látni fogjuk többek között a Chrome audit tool-jait, a legújabb webes szabványok és az Angular összefonódását, a lazy load technikákat, szerveroldali renderelést és még sok minden mást.

Hozzászólások

Szerencsere ezt a szart is egyre kevesebben hasznaljak.

Szerkesztve: 2023. 11. 11., szo – 18:22

Véletlenül sem a végtelenül trehány (agilis!) módon összetákolt kód meg a csereszabatos hullóeszközként kezelt devek kombinációja adja ki a szar eredményt. Neem, dehogy. Az ügyfél percenként változó prioritásainak azonnali lekövetése sem b*sz szét mindent is. Az is tök rendben van, hogy mindenki azt okád bele a kódbázisba, amit csak szeretne mert "a sokszínűség és mindenki véleménye fontos", a mindenféle új fancy experiment, tool, framework maradékait meg szintén ott hagyjuk a kódbázisban, mert a kitakarításban nincs biznisz veljú. És ha nincs biznisz veljú, akkor arról nem lehet story írni, így fizetni se fog a k*va ugyfél érte. Nem csak meghallgatjuk, hanem bevonjuk a döntésekbe a gyakornokokat is, mert  "a közös gondolkodás adja ki a legjobb eredményt". Szóval 3 gyakornok leszavazza a 2 szeniort, amikor demokratikusan döntést hozunk. Ha a szenior meg kicsit beleállósabb, akkor utána mehet beszélgetni a szoftverfejlesztéshez szemernyit sem értő managerekkel, hogy "miért nem kedvesebb meg rugalmasabb másokkal" és "miért nem csapatjátékos".

A framework a hibás. Egyértelmű.

Meglepődnék ha a videóban bármi ilyesmi téma érintve lenne. Egyébként félre tudom ezeket tenni ezeket és a leckét is megtanultam: nem vívok meg olyan harcot, amit úgyse tudok megnyerni. Szar az IT, de ez van. A számlákat fizetni kell. Dolgozok bármilyen frameworkben-programnyelvben, lenyelem a hányást, széles mosollyal hamikálom a leglegacybb fost is. Örömmel aszisztálok a legnagyobb hülyeséghez is, bólogatok minden f*szomsághoz.

De a zsebbe k*rva bele kell nyúlni.

Elfogadtam, hogy ilyen a "professzionális" IT és hogy jelenleg és hosszú távon is ebből tudok a legtöbb pénzt kihozni a legkevesebb befektetéssel.

És vannak boldog pillanatok, órák olykor hónapok is: ha békén hagynak, akkor a legnagyobb legacy kakiban is örömmel tevékenykedek. Ha békénhagynak.

Megkérdezhetem, hogy te mire váltottál fejlesztésből? Legyek valami team lead vagy BA vagy PM/SM? Ugyanúgy IT, ugyanazokkal az emberekkel ugyanabban a közegben kell ténykednem, szóval semmi különbség. Menjek vasutasnak/lidlis pénztárosnak? Nem jó a $$$ ott... más magas hozzáadott értékű (lol) dologhoz meg nem értek. Tanulni nem vagyok rest, de az IT-ba sem 3 hónap/2 év után lesz profi valaki és habokra nem tolok bele akármilyen bizonytalan szakmába éveket.

> mire váltottál fejlesztésből?

uzemeltetesre... ha jol ossze van mar rakva a rendszer akkor alig van vele melo utana, max 2-3 evente egy nagyobb sw/hw upgrade de azt a max par napot ki lehet birni. meg hasznat veszem a programozoi tudasnak, nem csak scriptelesnel hanem hibakereseskor is jol jon, ha nem ijedek meg egy C forditasi hibatol vagy egy php fatal errortol a logokban frissiteskor...

bar a fejlesztesben biztos tobb a penz, ezt nem vitatom. de sose birtam elviselni, ha masok beleugatnak hogyan es/vagy mivel fejlesszek. mondjak meg mi a cel es bizzak ram hogy oldalom meg, milyen nyelven es milyen frameworkkel...

meg csapatban az uzemeltetes is lehet stresszes ha olyanok a tobbiek, en mondjuk (majdnem) soloban nyomom, csak egy alkalmazottam van aki maszkal ki ha on-site kell valamit butykolni, meg helyettesit ha epp nem erek ra / nincs kedvem dolgozni.

Az üzemeltetés se sokkal jobb. Ugyanúgy megvannak ott is a "vérnyomásemelők".

Alapvetően nem mindegy, hogy magadnak üzemeltetsz és az erre épített szolgáltatást adod el vagy az ügyfél rendszerét kell üzemeltetned. Utóbbi esetben az ügyfél összes dolgozója bele akar szólni a munkádba. Még Mancika is, a pénzügyről. Tapasztalataim alapján.

Véleményem szerint meg kell találni a megfelelő eszközt a felgyülemlő stressz, feszültség levezetésére. Akár munkahelyet, munkakört is váltva. Az élet többet ér.

Bármelyik bank lehet. Mind egykutya.

Egyébként full remote külföldre és itt épp jó. De tudom, hogy semmi sem tart örökké, és többnyire amúgy *rósz*, hisz a (*sóhaj) évtizedes tapasztalataimat írtam le. Meg kell becsülni a boldog (vagy nem fos) periódusokat.

Ha 3 gyakornok rossz iranyba akar elindulni egy frameworkkel, es 2 senior nem tudja nekik elmagyarazni, hogy miert, akkor az jo esellyel egy rosszul tervezett framework.

Ennel sokkal rosszabb szituaciokban is bizonyitania kell egy frameworknek: amikor a gyakornok tudasszintu ember honapokig egyedul dolgozott rajta es egy csak eggyel kevesbe junior atveszi, mikor eltunik.

Szerintem egyszerűen az van, hogy a juniorok el vannak kapatva. Piheség, érzékenység meg minden.

Az ő feladatuk az elfogadás, megértés, kérdezés és az iránymutatások követése (lenne). Természetesen van lehetőség kérdezni, 'csellindzselni' de "a szerintem másképp is lehetne csinálnira" a korrekt szenior válasz az, hogy "igen, de itt mi így csináljuk". Ilyenkor van, hogy az öntudatos junior jelzi a külvilág felé, hogy "én itt bizony el vagyok nyomva". Sajnos szuper fontos (lenne) az, hogy hogyan van elnevezve a változó. Az is fontos, hogy a metódusok milyen sorrendben vannak az osztályban. S privát metódus az később jön mint a public. Igen, a módosítók sorrendje is fix, mert ezer ilyen apróságból áll össze az, hogy nem egy hányinger az egész kód. Ha ezek be vannak tartva sincs garancia semmire, de ha nincs, akkor garantálom hogy foshalom az egész. Egy apróságtól önmagában nem elsz baj, de 1000 ilyen majd összeáll egy hordó fossá.
A legcsodálatosabb framework sem ment meg a hülyeségek 90 százalékától. A framework bizonyos határokig megszabja, hogy hogyan szervezd a kódodat, de az elnevezések, a stackoverflowról becopyzott széthekkelések, stb-t semmi sem tudja megakadályozni. Ilyesmik.

De a mai világ nem így működik, úgyhogy többnyire támogatás hiányában maximum olyan dolgokat észrevéleményezek, amik adatvesztéshez meg hasonló súlyú problémákhoz vezetnek. Egyébként szupportot se vállalok semmire... nálam nem fog csörögni a telefon éjszaka/hétvégén azért, mert más beleverte a ****át 2 hónapja.

Az Angular a frontend világ PHP-ja.