Zyski:
- Możliwość szybkiego zawężenia możliwych przyczyn źródłowych poprzez udostępnienie sztucznej inteligencji zapisów awarii (śladów stosu) z odpowiednim kodem i kontekstem scenariusza
- Możliwość trwałego rozwiązania pierwotnej przyczyny zamiast weryfikowania diagnozy sztucznej inteligencji jako hipotezy w kodzie oraz testowania i wyciszania symptomów
- Ochrona prywatności podczas debugowania poprzez maskowanie danych osobowych w rejestrach i dziennikach awarii
Każda aplikacja generuje błędy; To, co wyróżnia dobrego programistę, to szybkość znajdowania i naprawiania błędów. Debugowanie mobilne — znalezienie i naprawienie źródła problemu — jest szczególnie trudne, ponieważ błąd pojawia się na urządzeniu użytkownika, w środowisku, którego nie widać. W większości przypadków wszystko, co masz, to dziennik awarii (dziennik awarii/śledzenie stosu — opis techniczny tego, dokąd udała się aplikacja po awarii). Sztuczna inteligencja jest niezwykle skuteczna w odczytywaniu tych tajemniczych zapisów, wymienianiu możliwych przyczyn i proponowaniu rozwiązań. W tej części nauczymy się wykorzystywać sztuczną inteligencję jako „detektywa błędów”, ale pozostawimy Cię z odpowiedzialnością za weryfikację ostatecznej diagnozy i naprawienie problemu.
Czytanie dziennika awarii: gdzie sztuczna inteligencja świeci najjaśniej
Dziennik awarii to długi i zastraszający tekst; niedoświadczony programista nie będzie wiedział, gdzie szukać. AI analizuje ten tekst w ciągu kilku sekund: w której linii nastąpiła awaria, jaki wyjątek został zgłoszony, jaka jest możliwa przyczyna. Typowe błędy mobilne są oczywiste i sztuczna inteligencja szybko je rozpoznaje: NullPointerException (próba dostępu do wartości null), IndexOutOfBoundsException (dostęp do nieistniejącego elementu listy) na Androidzie, EXC_BAD_ACCESS (dostęp do wolnej pamięci) na iOS, nieoczekiwanie znaleziono zero (wymuszanie zera opcjonalnie).
Najczęstsze rodzaje awarii urządzeń mobilnych i ich typowe przyczyny są następujące:
Błąd (wyjątek)
Platforma
typowa przyczyna
Wyjątek NullPointer
Androida
Dostęp do wartości null
Wyjątek IndexOutOfBounds
Androida
Dostęp do nieistniejącego elementu listy
nieoczekiwanie znaleziono zero
iOS
Wymuś rozpakowanie zerowego opcjonalnego (!)
EXC_BAD_ACCESS
iOS
Dostęp do zwolnionej pamięci
ANR/zawieszenie
Androida
Długie/ciężkie przetwarzanie głównego wątku
Procedura debugowania krok po kroku:
- Zbierz płytę. Przygotuj dziennik awarii, komunikat o błędzie i kroki, aby je odtworzyć, jeśli to możliwe.
- Podaj kontekst AI. Powiedz mi nie tylko o błędzie, ale także o odpowiednim fragmencie kodu i o tym, co spowodowało awarię.
- Zapytaj o możliwe przyczyny. „Powiedz mi 3 najbardziej prawdopodobne przyczyny i jak sprawdzić każdą z nich”.
- Zweryfikować. Potwierdź proponowany powód w kodzie i testowaniu; Nie naprawiaj tego poprzez zgadywanie.
- Napraw to i przetestuj ponownie. Sprawdź, czy błąd faktycznie zniknął i nie są generowane żadne nowe błędy.
Wskazówka: przekazując dziennik awarii AI, dołącz także odpowiedni fragment kodu. Tylko w przypadku śledzenia stosu sztuczna inteligencja dokonuje ogólnych przewidywań; Kiedy zobaczysz kod, prawdopodobieństwo znalezienia dokładnej linii i prawdziwej przyczyny znacznie wzrasta. Kontekst determinuje jakość diagnozy.
Pułapka danych osobowych
Dzienniki awarii i dzienniki często zawierają dane użytkownika: adres e-mail, identyfikator użytkownika, lokalizację, a nawet treść formularzy. Wklejenie tego zapisu do AI w niezmienionej postaci powoduje wyciek danych osobowych stronie trzeciej i stanowi naruszenie KVKK/RODO. Przed przesłaniem nagrania wyczyść (zamaskuj) obszary osobiste. Uważaj także, aby od początku nie zapisywać danych osobowych w logach aplikacji; Dobry dziennik opisuje problem, ale nie ujawnia tożsamości.
Uwaga: poprawka sugerowana przez sztuczną inteligencję może „wyciszyć błąd”, ale może nie rozwiązać pierwotnej przyczyny. Na przykład zawinięcie wyjątku NullPointerException sprawdzeniem wartości null zatrzyma awarię, ale jeśli nie dowiesz się, dlaczego wartość ma wartość null, rzeczywisty błąd logiczny będzie kontynuowany. Leczyć chorobę, a nie objaw.
Analiza przyczyn źródłowych
Celem profesjonalnego debugowania nie jest wyciszenie błędu, ale znalezienie jego pierwotnej przyczyny. Zapytałem sztuczną inteligencję „dlaczego może to być wartość zerowa i gdzie mogła zaginąć w przepływie danych?” pytając: „Jak to wyciszyć?” Jest to o wiele cenniejsze niż proszenie. Po znalezieniu pierwotnej przyczyny dziesiątki odmian tego samego błędu są rozwiązywane jednocześnie. Sztuczna inteligencja jest dobra w rozumowaniu łańcuchowym: podążaj za danymi od wejścia do wyjścia i poproś ją, aby zastanowiła się, gdzie się psują.
trzy mini etui
Przypadek 1 — 2 godziny pracy w 10 minut. Programista spędził 2 godziny na poszukiwaniu błędu, który zawieszał się tylko w konkretnym modelu Samsunga. Przekazał dziennik awarii (czyszczenie obszarów osobistych) AI; YZ powiedział, że błąd wskazuje na przepełnienie pamięci, które występuje w przypadku innej rozdzielczości aparatu tego urządzenia. Dzięki wskazówce powód został znaleziony w 10 minut. AI przyspieszyła wyszukiwanie, człowiek zweryfikował rozwiązanie.
Przypadek 2 — Wyciszony błąd powrócił. Jeden zespół uciszył powtarzającą się awarię, korzystając z sugestii sztucznej inteligencji, aby spróbować ją złapać. Awarie ustały, ale użytkownicy zaczęli narzekać, że „dane nie są zapisywane”; ponieważ prawdziwy problem (połączenie z bazą danych) nadal występował, stał się po prostu niewidoczny. Po znalezieniu pierwotnej przyczyny awaria i utrata danych zostały rozwiązane. Lekcja: wyciszenie nie rozwiązuje problemu.
Przypadek 3 — Wyciek danych z dziennika. Kontrola wykazała, że imiona i nazwiska oraz numery telefonów użytkowników zostały zapisane w dziennikach awarii aplikacji. Programiści rutynowo wklejali te logi do sztucznej inteligencji i naprawiali błędy; Dane osobowe wyciekają więc od miesięcy. Logi zostały zamaskowane i proces został poprawiony. Lekcja: poufność obowiązuje nawet podczas debugowania.
Słaba zachęta/silna zachęta
Słaby monit: „Dlaczego występuje ten błąd? [śledzenie stosu]”
Silna zachęta: „Ta awaria dzieje się w mojej aplikacji na Androida. Kontekst: – Podczas wykonywania: dodanie użytkownika do koszyka ze szczegółów produktu – Tylko na niektórych urządzeniach, modele z małą ilością pamięci RAM – Powiązany kod: [ViewModel i część repozytorium] – Dziennik awarii (wyczyszczone dane osobowe): [śledzenie stosu] Wymień 3 najbardziej prawdopodobne przyczyny źródłowe. Dla każdej z nich: 1) Jak zweryfikować, 2) Trwała poprawka (nie wyciszanie). Podaj swoje założenia, jeśli nie jesteś pewien.
Szablony do kopiowania
Szablon analizy awarii: „Przeanalizuj następującą awarię. Kontekst: [co robisz, jakie urządzenie/wersja]. Odpowiedni kod: [kod]. Dziennik awarii (dane osobowe zostały usunięte): [trace]. Podaj 3 najbardziej prawdopodobne przyczyny źródłowe i weryfikację + trwałe rozwiązanie dla każdej z nich. Zaznacz także obejścia, które wyciszą objaw.
Szablon głównej przyczyny: „Ta wartość pojawia się nieoczekiwanie [null/false]. Śledź przepływ danych od wejścia do tego punktu: gdzie mogą zostać utracone lub uszkodzone? Powiedz mi, gdzie powinienem sprawdzić na każdym etapie. [kod]”
Szablon odczytu dziennika: „Interpretuj dane wyjściowe dziennika: jaka kolejność zdarzeń wystąpiła, gdzie występuje nieprawidłowość, jaki był ostatni zdrowy krok przed wystąpieniem błędu? [log — dane osobowe zostały usunięte]”
Szablon reprodukcji: „Jakie kroki, stany urządzenia i dane należy spróbować, aby niezawodnie odtworzyć ten błąd? Wymień warunki, które mogą wywołać błąd, w kolejności prawdopodobieństwa. [opis]”
Typowe błędy
- Udostępnianie bezkontekstowego śledzenia stosu. Bez odpowiedniego kodu i scenariusza sztuczna inteligencja dokonuje ogólnych przewidywań.
- Wklejanie danych osobowych do AI wraz z logami. Naruszenie poufności; najpierw maska.
- Wycisz objaw. Ukrycie awarii za pomocą try-catch pozostawia główny problem i tworzy nowe problemy.
- Zastosowanie pierwszej sugestii bez jej weryfikacji. Diagnoza AI jest hipotezą; Potwierdź w kodzie.
- Próbuję odtworzyć to w emulatorze. Niektóre błędy pojawiają się tylko w przypadku rzeczywistego urządzenia/stanu.
- Nie powtarzam testu po korekcie. Poprawka mogła uszkodzić coś innego; Sprawdź regresję.
Podsumowując
Jednym z obszarów, w których sztuczna inteligencja przoduje, jest odczytywanie dzienników awarii i sortowanie możliwych przyczyn; Jakość diagnozy znacznie się poprawia, gdy podany jest kontekst. Ale ostateczna diagnoza i korekta należą do człowieka: sugestia sztucznej inteligencji jest hipotezą, zweryfikowaną w kodzie i testach. Celem nie jest wyciszenie objawu, ale rozwiązanie pierwotnej przyczyny; Wyciszony błąd zwykle powraca w innej formie. Dzienniki awarii mogą zawierać dane osobowe; Zamaskuj go przed przekazaniem AI i nie zapisuj od początku danych osobowych w swoich logach.
Zadanie aplikacji
Weź posiadany dziennik awarii (lub próbkę wygenerowaną przez sztuczną inteligencję), zamaskuj wszelkie zawarte w nim dane osobowe/charakterystyczne i przekaż je sztucznej inteligencji za pomocą „szablonu analizy awarii”. Rozróżnij, które z głównych przyczyn, listy AI są rzeczywistymi poprawkami, a które jedynie wyciszaniem. Zastosuj wybraną trwałą poprawkę i sprawdź, czy błąd zniknął i nie pojawiły się żadne nowe problemy.
lista kontrolna
- [ ] Podałem dziennik awarii z odpowiednim kodem i kontekstem scenariusza
- [ ] Zamaskowałem dane osobowe/charakterystyczne w logach
- [ ] Poprosiłem sztuczną inteligencję o pierwotną przyczynę i trwałe rozwiązanie, a nie o wyciszenie
- [ ] Diagnozę zweryfikowałem w kodzie i testowaniu, nie stosowałem jej ślepo
- [ ] Po naprawie sprawdziłem, czy błąd zniknął i nie było regresji
- [ ] Sprawdziłem, czy moja aplikacja nie zapisuje danych osobowych w swoich logach