VÉLEMÉNY – Kinek a felelőssége, ha szar a weboldal?

Ha tetszett, oszd meg ismerőseiddel!

Nemrég beregisztráltam Tiktok-ra, és meglepő módon nem a seggrázós csajokat mutogatja nekem az algoritmus, hanem tényleg egészen jó tartalmakat dobál elém. Aztán elém dobta az egyik tiktok videós (azért se fogom leírni, hogy tiktokker), tartalmát, amiben az egyik munkájuk során tapasztalt furcsa hibajelenség kapcsán tette fel a címben is a kérdést, egészen pontosan, hogy kié a felelősség?

Előzmények

A történet lényege, hogy az egyik ügyfél arra kezdett el panaszkodni, hogy lassú a weboldala, egy-egy oldalbetöltés során akár 10-12 másodpercig is kint volt a kis loader ikon. Mint kiderült, egy carousel okozta a gondot, amibe az ügyfél 500 elemet jelenített meg. Ez azonban a videós szerint nem volt leírva a specifikációban és szerződésben se volt benne, ők meg nem gondolták, hogy egy ügyfél által kezelt carousel-ben 20-30 elemnél több lenne.

És hát szerinte itt jön a nagy kérdés, hogy akkor most kinek a felelőssége az, hogy lassú az oldal? Mielőtt erre válaszolnék, menjünk tovább, mert ennek volt egy kis utóélete is.

Egy másik videóban konkrét hibát hozott, amiben bemutatta, hogy a rossz kódban, a carousel összes eleme esetén lekérdezésre kerül a felhasználóID, ami ráadásul adatbázisból kerül lekérdezésre. Igen, jól érted, minden egyes elemnél újra és újra belekérdezett az adatbázisba, csak azért, hogy ugyanazt az adatot lekérdezze. Amint kiemelték a lekérdezést a foreach ciklus elé egy változóba, egyből sokkal gyorsabb lett a carousel működése.

A hibát okozó rossz kód
A javított változat

Na most, hogy ebben a konkrét esetben kinek a felelőssége az oldal lassulás? Ebben az esetben egyértelműen a fejlesztőké, hiszen többféleképpen is optimalizálhatták volna a carousel működését. Nekik elvileg megvan az a tudás és az eszközkészlet, hogy ezt megtegyék. A megrendelőnél ez ritkán van jelen.

Mit tudtak volna tenni, hogy ez elkerülhető legyen?

  • Egyrészt ennek a hibának már 10 elemnél is elő kellett volna jönnie. Már ennyi elemnél is fel kellett volna tűnnie, hogy miért is kérdezek bele tízszer az adatbázisba, mikor egyszer is elég lenne?
  • Lehetett volna valamilyen lazy load megoldást alkalmazni. A carouselnek a léptetéskor biztos, hogy van valamilyen eseménye, amire feliratkozhatunk. Aztán az esemény elsütésekor betöltjü a következő 3-5 elemet. Innentől kezdve akár 10 millió elem is lehetne a carouselben.
  • Ha nem voltak benne biztosak, hogy mennyi elemnél működik jól akkor, akár le is limitálhatták volna az elemek számát. Aztán persze a megrendelő szól, hogy nem tud mondjuk 30 elemnél többet berakni a carouselbe. Ekkor viszont már lett volna egy igény a megrendelő irányából, amin el tudnak indulni. Majd tudták volna tesztelni nagyobb darabszámra a carouselt, és akkor előjöhetett volna ez az oldallassulás hibajelenség.

Félreértés ne essék! Nem magas lóról akarok beszélni, és nem azt akarom mondani, hogy “én bezzeg sose követtem volna el ilyen hibát“. A gond azzal van az én szememben, hogy teljesen egyértelmű, hogy kinek a felelőssége az éles környezetben bekövetkezett lassulás. Ám ők mégis kérdést csinálnak belőle, és úgy tesznek, mintha az a megrendelő hibája is lenne. Nem! El kell ismerni, hogy ezt elrontották. Ki kell alakítani azokat a folyamatokat, és azt a gondolkodásmódot, hogy ilyen ne fordulhasson elő.

