Hibajelentések és naplózás fejlesztése frissítések során

Hiba javítása online alkalmazásban

A Hiba javítása akkor működik jól, ha a magánügyfél pontosan leírja, mi romlott el, a szakember pedig nem találgat, hanem ellenőrzi a hibát, a naplókat és a működési környezetet. Egy online feladatnál ez különösen fontos, mert nincs személyes jelenlét. A fejlesztő képernyőképekből, hibajelentésekből, hozzáférésekből, tesztadatokból és naplóbejegyzésekből dolgozik. Én azt látom, hogy a legtöbb félreértés nem a javítás közben jön elő, hanem már az első leírásnál. Ha a megbízó csak annyit ír, hogy nem működik az oldal vagy lefagy az alkalmazás, abból még nem lehet megbízható árat, határidőt és megoldási tervet adni.

A magánügyfeleknek általában nem teljes fejlesztői csapatra van szükségük. Gyakran elég egy tapasztalt szabadúszó, aki megkeresi a hibát, kijavítja a problémás részt, majd röviden leírja, mit változtatott. A Qjob.hu felületén ilyen feladatra is lehet önálló szakembert keresni, ha a munka távolról elvégezhető és a feladat határai érthetők. A lényeg nem az, hogy a hiba neve szakszerű legyen. Az a fontos, hogy a jelenség ismételhető legyen, vagy legalább legyen elég adat a vizsgálathoz.

Hibajavítás és hibakeresés különbsége

A hibajavítás nem mindig egyetlen gyors kódsor átírása. Sokszor előbb hibakeresés kell, mert a látható gond csak következmény. Lehet, hogy egy gomb nem menti el az adatot, de a háttérben jogosultsági hiba, adatbázisprobléma, rossz űrlapellenőrzés vagy külső szolgáltatás hibája áll. Tapasztalatom szerint az ügyfél akkor jár jobban, ha nem csak a tünet eltüntetését kéri, hanem azt is, hogy a fejlesztő ellenőrizze az okot.

A javítás általában konkrét változtatás. A hibakeresés inkább feltárás. Ez lehet rövid, ha a szakember látja a hibát és gyorsan eléri a naplókat. De lehet hosszabb is, ha a gond csak bizonyos böngészőben, bizonyos készüléken vagy ritka felhasználói lépésnél jelenik meg. Szerintem itt nem érdemes túl szűken gondolkodni. Ha a hiba üzleti folyamatot érint, például rendelést, fizetést, regisztrációt vagy üzenetküldést, akkor a kiváltó ok legalább annyira fontos, mint maga a látható javítás.

Volt olyan eset, amikor egy ügyfél azt hitte, hogy csak egy űrlap gombja hibás. A fejlesztő rövid vizsgálat után látta, hogy a naplózás sem működik rendesen, ezért a rendszer nem mutatta meg, miért nem mentek el az adatok. A tényleges munka így két részből állt. Először rendbe kellett tenni a hibajelentést, utána lehetett biztonságosan javítani az űrlapot. Ez nem látványos munka, de nélküle a hiba később visszatért volna.

Hiba javítása árak távoli munkánál

A Hiba javítása ára attól függ, mennyire ismételhető a probléma, milyen rendszerhez kell hozzáférni, van e naplózás, és kell e utólagos tesztelés. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent. Nem azért, mert minden drága ajánlat jobb. Hanem azért, mert a hibakeresés időt kér. Ha valaki látatlanban nagyon alacsony árat mond egy összetett alkalmazáshibára, akkor lehet, hogy csak a felszínt fogja javítani.

Ezek az összegek irányadó díjak távoli munkára. Egy egyszerű felületi hiba ára nem hasonlítható egy olyan hibához, amely adatvesztést vagy fizetési gondot okozhat. Én azt tartom korrektnek, ha a szakember először külön jelzi a vizsgálat díját, majd a javítás várható költségét. Így a megbízó nem fizet vakon egy nagyobb munkáért, a fejlesztő pedig nem vállal irreális kockázatot.

Megfelelő szakember hibajavításhoz

A jó szakember nem csak azt kérdezi meg, hol fáj a rendszer. Meg akarja érteni, mikor jelentkezik a hiba, kiket érint, volt e frissítés, és milyen lépések után történik a gond. Ez elsőre lassabbnak tűnhet, de távoli munkánál ez ad biztonságot. Ha valaki azonnal belépést kér mindenhová, és nem kér pontos leírást, az nálam intő jel.

Magánügyfélként érdemes olyan fejlesztőt választani, aki tud röviden és világosan kommunikálni. Nem kell mindent műszaki nyelven megmagyaráznia. De tudnia kell elmondani, hogy mi volt a hiba oka, mi változott, és mire kell figyelni a jövőben. A portfólió hasznos, de hibajavításnál a gondolkodásmód még fontosabb. Egy szép referenciaoldal nem bizonyítja, hogy a szakember tud naplókat olvasni, hibát ismételni vagy kockázatot mérni.

Érdemes rákérdezni arra is, hogyan kezeli a hozzáféréseket. Jelszót nem jó üzenetben küldeni, és nem szerencsés korlátlan hozzáférést adni mindenhez. A megbízó kérhet ideiglenes fiókot, korlátozott jogosultságot vagy külön tesztkörnyezetet. Ez nem bizalmatlanság. Ez normális munkarend.

