Voitot:
- Kyky rajata nopeasti mahdollisia perimmäisiä syitä antamalla kaatumistietueet (pinojäljet) tekoälylle asianmukaisella koodi- ja skenaariokontekstilla
- Kyky ratkaista pysyvästi perimmäinen syy sen sijaan, että validoisit tekoälyn diagnoosin hypoteesina koodissa ja testaamaan ja vaientamaan oiretta
- Yksityisyyden suojaaminen virheenkorjauksen aikana peittämällä henkilötiedot kaatumistietueissa ja lokeissa
Jokainen sovellus antaa virheitä; Hyvän kehittäjän erottamiskyky on se, kuinka nopeasti hän löytää ja korjaa vikoja. Mobiilivirheenkorjaus – ongelman lähteen löytäminen ja korjaaminen – on erityisen vaikeaa, koska virhe tapahtuu käyttäjän laitteessa ympäristössä, jota et näe. Useimmiten sinulla on vain kaatumisloki (kaatumisloki / pinojäljitys – tekninen erittely siitä, minne sovellus meni, kun se kaatui). Tekoäly on erittäin tehokas lukemaan näitä salaperäisiä tietueita, luettelemaan mahdollisia syitä ja ehdottamaan ratkaisuja. Tässä osiossa opimme käyttämään tekoälyä "vikaetsivänä", mutta jätämme sinulle vastuun lopullisen diagnoosin ja korjauksen vahvistamisesta.
Törmäyslokin lukeminen: Missä tekoäly loistaa kirkkaimmin
Törmäysloki on pitkä ja pelottava teksti; kokematon kehittäjä ei tiedä mistä etsiä. Tekoäly jäsentää tämän tekstin sekunneissa: millä rivillä se kaatui, mikä poikkeus heitettiin, mikä on mahdollinen syy. Yleiset mobiilivirheet ovat ilmeisiä, ja tekoäly tunnistaa ne nopeasti: NullPointerException (yrittää päästä käsiksi nolla-arvoon), IndexOutOfBoundsException (olemattoman luetteloelementin käyttö) Androidissa, EXC_BAD_ACCESS (vapautetun muistin käyttö) iOS:ssä, yllättäen löydetty nolla (pakottaa ni).
Yleisimmät matkapuhelimen kaatumistyypit ja niiden tyypilliset syyt ovat seuraavat:
Virhe (poikkeus)
Alusta
tyypillinen syy
NullPointerException
Android
Nolla-arvon käyttäminen
IndexOutOfBoundsException
Android
Käytetään olematonta luetteloelementtiä
yllättäen löytyi nollasta
iOS
Pakota purkaminen nolla valinnainen (!)
EXC_BAD_ACCESS
iOS
Vapautetun muistin käyttö
ANR/jäädytys
Android
Pitkä/raskas käsittely pääkierteessä
Vianetsintä vaihe vaiheelta:
- Kerää tietue. Kokoa kaatumisloki, virhesanoma ja vaiheet sen toistamiseksi, jos mahdollista.
- Anna tekoälykonteksti. Kerro minulle, ei vain virhe, vaan asiaankuuluva koodinpätkä ja mitä se kaatui tekemässä.
- Kysy mahdollisia syitä. "Kerro minulle 3 todennäköisintä syytä ja kuinka jokainen varmistetaan."
- Vahvista. Vahvista ehdotettu syy koodissa ja testauksessa; Älä korjaa sitä arvaamalla.
- Korjaa ja testaa uudelleen. Tarkista, että virhe on todella poissa eikä uusia virheitä synny.
Vinkki: Kun annat kaatumislokin tekoälylle, sisällytä myös asiaankuuluva koodinpätkä. Vain pinojäljityksen avulla tekoäly tekee yleisen ennusteen; Kun näet koodin, todennäköisyys löytää tarkka viiva ja todellinen syy kasvaa huomattavasti. Konteksti määrää diagnoosin laadun.
Henkilötietojen ansa
Kaatumislokit ja lokit sisältävät usein käyttäjätietoja: sähköpostiosoitetta, käyttäjätunnusta, sijaintia, jopa lomakkeen sisältöä. Tämän tietueen liittäminen tekoälyyn sellaisenaan vuotaa henkilötietoja kolmannelle osapuolelle ja on KVKK:n/GDPR:n vastaista. Puhdista (naamio) henkilökohtaiset alueet ennen tallenteen lähettämistä. Varo myös, ettet kirjoita henkilökohtaisia tietoja sovelluksesi lokeihin alusta alkaen. Hyvä loki kuvaa ongelmaa, mutta ei paljasta henkilöllisyyttä.
Varoitus: Tekoälyn ehdottama korjaus saattaa "hiljentää virheen", mutta ei välttämättä ratkaise perimmäistä syytä. Esimerkiksi NullPointerExceptionin kääriminen nolla-tarkistukseen pysäyttää kaatumisen, mutta jos et ymmärrä, miksi arvo on nolla, varsinainen logiikkavirhe jatkuu. Hoida sairautta, älä oireita.
Perussyyanalyysi
Ammattimaisen virheenkorjauksen tavoitteena ei ole hiljentää virhettä vaan löytää perimmäinen syy. Kysyin tekoälyltä "miksi tämä voi olla tyhjä, mihin se on voinut kadota tietovirrassa?" kysyy: "Kuinka hiljentän tämän?" Se on paljon arvokkaampaa kuin kysyminen. Kun perimmäinen syy on löydetty, kymmeniä saman virheen muunnelmia ratkaistaan kerralla. Tekoäly on hyvä tässä ketjuperustelussa: seuraa dataa syötteestä lähtöön ja pyydä sitä miettimään, missä se hajoaa.
kolme minilaukkua
Tapaus 1 – 2 tuntia työtä 10 minuutissa. Kehittäjä vietti 2 tuntia etsiessään vikaa, joka kaatui vain tietyssä Samsung-mallissa. Antoi törmäyslokin (henkilökohtaisten alueiden tyhjennys) tekoälylle; YZ sanoi, että virhe viittaa muistin ylivuotoon, joka tapahtuu kyseisen laitteen erilaisella kameran resoluutiolla. Vihjeen avulla syy löytyi 10 minuutissa. Tekoäly nopeutti hakua, ihminen vahvisti ratkaisun.
Tapaus 2 – Vaimennettu bugi on palannut. Yksi tiimi hiljensi toistuvan kaatumisen käyttämällä tekoälyehdotusta yrittääkseen saada sen kiinni. Kaatuminen loppui, mutta käyttäjät alkoivat valittaa, että "tietoja ei tallenneta"; koska todellinen ongelma (tietokantayhteys) oli edelleen olemassa, se oli juuri muuttunut näkymättömäksi. Kun perimmäinen syy löydettiin, sekä kaatuminen että tietojen menetys korjattiin. Oppitunti: hiljentäminen ei ratkaise.
Tapaus 3 – Tiedot vuotaneet lokiin. Tarkastuksessa havaittiin, että käyttäjien täydelliset nimet ja puhelinnumerot kirjoitettiin sovelluksen kaatumislokiin. Kehittäjät liittivät nämä lokit rutiininomaisesti tekoälyyn ja korjasivat vikoja; Henkilötietoja on siis kadonnut kuukausia. Lokit peitettiin ja prosessi korjattiin. Oppitunti: luottamuksellisuus koskee myös virheenkorjausta.
Heikko kehote / Vahva kehote
Huono kehote: "Miksi tämä virhe tapahtuu? [pinon jäljitys]"
Voimakas kehote: "Tämä kaatuminen tapahtuu Android-sovelluksessani. Konteksti: - Tekemisen aikana: käyttäjä lisää ostoskoriin tuotetiedoista - Vain joissakin laitteissa, vähän RAM-muistia sisältävät mallit - Aiheeseen liittyvä koodi: [ViewModel and Repository part] - Kaatumisloki (henkilötiedot tyhjennetty): [pinon jäljitys]Luettelo 3 todennäköisintä perimmäistä syytä. Jokaiselle:1) Kuinka en korjaa (hiljentäminen) 2. olettamus, jossa et ole varma."
Kopioitavat mallit
Kaatumisanalyysimalli:"Analysoi seuraava kaatuminen. Konteksti: [mitä olet tekemässä, mikä laite/versio]. Asiaankuuluva koodi: [koodi]. Kaatumisloki (henkilötiedot tyhjennetty): [jälki]. Anna kullekin kolme todennäköisintä perimmäistä syytä ja vahvistus + pysyvä korjaus. Merkitse myös oireen hiljentävät kiertotavat."
Pääsyymalli: "Tämä arvo tulee [null/false] odottamatta. Seuraa tiedonkulkua syötteestä tähän pisteeseen: missä se voi kadota tai vioittua? Kerro minulle, mistä minun tulee tarkistaa kussakin vaiheessa. [koodi]"
Lokinlukumalli: "Tulkitse tämä lokituloste: mitkä tapahtumat tapahtuivat järjestyksessä, missä on poikkeama, mikä oli viimeinen terve vaihe ennen virhettä? [loki — henkilötiedot tyhjennetty]"
Toistomalli: "Mitä vaiheita, laitteen tiloja ja tietoja pitäisi yrittää toistaa tämä virhe luotettavasti? Listaa olosuhteet, jotka voivat laukaista virheen todennäköisyysjärjestyksessä. [kuvaus]"
Yleisiä virheitä
- Antaa yhteydettömän pinojäljityksen. Ilman asiaankuuluvaa koodia ja skenaariota tekoäly tekee yleisen ennusteen.
- Henkilötietojen liittäminen tekoälyyn lokien kanssa. Luottamuksellisuuden rikkominen; naamio ensin.
- Hiljennä oire. Törmäyksen piilottaminen try-catchilla jättää pääongelman ja luo uusia ongelmia.
- Ensimmäisen ehdotuksen soveltaminen vahvistamatta sitä. Tekoälyn diagnoosi on hypoteesi; Vahvista koodissa.
- Yritetään toistaa se emulaattorissa. Jotkut virheet näkyvät vain todellisessa laitteessa/kunnossa.
- Ei testata uudelleen korjauksen jälkeen. Korjaus on saattanut rikkoa jotain muuta; Tarkista regressio.
Yhteenvetona
Yksi alueista, joilla tekoäly loistaa, on kaatumislokien lukeminen ja mahdollisten syiden selvittäminen; Diagnoosin laatu paranee huomattavasti, kun konteksti annetaan. Mutta lopullinen diagnoosi ja korjaus kuuluu ihmiselle: tekoälyn ehdotus on hypoteesi, joka on vahvistettu koodilla ja testauksella. Tavoitteena ei ole hiljentää oiretta, vaan ratkaista perimmäinen syy; Vaimennettu virhe yleensä palautuu toisessa muodossa. Kaatumislokit voivat sisältää henkilötietoja; Peitä se ennen kuin annat sen tekoälylle, äläkä kirjoita henkilötietoja lokiisi alusta alkaen.
Sovellustehtävä
Ota olemassa oleva kaatumisloki (tai tekoälystä luomasi näyte), peitä siinä kaikki henkilökohtaiset/erottelevat tiedot ja anna se tekoälylle "Crash analysis template" -mallin avulla. Erottele, mitkä AI-luettelot ovat todellisia korjauksia ja mitkä vain hiljentämistä. Käytä valitsemaasi pysyvää korjausta ja varmista, että virhe on kadonnut eikä uusia ongelmia esiinny.
tarkistuslista
- [ ] Olen antanut kaatumislokin asianmukaisella koodilla ja skenaariokontekstilla
- [ ] Peittelin lokeihin henkilökohtaiset/erottelevat tiedot
- [ ] Pyysin tekoälyä perimmäistä syytä ja pysyvää korjausta, en hiljentämistä
- [ ] Varmistin diagnoosin koodissa ja testauksessa, en soveltanut sitä sokeasti
- [ ] Korjauksen jälkeen testasin, että virhe oli poissa eikä regressiota tapahtunut
- [ ] Tarkistin, että sovellukseni ei kirjoita henkilötietoja lokeihinsa