Добивки:
- Способност брзо да се отстранат можните основни причини со давање записи за падови (траги на оџакот) на вештачката интелигенција со соодветниот код и контекст на сценарио
- Способност трајно да се реши основната причина наместо да се потврди дијагнозата на вештачката интелигенција како хипотеза во кодот и тестирање и замолчување на симптомот
- Заштита на приватноста при дебагирање со маскирање на лични податоци во записи за падови и дневници
Секоја апликација дава грешки; Она што го разликува добриот програмер е колку брзо ги наоѓа и поправа грешките. Мобилното дебагирање - наоѓање и поправање на изворот на проблемот - е особено тешко бидејќи грешката се јавува на уредот на корисникот, во средина што не можете да ја видите. Поголемиот дел од времето, сè што имате е дневник за падови (дневник на падови / трага на стек - технички преглед каде отишла апликацијата кога паднала). Вештачката интелигенција е исклучително моќна во читањето на овие криптични записи, наведување можни причини и предлагање решенија. Во оваа единица ќе научиме како да ја користиме вештачката интелигенција како „детектив за грешки“, но ќе ви оставиме одговорност да ја потврдите конечната дијагноза и да ја поправите.
Читање на дневникот за падови: Каде што вештачката интелигенција сјае најсилно
Дневникот за падови е долг и застрашувачки текст; неискусен програмер нема да знае каде да бара. AI го анализира овој текст за секунди: на која линија падна, кој исклучок беше исфрлен, која е можната причина. Вообичаените мобилни грешки се очигледни и вештачката интелигенција брзо ги препознава: NullPointerException (се обидува да пристапи до нула вредност), IndexOutOfBoundsException (пристап до непостоечки елемент од списокот) на Android, EXC_BAD_ACCESS (пристап до ослободена меморија) на iOS, неочекувано пронајдена опција за неочекувано).
Најчестите типови на мобилни несреќи и нивните типични причини се како што следува:
Грешка (исклучок)
Платформа
типична причина
NullPointerException
Андроид
Пристап до нула вредност
IndexOutOfBoundsException
Андроид
Пристап до непостоечки елемент од списокот
неочекувано пронајден нула
iOS
Присилно одвиткување нула опционално (!)
EXC_BAD_ACCESS
iOS
Пристап до ослободената меморија
ANR/замрзнување
Андроид
Долга/тешка обработка на главната нишка
Тек на дебагирање чекор по чекор:
- Соберете го записот. Соберете го дневникот за падови, пораката за грешка и чекорите за репродукција ако е можно.
- Наведете го контекстот на вештачката интелигенција. Кажете ми не само за грешката, туку и за релевантниот дел од кодот и за тоа што се урна.
- Прашајте за можни причини. „Кажете ми ги 3-те најверојатни причини и како да ја потврдам секоја од нив“.
- Потврди. Потврдете ја предложената причина во кодот и тестирањето; Не го поправајте со погодување.
- Поправете го и тестирајте повторно. Проверете дали грешката е навистина исчезната и не се генерираат нови грешки.
Совет: кога го давате дневникот за падови на вештачката интелигенција, вклучете го и соодветниот фрагмент од код. Само со stack trace вештачката интелигенција прави општо предвидување; Кога ќе го видите кодот, веројатноста да се најде точната линија и вистинската причина значително се зголемува. Контекстот го одредува квалитетот на дијагнозата.
Замка за лични податоци
Дневниците и дневниците на падови често содржат кориснички податоци: е-пошта, кориснички ID, локација, дури и содржина на форма. Вметнувањето на овој запис во вештачката интелигенција како што е е протекување на лични податоци на трето лице и е прекршување на KVKK / GDPR. Исчистете (маскирајте) личните области пред да ја испратите снимката. Исто така, внимавајте да не пишувате лични податоци во дневниците на вашата апликација од почеток; Добар дневник го опишува проблемот, но не го открива идентитетот.
Внимание: Поправката предложена од вештачката интелигенција може да ја „замолчи грешката“, но можеби нема да ја реши основната причина. На пример, завиткување на NullPointerException со нула проверка ќе го запре падот, но ако не сфатите зошто вредноста е нула, вистинската логичка грешка ќе продолжи. Третирајте ја болеста, а не симптомот.
Анализа на корените причини
Целта на професионалното дебагирање не е да се замолчи грешката, туку да се најде основната причина. Ја прашав вештачката интелигенција „зошто ова може да биде нула, каде можеби се изгубило во протокот на податоци? прашувајќи: „Како да го замолчам ова?“ Тоа е многу повредно од барањето. Откако ќе се најде основната причина, десетици варијации на истата грешка се решаваат одеднаш. Вештачката интелигенција е добра во ова верижно размислување: следете ги податоците од влез до излез и побарајте од нив да размисли каде се распаѓаат.
три мини футроли
Случај 1 — 2 часа работа за 10 минути. Еден развивач помина 2 часа во потрага по грешка што падна само на специфичен модел на Samsung. Го дал дневникот за падови (чистење лични области) на вештачката интелигенција; YZ рече дека грешката укажува на прелевање на меморијата што се случува со различна резолуција на камерата на тој уред. Со поим причината е пронајдена за 10 минути. ВИ го забрза пребарувањето, човекот го потврди решението.
Случај 2 - Замолчената бубачка се врати. Еден тим го замолчи повторливиот пад со користење на предлог за вештачка интелигенција за да се обиде да го фати. Ударот престана, но корисниците почнаа да се жалат дека „податоците не се зачувуваат“; бидејќи вистинскиот проблем (врска со база на податоци) сè уште беше таму, тукушто стана невидлив. Откако беше пронајдена основната причина, и падот и загубата на податоци беа решени. Поука: замолчувањето не се решава.
Случај 3 - Податоците протекоа во дневникот. Ревизијата покажа дека целосните имиња и телефонските броеви на корисниците биле запишани во дневниците за падови на апликацијата. Програмерите рутински ги залепуваат овие логови во вештачката интелигенција и ги поправале грешките; Така, личните податоци излегуваат со месеци. Дневниците беа маскирани и процесот беше коригиран. Лекција: доверливоста се применува дури и при дебагирање.
Слаб промпт / Силен промпт
Лошо известување: „Зошто се појавува оваа грешка? [стак трага]“
Силен потсетник: „Овој пад се случува во мојата апликација за Android. Контекст: - додека го правам: корисникот додава во количката од деталите за производот- Само на некои уреди, модели со ниска RAM меморија- Поврзан код: [ViewModel and Repository part]- Дневник на падови (личните податоци се исчистени): [stack trace]Наведете ги 3-те најверојатни причини за секој: 1 поправете). (не замолчувајќи) наведете ја вашата претпоставка таму каде што не сте сигурни“.
Шаблони за копирање
Шаблон за анализа на падови: „Анализирајте го следниов пад. Контекст: [што правите, кој уред/верзија]. Релевантен код: [шифра]. Дневник на падови (личните податоци се исчистени): [трага]. Наведете 3 најверојатни основни причини и потврда + трајна поправка за секоја. Исто така, означете решенија што го стишуваат симптомот.
Шаблон за основна причина: "Оваа вредност доаѓа [null/false] неочекувано. Следете го протокот на податоци од внесувањето до оваа точка: каде може да се изгуби или оштети? Кажете ми каде да проверам во секоја фаза. [код]"
Шаблон за читање дневник: „Интерпретирај го овој излез од дневникот: кои настани се случија по редослед, каде е абнормалноста, кој беше последниот здрав чекор пред грешката? [log — личните податоци се исчистени]“
Шаблон за репродукција: "Кои чекори, состојби на уредот и податоци треба да се обидам со сигурност да ја репродуцирам оваа грешка? Наведете ги условите што би можеле да ја активираат грешката по редослед на веројатност. [опис]"
Вообичаени грешки
- Давање трага на стек без контекст. Без релевантен код и сценарио, вештачката интелигенција прави општо предвидување.
- Вметнување лични податоци во вештачката интелигенција заедно со дневници. Прекршување на доверливоста; прво маска.
- Замолчете го симптомот. Сокривањето на падот со обид за фаќање го напушта коренскиот проблем и создава нови проблеми.
- Примена на првиот предлог без да се потврди. Дијагнозата на АИ е хипотеза; Потврдете во кодот.
- Се обидува да го репродуцира во емулаторот. Некои грешки се појавуваат само на вистинскиот уред/состојба.
- Не се повторува по корекција. Поправката можеби скршила нешто друго; Проверете ја регресијата.
Сумирано
Една од областите каде што вештачката интелигенција се истакнува е читањето на дневниците за падови и сортирањето на можните причини; Квалитетот на дијагнозата значително се подобрува кога се дава контекст. Но, конечната дијагноза и корекција му припаѓаат на човекот: предлогот на вештачката интелигенција е хипотеза, проверена во код и тестирање. Целта не е да се замолчи симптомот, туку да се реши основната причина; Замолчената грешка обично се враќа во друга форма. Дневниците на падови може да содржат лични податоци; Маскирајте го пред да го дадете на вештачката интелигенција и не пишувајте лични податоци во вашите дневници од почеток.
Задача за апликација
Земете дневник за падови што го имате (или примерокот што го генерирате од вештачката интелигенција), маскирајте ги сите лични/карактеристични податоци во него и дајте му го на вештачката интелигенција со „Шаблон за анализа на падови“. Разграничете кои од основните причини списоците за вештачка интелигенција се вистински поправки и кои само замолчуваат. Применете ја трајната поправка што ја избравте и потврдете дека грешката е исчезната и дека не се појавуваат нови проблеми.
листа за проверка
- [ ] Го дадов дневникот за падови со релевантен код и контекст на сценарио
- [ ] Ги маскирав личните/карактеристични податоци во дневниците
- [ ] Побарав од вештачката интелигенција за основна причина и трајно поправање, а не за замолчување
- [ ] Ја потврдив дијагнозата во код и тестирање, не ја применив слепо
- [ ] По поправката, тестирав дека грешката ја нема и нема регресија
- [ ] Проверив дека мојата апликација не запишува лични податоци во дневниците