Alapszabály: nincs minden benne a specben!

Fejlesztőként tudni kell, hogy egy fejlesztésnek jó esetben a fele van benne a specifikációban, a maradék részét nekünk kell hozzá tenni. Át kell gondolnunk a lehetséges forgatókönyveket, és akár a teljesen abszurd esetekre is fel kell készülnünk.

Ezen példa analógiáján keresztül, én is mondhattam volna azt az egyik weboldalnál, hogy “áh nem rakok én lapozót a lista oldalra, mert a megrendelő azt mondta, hogy 20-30 terméknél nem lesz több“. Aztán persze már most ott járunk, hogy van majdnem 100 termék az oldalon, de van lapozó. Egy oldalon max 10 elemet jelenítek meg, és baromi gyors.

Úgy gondolom, hogy a mi szakmánkban alapvető, hogy azért minimális fenntartásokkal kezeljük a megrendelő igényeit. Amire inkább iránymutatásként tekintsünk, semmint kőbevésett parancsokként. Nyilván vannak kivételek, de itt most elsősorban olyan weboldal projektekre gondolok, mikor valaki megkeres, hogy kell neki egy oldal ilyen és ilyen célra.

Picit azért fogadjuk fenntartásokkal a megrendelő igényeit.

Mélyebb problémák

Szomorúan látom, és főleg a full stack fejlesztőknél, hogy valami nagyon nincs rendben szakmailag náluk. Nem gondolom magamat kiváló programozónak, de ezek a tapasztalatok számomra igencsak azt mutatják, hogy vannak olyanok, akik csak eladni tudják magukat, de nincs mögöttük megfelelő szakértelem.

Legnagyobb hibaként én azt látom náluk, hogy leginkább egy adott problémára, és annak gyors megoldására fókuszálnak. Az, hogy esetleg kicsit lelassítsanak és megnézzék, hogy annak a megoldásnak, amit írtak annak milyen hatásai lehetnek, esetleg elgondolkodjanak az esetleges veszélyforrásokon ,már nincs helye és ideje a munkájuk során.

Minél gyorsabban túl lenni rajta, minél gyorsabban átadni a megbízónak, hogy minél hamarabb lehessen bevasalni a pénzt a munkáért. Nem gondolom, hogy ez szerencsés hozzáállás. Bár azt is gondolom, hogy mivel szerintem ez nincs helyén, ezért én sose fogok meggazdagodni ebből.

Tudom, hogy könnyen beleesik az ember abba hibába, hogy gyorsan akarja megoldani a problémát. Hiszen nincsen senki aki ránézne a kódjára. Az ügyfélnek meg oly mindegy, hogy most például for-ral vagy jQuery-s each-csel iterálsz. Csak hát ugye tudjuk, hogy az egyik majdnem tízszer olyan lassú, mint a másik.

Működik? Működik. Azt csinálja amit kell? Akkor meg?

random programozó

Igen ám, csakhogy ez nem helyes hozzáállás. Egyrészt felderítetlen hibák maradhatnak a kódban, másrészt nem is túl erőforrás kímélő. Bármennyire is furcsa, hogy már nem kell szöszölni a számítógépekbe beépített 10kb memóriával, hanem már gigabájtok és gigabitek állnak rendelkezésünkre, attól még kötelességünk, hogy ahol lehet optimalizáljuk a kódunkat.

Ha nem tudjuk, hogy hol kezdjük, akkor nézzünk szét style guide-ért a neten. Ezek jellemzően valamelyik nagy cég iránymutatásait és megoldásait tartalmazzák.

Vegyünk erőt magunkon, és ne kényelmesedjünk bele a beömlő megrendelői pénzekbe, hanem fejlődjünk. És pláne ne toljuk át a megrendelőre, a mi hibánkat.


Ha tetszett, oszd meg ismerőseiddel!