Gevinster:
- Evne til raskt å begrense mulige grunnårsaker ved å gi krasjposter (stackspor) til kunstig intelligens med relevant kode og scenariokontekst
- Evne til permanent å løse årsaken i stedet for å validere AI-diagnosen som en hypotese i kode og testing og demping av symptomet
- Beskytter personvernet mens du feilsøker ved å maskere personlige data i krasjposter og logger
Hver applikasjon gir feil; Det som kjennetegner en god utvikler er hvor raskt de finner og fikser feil. Mobil feilsøking – å finne og fikse kilden til et problem – er spesielt vanskelig fordi feilen oppstår på brukerens enhet, i et miljø du ikke kan se. Mesteparten av tiden er alt du har en krasjlogg (krasjlogg / stabelsporing - en teknisk oversikt over hvor applikasjonen gikk da den krasjet). AI er ekstremt kraftig til å lese disse kryptiske postene, liste opp mulige årsaker og foreslå løsninger. I denne enheten vil vi lære hvordan du bruker AI som en "bug-detektiv", men overlater deg med ansvaret for å verifisere den endelige diagnosen og fikse.
Leser krasjloggen: Der AI lyser sterkest
En krasjlogg er en lang og skremmende tekst; uerfaren utvikler vet ikke hvor de skal lete. AI analyserer denne teksten på sekunder: på hvilken linje den krasjet, hvilket unntak ble kastet, hva er den mulige årsaken. Vanlige mobilfeil er åpenbare og AI gjenkjenner dem raskt: NullPointerException (prøver å få tilgang til en nullverdi), IndexOutOfBoundsException (tilgang til et ikke-eksisterende listeelement) på Android, EXC_BAD_ACCESS (tilgang til frigjort minne) på iOS, uventet funnet null (tvinger en null).
De vanligste typene mobilkrasj og deres typiske årsaker er som følger:
Feil (unntak)
Plattform
typisk årsak
NullPointerException
Android
Få tilgang til en nullverdi
IndexOutOfBoundsException
Android
Tilgang til ikke-eksisterende listeelement
uventet funnet null
iOS
Tving utpakking av en null valgfri (!)
EXC_BAD_ACCESS
iOS
Få tilgang til frigjort minne
ANR/frys
Android
Lang/tung bearbeiding på hovedtråd
Trinn for trinn feilsøkingsflyt:
- Samle rekorden. Sett sammen krasjloggen, feilmeldingen og trinnene for å reprodusere den hvis mulig.
- Gi AI-konteksten. Fortell meg ikke bare feilen, men den relevante kodebiten og hva den krasjet.
- Spør etter mulige årsaker. "Fortell meg de 3 mest sannsynlige årsakene og hvordan du kan bekrefte hver."
- Verifisere. Bekreft den foreslåtte årsaken i kode og testing; Ikke fiks det ved å gjette.
- Fiks det og test på nytt. Sjekk at feilen faktisk er borte og at det ikke genereres nye feil.
Tips: Når du gir krasjloggen til AI, ta med den relevante kodebiten også. Kun med stacksporing gjør AI generell prediksjon; Når du ser koden, øker sannsynligheten for å finne den eksakte linjen og den virkelige årsaken betraktelig. Kontekst bestemmer kvaliteten på diagnosen.
Persondatafelle
Krasjlogger og logger inneholder ofte brukerdata: e-post, bruker-ID, plassering, til og med skjemainnhold. Å lime inn denne posten i AI-en som den er, lekker personopplysninger til tredjeparten og er et brudd på KVKK / GDPR. Rydd (masker) personlige områder før du sender inn opptaket. Vær også forsiktig så du ikke skriver personlige data til programmets logger fra begynnelsen; En god logg beskriver problemet, men avslører ikke identiteten.
Forsiktig: Reparasjonen foreslått av AI kan "dempe feilen", men løser kanskje ikke årsaken. Hvis du for eksempel bryter en NullPointerException med en null-sjekk, vil krasjen stoppe, men hvis du ikke finner ut hvorfor verdien er null, vil den faktiske logiske feilen fortsette. Behandle sykdommen, ikke symptomet.
Grunnårsaksanalyse
Målet med profesjonell feilsøking er ikke å dempe feilen, men å finne årsaken. Jeg spurte AI "hvorfor kan dette være null, hvor kan det ha blitt borte i dataflyten?" spør, "hvordan gjør jeg dette til taushet?" Det er mye mer verdifullt enn å spørre. Når hovedårsaken er funnet, løses dusinvis av varianter av samme feil på en gang. AI er god på dette kjederesonnementet: følg dataene fra input til output og be den tenke på hvor den brytes ned.
tre minisaker
Case 1 — 2 timers arbeid på 10 minutter. En utvikler brukte 2 timer på å søke etter en feil som kun krasjet på en spesifikk Samsung-modell. Ga krasjloggen (rydde personlige områder) til AI; YZ sa at feilen peker på et minneoverløp som oppstår med en annen kameraoppløsning på den enheten. Med ledetråden ble årsaken funnet på 10 minutter. AI akselererte søket, mennesket bekreftet løsningen.
Tilfelle 2 - Den lydløse feilen er tilbake. Ett team dempet et tilbakevendende krasj ved å bruke et AI-forslag for å prøve å fange det. Krasj stoppet, men brukere begynte å klage over at "data ikke lagres"; fordi det virkelige problemet (databaseforbindelsen) fortsatt var der, var det akkurat blitt usynlig. Når rotårsaken ble funnet, ble både krasj og datatap løst. Leksjon: lydløsing løser ikke.
Tilfelle 3 — Data lekket i logg. En revisjon fant at brukernes fulle navn og telefonnummer ble skrevet inn i appens krasjlogger. Utviklere limte rutinemessig inn disse loggene i AI og fikset feil; Så personopplysninger har gått ut i flere måneder. Logger ble maskert og prosessen ble korrigert. Leksjon: konfidensialitet gjelder selv ved feilsøking.
Svak forespørsel / Sterk forespørsel
Dårlig melding: "Hvorfor oppstår denne feilen? [stakksporing]"
Sterk melding: "Denne krasjen skjer i Android-appen min. Kontekst:- Mens du gjør: bruker legger til handlekurv fra produktdetalj- Bare på enkelte enheter, modeller med lite RAM- Relatert kode: [ViewModel and Repository-del]- Krasjlogg (personlige data slettet): [stacksporing]Liste de 3 mest sannsynlige grunnårsakene. For hver:1) How do I verify your silenct. antagelse hvor du ikke er sikker."
Kopierbare maler
Krasjanalysemal: "Analyser følgende krasj. Kontekst: [hva du gjør, hvilken enhet/versjon]. Relevant kode: [kode]. Krasjlogg (personlige data slettet): [sporing]. Gi 3 mest sannsynlige grunnårsaker og bekreftelse + permanent løsning for hver. Merk også løsninger som demper symptomet."
Grunnårsaksmal: "Denne verdien kommer uventet [null/false. Følg dataflyten fra inngangen til dette punktet: hvor kan den gå tapt eller ødelagt? Fortell meg hvor jeg bør sjekke på hvert trinn. [kode]"
Lesemal for logg: "Tolk denne loggutgangen: hvilke hendelser skjedde i rekkefølge, hvor er unormaliteten, hva var det siste friske trinnet før feilen? [logg — personlige data slettet]"
Reproduksjonsmal: "Hvilke trinn, enhetstilstander og data bør jeg prøve å reprodusere denne feilen på en pålitelig måte? List opp forholdene som kan utløse feilen i rekkefølge etter sannsynlighet. [beskrivelse]"
Vanlige feil
- Gir kontekstfri stabelsporing. Uten relevant kode og scenario gir AI generell prediksjon.
- Lim inn personlige data i AI sammen med logger. Brudd på konfidensialitet; maske først.
- Demp symptomet. Å skjule krasj med try-catch etterlater rotproblemet og skaper nye problemer.
- Bruker det første forslaget uten å bekrefte det. Diagnosen AI er en hypotese; Bekreft i kode.
- Prøver å reprodusere det i emulatoren. Noen feil vises kun på den faktiske enheten/tilstanden.
- Tester ikke på nytt etter korrigering. Reparasjonen kan ha ødelagt noe annet; Sjekk regresjon.
Oppsummert
Et av områdene hvor AI utmerker seg er å lese krasjlogger og sortere ut mulige årsaker; Kvaliteten på diagnosen er sterkt forbedret når konteksten er gitt. Men den endelige diagnosen og korreksjonen tilhører mennesket: AIs forslag er en hypotese, verifisert i kode og testing. Målet er ikke å dempe symptomet, men å løse grunnårsaken; Den lydløse feilen kommer vanligvis tilbake i en annen form. Krasjlogger kan inneholde personlige data; Mask det før du gir det til AI og ikke skriv personlige data i loggene dine fra begynnelsen.
Søknadsoppgave
Ta en krasjlogg du har (eller prøven du genererer fra AI-en), masker eventuelle personlige/karakteristiske data i den, og gi den til AI-en med "Crash-analysemalen". Skille hvilke av grunnårsakene til AI-listene som er faktiske rettelser og hvilke som bare demper. Bruk den permanente løsningen du valgte og kontroller at feilen er borte og at det ikke oppstår nye problemer.
sjekkliste
- [ ] Jeg har gitt krasjloggen med relevant kode og scenariokontekst
- [ ] Jeg maskerte personlige/karakteristiske data i loggene
- [ ] Jeg spurte AI om rotårsak og permanent løsning, ikke lyddemping
- [ ] Jeg bekreftet diagnosen i kode og testing, jeg brukte den ikke blindt
- [ ] Etter reparasjonen testet jeg at feilen var borte og at det ikke var noen regresjon
- [ ] Jeg sjekket at applikasjonen min ikke skriver personopplysninger i loggene