Programozásról lesz szó.

Ha ez téged nem érdekel, ugord át a bejegyzést. :)

Egyik haverom éppen mostanában fáradozik egy bizonyos vállalkozási célra megvásárolt PHP alapú rendszer beüzemelésével, azonban szomorúan volt kénytelen konstatálni, hogy a drága pénzen beszerzett cucc bár a várakozásait túlszárnyalva valósítja meg az általa igényelt funkciókat, akad benne néhány zavaró hiba.

Anélkül, hogy a Magyarországon úttörőnek számító megoldásról idő előtt kényes részleteket árulnék el, annyit elmondhatok, hogy az adott AJAX alapú cucc a látogatókat versenyezteti bizonyos szempontok szerint, majd pedig a gyorsaságuk alapján rendezi őket sorba.

A rendszer a képernyő egy külön területén jelzi ki, hogy melyik felhasználó vezet, valamint egy másik területen, hogy korábban miként alakult a sorrend. Ez a két képernyőterület (a lista és az azt vezető felhasználó kiírása) az esetek többségében tökéletes szinkronban van, azonban ha egyszerre többen is kattintanak, akkor néha elcsúsznak egymáshoz képest az adatok, és az egész cucc egy olyan hibás állapotba ragad be, mely kijelentkezés után is megmarad.

Haverom engem kért meg, hogy járjak utána, mi lehet a gond, mert ő nem ért hozzá.

Oké, mondom, nézzünk rá. Van egy gomb, meghív egy JavaScript függvényt. Rendben, hol van az a függvény? Négy különböző .js fájlt is behív a fejléc. Nézzük csak meg, melyikben definiálják a kérdéses függvényt. Ez is megvan, öröm, boldogság. Függvényünk létrehoz egy AJAX  (XMLHttpRequest) objektumot, amit ráereszt egy bizonyos PHP-ra. Na, itt kezdtem el jegyzetelni, hogy ne zavarodjak bele a hierarchiába. :) Szóval van az Ajax objektum által meghívott PHP rengeteg egymásba ágyazott feltételfüggő (if {}) résszel. Ha egyszerre hatszáz dolog összeáll, akkor ez lefuttat egymás után egy csomó frissítő meg hozzáfűző MySQL lekérdezést.

Na, itt kezdtem el vakarni a fejem.

Vajon mi a ványadt fenéért írja be a cucc egyszerre ugyanazt több táblába is? Mi értelme van külön tárolni a listát vezető felhasználó adatait és magát a listát? Van-e valami konkrét funkció, ami indokolja ezt a redundanciát? Végül arra jutottam, hogy nincs itt semmi mélyebb megfontolás, egyszerűen egy koncepciótlan láma a fejlesztő.

A koncepció hiánya már abban is világosan megmutatkozott, hogy látva az egymás alatt sorban meghívott lekérdezéseket még nekem is az volt a legelső kérdésem, hogy mindez szép és jó, de vajon mi történik, ha egyszerre többen kattintanak a folyamatot elindító gombra a weblapon, vagyis ezáltal egy időben többen is lefuttatják az azt kiszolgáló PHP kódot? Ebben az esetben nyilván az történik, hogy az egyes meghívásokban szereplő SQL utasítások jó eséllyel összekeverednek. Az első fele az első felhasználó adataival hajtódik végre, a második fele a második felhasználóéval, végeredményként pedig  megkapjuk a hibát: nem lesz szinkronban a lista és az azt vezető felhasználót tároló adatrekord.

Innentől a jelenség kijavítása természetesen egyszerű ujjgyakorlat. A szóban forgó lekérdezésekkel érintett táblákat átalakítottam MyISAM formátumból tranzakció-biztos InnoDb formátumba, a különálló SQL utasításokat pedig egységbe foglaltam, vagyis BEGIN WORK és COMMIT utasítások közé helyeztem őket.

Láss csodát: volt hiba, nincs hiba.

Hogy miért írok erről külön bejegyzést?

Azért, mert ezzel most érdekes felfedezésre jutottam. A szóban forgó rendszer ugyanis a maga több ezer soros kódjával bár kétség kívül egy szorgos munkával összerakott projekt, amely egy darab felhasználóval tesztelve a professzionális kivitelezés látszatát kelti, de ennek ellenére olyan, a fentiekhez hasonló szarvashibáktól hemzseg, melyeket magam azért nem követnék el soha az életben, mert már a kezdetekben alapvető evidenciaként tanultam meg, hogy ügyelni kell ezekre a részletekre, ha nagyobb tömeget is ki akarunk szolgálni.

Akárki is készítette ezt a rendszert, legfeljebb kódolni tanult, de programozni soha.

Hasonló ez ahhoz a szituációhoz, mint amikor egy bizonyos, a webfejlesztés alapelveivel a jelek szerint szintén csak a saját tévhite szerint tisztában lévő kopasz blogger több felhasználói visszajelzés alapján eredetileg olyan blogrendszert fejlesztett a közössége számára, mely a bejelentkezett felhasználók jelszavait mindenféle titkosítás nélkül rakta ki sütibe (cookie). Már az is kiröhögni való megoldás, ha valaki teljességgel mellőzi a jelszavak hash-elését, de hogy ezt oda-vissza küldözgesse a felhasználó között, és még sütibe is írja, már tényleg a technikai kabaré netovábbja.

Mégis, a most általam kijavított PHP alapú rendszer fejlesztője akár több hónap kitartó munkájával összehozott valamit, melyhez nekem nem biztos, hogy lenne megfelelő türelmem, és ügyes üzleti érzékkel sikeresen áruba is bocsátotta.

Ami igazán meglepő számomra, hogy én, aki mindig is következetesen tartózkodtam attól, hogy úgymond informatikusnak nevezzem magam (csupán azt írtam le, hogy több megszerzett végzettségem elnevezésében benne van ez a szó, valamint hogy a folyamatban lévő egyetemi szakjaim többségének nevében úgyszintén szerepel) rendszeresen olyan megoldásokkal és megnyilvánulásokkal találkozom magukat magabiztosan informatikusnak és szoftverfejlesztőnek tituláló, de a valóságban szakmailag a nyomomba se érő emberek részéről, melyeket én soha nem követnék el, illetve amelyek láttán csak a fejemet fogom kínomban.

A lelkes amatőrök magabiztossága ennyit számítana az érvényesülés szempontjából? Mert ha igen, akár én magam is felhagyhatnék az eddigi tudatosan sugárzott szerénységgel, és istencsászárként pozícionálhatnám magam. xD

Mér' is ne, baszáj? Ennyi erővel. ;P

By SoDI


 
 
0 (0)
Jelentkezz be a szavazáshoz!