Hibajelentés és naplózás javítása

A hibajelentés és naplózás javítása sokszor láthatatlan, mégis fontos része a munkának. Ha nincs napló, a szakember nehezebben látja, mi történt a háttérben. Ha a napló túl kevés adatot tartalmaz, akkor csak általános hibák látszanak. Ha túl sok érzékeny adat kerül bele, az adatvédelmi és biztonsági gondot okozhat. Itt finom egyensúly kell.

Egy jó naplózás megmutatja az időpontot, a hibás folyamatot, a felhasználói lépést, a kiszolgáló válaszát és a hiba súlyát. Nem kell mindent örökre tárolni. De a legfontosabb eseményeket követni kell. Hibajavítás közben a fejlesztő gyakran először ezt nézi meg. Ha nincs használható adat, akkor tesztelnie kell, ismételnie kell a lépéseket, és több idő megy el a feltárásra.

Sokan ott hibáznak, hogy csak akkor kezdenek naplózással foglalkozni, amikor már komoly baj van. Pedig egy egyszerűbb hibajelentési rendszer is sokat segít. Nem kell nagy céges megoldás minden kisebb alkalmazáshoz. Elég lehet egy átlátható eseménynapló, e mailes értesítés fontos hibákról, vagy egy külön lista az összeomlásokról és sikertelen műveletekről.

Online munkafolyamat és átadás

Távoli hibajavításnál a munkafolyamat akkor tiszta, ha a megbízó és a szakember már az elején megállapodik a hozzáférésekről, az első vizsgálat határáról, a kommunikáció módjáról és az átadás formájáról. Ez lehet üzenetváltás, rövid videó, képernyőkép vagy írásos összefoglaló. A lényeg, hogy a javítás ne csak kész legyen, hanem ellenőrizhető is legyen.

Az első lépés a hiba leírása. Jó, ha tartalmazza a hibás oldal vagy képernyő nevét, a pontos lépéseket, a várható eredményt és a tényleges hibát. A második lépés a vizsgálat. Itt a fejlesztő megnézi a kódot, a naplókat, a környezetet és a frissítéseket. A harmadik lépés a javítás vagy javaslat. Nem minden esetben érdemes azonnal kódot módosítani. Néha előbb mentés, tesztverzió vagy jóváhagyás kell.

Az átadásnál legyen rövid leírás arról, mi változott. Nem kell hosszú műszaki dokumentum, de a megbízónak tudnia kell, melyik hiba javult, milyen teszt történt, és maradt e nyitott kockázat. Ha a szakember csak annyit ír, hogy kész, az kevés. Főleg akkor, ha a gond később ismét előjöhet más körülmények között.

Tipikus hibák a megbízás előtt

A Hiba javítása előtt a leggyakoribb ügyfélhiba a túl kevés információ. A második a sürgetés. A harmadik az, hogy a megbízó több különböző problémát egyetlen apró feladatként ír le. Érthető, hogy mindenki gyors megoldást szeretne, de egy hibás alkalmazásnál a kapkodás további gondot hozhat. Szerintem jobb egy rövid, pontos induló leírás, mint tíz hiányos üzenet.

Az is gond, ha a megbízó nem készít mentést, mielőtt hozzáférést ad. Egy jó szakember erre rákérdez, de a felelősség közös. Ha éles rendszerben történik a javítás, akkor különösen fontos, hogy legyen visszaállítási lehetőség. Nem azért, mert a fejlesztő biztosan hibázik. Hanem azért, mert a rendszerek néha váratlanul viselkednek.

Másik gyakori hiba a túl homályos elvárás. A megbízó azt mondja, hogy legyen stabilabb az alkalmazás, de nem mondja meg, hol fagy, mikor lassú, vagy melyik folyamat sérül. Ilyenkor a szakember csak találgat. Jobb konkrét példákat adni. Például a regisztráció után nem érkezik levél, a kosár törlődik frissítéskor, vagy a profilkép feltöltése után üres képernyő jelenik meg.

Minőségi javítás és utóellenőrzés

A minőségi javítás nem csak abból áll, hogy a hiba eltűnik. Fontos, hogy ne keletkezzen új probléma, a változás ne rontsa el a kapcsolódó funkciókat, és a megbízó értse, mit kapott. Egy szabadúszó fejlesztő akkor dolgozik jól, ha nem terheli túl a magyarázatot, de nem is hagyja bizonytalanságban az ügyfelet.

Az utóellenőrzés lehet rövid próba, több böngészős ellenőrzés, alapvető adatmentési teszt vagy ismételt hibanapló figyelés. Ez függ a feladattól. Egy kis felületi gondnál elég lehet egy gyors ellenőrzés. Egy fizetési, belépési vagy adatkezelési hibánál sokkal komolyabb teszt kell. A hibaelhárítás itt nem külön luxus, hanem a munka része.

Én azt látom, hogy a jó eredményhez három dolog kell. Pontos hiba, megfelelő hozzáférés és nyugodt ellenőrzés. Ha ezek megvannak, a távoli javítás hatékony tud lenni. Ha valamelyik hiányzik, a munka drágább, lassabb vagy bizonytalanabb lesz. A megbízó részéről ez nem műszaki tudást igényel, hanem rendezett információt. A szakember részéről pedig türelmet, fegyelmet és érthető kommunikációt.