Nyereség:
- Lehetőség a lehetséges kiváltó okok gyors szűkítésére azáltal, hogy összeomlási rekordokat (veremnyomokat) ad a mesterséges intelligenciának a megfelelő kóddal és forgatókönyv-kontextussal
- Képesség a kiváltó ok végleges megoldására, ahelyett, hogy az AI diagnózisát hipotézisként validálná a kódban, valamint tesztelné és elnémítaná a tünetet
- A magánélet védelme hibakeresés közben a személyes adatok elrejtésével az összeomlási rekordokban és naplókban
Minden alkalmazás hibát ad; A jó fejlesztőt az különbözteti meg, hogy milyen gyorsan találja meg és javítja ki a hibákat. A mobil hibakeresés – a probléma forrásának megtalálása és kijavítása – különösen nehéz, mert a hiba a felhasználó eszközén, nem látható környezetben történik. Legtöbbször csak egy összeomlási naplóval rendelkezik (összeomlási napló / veremkövetés – annak technikai részlete, hogy az alkalmazás hová ment, amikor összeomlott). A mesterséges intelligencia rendkívül hatékonyan képes elolvasni ezeket a rejtélyes feljegyzéseket, felsorolni a lehetséges okokat, és megoldásokat javasolni. Ebben az egységben megtanuljuk, hogyan lehet az AI-t „hibanyomozóként” használni, de rád bízzuk a végső diagnózis és a javítás ellenőrzésének felelősségét.
Az összeomlási napló olvasása: ahol a mesterséges intelligencia a legfényesebben ragyog
Az ütközési napló hosszú és megfélemlítő szöveg; a tapasztalatlan fejlesztő nem fogja tudni, hol keressen. Az AI másodpercek alatt elemzi ezt a szöveget: melyik sorban ütközött, melyik kivételt dobták, mi lehet a lehetséges oka. A gyakori mobilhibák nyilvánvalóak, és a mesterséges intelligencia gyorsan felismeri őket: NullPointerException (null értékhez próbál hozzáférni), IndexOutOfBoundsException (nem létező listaelem elérése) Androidon, EXC_BAD_ACCESS (felszabadult memória elérése) iOS rendszeren, váratlanul talált nulla (ni kényszerítve).
A mobilösszeomlások leggyakoribb típusai és tipikus okai a következők:
Hiba (kivétel)
Platform
tipikus ok
NullPointerException
Android
Null érték elérése
IndexOutOfBoundsException
Android
Nem létező listaelem elérése
váratlanul nullára talált
iOS
A kicsomagolás kényszerítése nulla opcionális (!)
EXC_BAD_ACCESS
iOS
A felszabadult memória elérése
ANR/fagy
Android
Hosszú/erős feldolgozás a főszálon
Lépésről lépésre hibakeresési folyamat:
- Gyűjtsd össze a rekordot. Állítsa össze az összeomlási naplót, a hibaüzenetet és a reprodukáláshoz szükséges lépéseket, ha lehetséges.
- Adja meg az AI kontextust. Ne csak a hibát mondja el, hanem a vonatkozó kódrészletet és azt, hogy miként omlott össze.
- Kérdezze meg a lehetséges okokat. "Mondja el a 3 legvalószínűbb okot, és mindegyik ellenőrzésének módját."
- Ellenőrizze. Erősítse meg a javasolt okot a kódban és a tesztelésben; Ne találgatással javítsd ki.
- Javítsd ki és teszteld újra. Ellenőrizze, hogy a hiba valóban megszűnt-e, és nem keletkezett-e új hiba.
Tipp: Amikor átadja az összeomlási naplót az MI-nek, adja meg a megfelelő kódrészletet is. A mesterséges intelligencia csak a veremkövetéssel ad általános előrejelzést; Ha látja a kódot, nagymértékben megnő annak a valószínűsége, hogy megtalálja a pontos vonalat és a valódi okot. A kontextus határozza meg a diagnózis minőségét.
Személyes adatok csapdája
Az összeomlási naplók és naplók gyakran tartalmaznak felhasználói adatokat: e-mail címet, felhasználói azonosítót, helyet, sőt űrlaptartalmat is. Ennek a rekordnak az AI-be való beillesztése személyes adatok kiszivárogtatását jelenti harmadik félnek, és a KVKK/GDPR megsértését jelenti. A felvétel elküldése előtt tisztítsa meg (maszkolja le) a személyes területeket. Ügyeljen arra is, hogy ne írjon személyes adatokat az alkalmazás naplójába a kezdetektől fogva; Egy jó napló leírja a problémát, de nem fedi fel a személyazonosságot.
Figyelem: Az AI által javasolt javítás „elnémíthatja a hibát”, de nem oldja meg a kiváltó okot. Például, ha egy NullPointerException-t null-ellenőrzéssel burkol, leállítja az összeomlást, de ha nem derül ki, hogy az érték miért null, a tényleges logikai hiba továbbra is fennáll. A betegséget kezelje, ne a tünetet.
A kiváltó ok elemzése
A professzionális hibakeresés célja nem a hiba elhallgatása, hanem a kiváltó ok megtalálása. Megkérdeztem az AI-t, hogy "miért lehet ez nulla, hol veszhetett el az adatfolyamban?" azt kérdezi: "Hogyan tudom ezt elhallgattatni?" Sokkal értékesebb, mint kérni. A kiváltó ok megtalálása után ugyanannak a hibának több tucat változata egyszerre megoldódik. Az AI jó ebben a láncszemléletben: kövesse az adatokat a bemenettől a kimenetig, és kérje meg, hogy gondolja át, hol hibásodik meg.
három mini tok
1. eset – 2 óra munka 10 perc alatt. Egy fejlesztő 2 órát töltött egy olyan hiba keresésével, amely csak egy adott Samsung modellen omlott le. Átadta az ütközési naplót (személyes területek törlése) az MI-nek; YZ azt mondta, hogy a hiba memória túlcsordulásra utal, amely az eszköz eltérő kamerafelbontása esetén fordul elő. A nyomdal 10 perc alatt megtalálták az okot. Az AI felgyorsította a keresést, az ember ellenőrizte a megoldást.
2. eset – Az elhallgatott hiba visszatért. Az egyik csapat elhallgatott egy ismétlődő összeomlást egy mesterséges intelligencia-javaslat segítségével, hogy megpróbálja elkapni. Az összeomlás abbamaradt, de a felhasználók panaszkodni kezdtek, hogy "nem mennek az adatok"; mert az igazi probléma (adatbázis-kapcsolat) még mindig ott volt, csak éppen láthatatlanná vált. Miután megtalálták a kiváltó okot, az összeomlást és az adatvesztést is megoldották. Tanulság: az elhallgattatás nem megoldás.
3. eset – A naplóban kiszivárgott adatok. Az ellenőrzés megállapította, hogy a felhasználók teljes neve és telefonszáma bekerült az alkalmazás összeomlási naplójába. A fejlesztők rendszeresen beillesztették ezeket a naplókat az AI-ba, és javították a hibákat; A személyes adatok tehát hónapok óta mennek ki. A naplókat elfedték, és a folyamatot kijavították. Tanulság: a titoktartás még hibakereséskor is érvényes.
Gyenge felszólítás / Erős felszólítás
Gyenge figyelmeztetés: "Miért fordul elő ez a hiba? [verem nyomkövetése]"
Erős felszólítás: "Ez az összeomlás az Android-alkalmazásomban történik. Kontextus:- A művelet közben: a felhasználó kosárba helyezi a termék részleteiből - Csak bizonyos eszközökön, alacsony RAM-mal rendelkező modelleken - Kapcsolódó kód: [ViewModel and Repository part] - Összeomlási napló (a személyes adatok törölve): [verem nyomon követése] Sorolja fel a 3 legvalószínűbb kiváltó okot. Mindegyiknél:1) Hogyan javítsam ki a pontosítást. feltételezés, ahol nem vagy biztos benne."
Másolható sablonok
Összeomláselemző sablon:"Elemezze a következő összeomlást. Kontextus: [mit csinál, melyik eszköz/verzió]. Releváns kód: [kód]. Összeomlási napló (a személyes adatok törölve): [nyom]. Adjon meg 3 legvalószínűbb kiváltó okot és ellenőrzést + végleges javítást mindegyikhez. Jelölje meg azokat a megoldásokat is, amelyek elnémítják a tünetet."
Gyári ok sablon: "Ez az érték váratlanul [null/false]. Kövesse az adatfolyamot a bemenettől egészen idáig: hol veszhet el vagy sérülhet meg? Mondja meg, hol kell ellenőrizni az egyes szakaszokban. [kód]"
Naplóolvasási sablon: "A naplókimenet értelmezése: milyen események történtek sorrendben, hol a rendellenesség, mi volt az utolsó egészséges lépés a hiba előtt? [napló - a személyes adatok törlése]"
Reprodukciós sablon: "Milyen lépésekkel, eszközállapotokkal és adatokkal kell megpróbálnom megbízhatóan reprodukálni ezt a hibát? Sorolja fel valószínűségi sorrendben azokat a körülményeket, amelyek kiválthatják a hibát. [leírás]"
Gyakori hibák
- Kontextusmentes veremkövetés biztosítása. Releváns kód és forgatókönyv nélkül az AI általános jóslatokat készít.
- Személyes adatok beillesztése az AI-ba a naplókkal együtt. A titoktartás megsértése; először maszk.
- Csendesítse a tünetet. Az összeomlás try-catch segítségével való elrejtése elhagyja a gyökér problémát, és új problémákat okoz.
- Az első javaslat alkalmazása ellenőrzés nélkül. Az AI diagnózisa hipotézis; Erősítse meg a kódban.
- Megpróbálja reprodukálni az emulátorban. Egyes hibák csak a tényleges eszközön/állapoton jelennek meg.
- Javítás után nem tesztelik újra. A javítás valami mást is eltörhetett; Ellenőrizze a regressziót.
Összefoglalva
Az egyik olyan terület, ahol a mesterséges intelligencia kiváló, az összeomlási naplók olvasása és a lehetséges okok feltárása; A diagnózis minősége nagymértékben javul, ha megadjuk a kontextust. De a végső diagnózis és korrekció az emberé: az AI javaslata egy hipotézis, amelyet kóddal és teszteléssel igazolnak. A cél nem a tünet elhallgatása, hanem a kiváltó ok megoldása; Az elhallgatott hiba általában más formában tér vissza. Az összeomlási naplók személyes adatokat tartalmazhatnak; Maszkolja le, mielőtt átadná az MI-nek, és ne írjon be személyes adatokat a naplójába a kezdetektől fogva.
Pályázati feladat
Készítsen egy összeomlási naplót (vagy az AI-ból generált mintát), takarja el a benne lévő személyes/megkülönböztető adatokat, és adja át az AI-nak a „Crash analysis template”-vel. Különböztesse meg, hogy a kiváltó okok közül melyek az AI-listák tényleges javítások, és melyek az elnémítás. Alkalmazza a választott állandó javítást, és ellenőrizze, hogy a hiba megszűnt-e, és nem merülnek fel új problémák.
ellenőrző lista
- [ ] Megadtam az összeomlási naplót a megfelelő kóddal és forgatókönyv-kontextussal
- [ ] A naplókban elrejtettem a személyes/megkülönböztető adatokat
- [ ] Az AI kiváltó okát és végleges javítását kértem, nem elnémítást
- [ ] A diagnózist kódban és tesztelésben igazoltam, nem vakon alkalmaztam
- [ ] A javítás után teszteltem, hogy a hiba megszűnt, és nincs regresszió
- [ ] Ellenőriztem, hogy az alkalmazásom nem ír-e be személyes adatokat a naplóiba