Печалби:
- Възможност за бързо стесняване на възможните първопричини чрез предоставяне на записи за сривове (следи на стека) на изкуствения интелект със съответния код и контекст на сценария
- Възможност за постоянно разрешаване на основната причина, вместо да валидира диагнозата на AI като хипотеза в кода и тестване и заглушаване на симптома
- Защита на поверителността при отстраняване на грешки чрез маскиране на лични данни в записи и регистрационни файлове за сривове
Всяко приложение дава грешки; Това, което отличава добрия програмист, е колко бързо намира и коригира грешки. Мобилното отстраняване на грешки — намирането и коригирането на източника на проблем — е особено трудно, защото грешката възниква на устройството на потребителя в среда, която не можете да видите. През повечето време всичко, с което разполагате, е регистър на сривове (журнал на сривове / проследяване на стека — техническа разбивка на това къде е отишло приложението, когато се е сбило). AI е изключително мощен при четенето на тези загадъчни записи, изброяването на възможните причини и предлагането на решения. В тази част ще научим как да използваме AI като „детектив на грешки“, но ви оставяме отговорността да проверите окончателната диагноза и поправката.
Четене на регистъра на сривовете: Където AI блести най-ярко
Журналът за сривове е дълъг и плашещ текст; неопитен разработчик няма да знае къде да търси. AI анализира този текст за секунди: на кой ред се е сбил, кое изключение е хвърлено, каква е възможната причина. Често срещаните мобилни грешки са очевидни и AI ги разпознава бързо: NullPointerException (опит за достъп до нулева стойност), IndexOutOfBoundsException (достъп до несъществуващ елемент от списък) на Android, EXC_BAD_ACCESS (достъп до освободена памет) на iOS, неочаквано намерена нула (принудително нула по избор).
Най-често срещаните типове сривове на мобилни устройства и техните типични причини са следните:
Грешка (изключение)
Платформа
типична причина
NullPointerException
Android
Достъп до нулева стойност
IndexOutOfBoundsException
Android
Достъп до несъществуващ елемент от списък
неочаквано намерено нула
iOS
Принудително разопаковане на нула по избор (!)
EXC_BAD_ACCESS
iOS
Достъп до освободена памет
ANR/замразяване
Android
Дълга/тежка обработка на основната нишка
Процес на отстраняване на грешки стъпка по стъпка:
- Съберете записа. Съберете заедно регистъра на сривовете, съобщението за грешка и стъпките за възпроизвеждането му, ако е възможно.
- Дайте контекст на AI. Кажете ми не само грешката, но и съответната част от кода и какво прави.
- Попитайте за възможните причини. „Кажете ми 3-те най-вероятни причини и как да проверя всяка от тях.“
- Проверете. Потвърдете предложената причина в кода и тестването; Не го поправяйте с познания.
- Поправете го и тествайте отново. Проверете дали грешката действително е изчезнала и не се генерират нови грешки.
Съвет: Когато предоставяте регистъра на сривовете на AI, включете и съответния кодов фрагмент. Само с проследяване на стека AI прави обща прогноза; Когато видите кода, вероятността да намерите точния ред и истинската причина се увеличава значително. Контекстът определя качеството на диагнозата.
Капан за лични данни
Журналите за сривове и регистрационните файлове често съдържат потребителски данни: имейл, потребителско име, местоположение, дори съдържание на формуляр. Поставянето на този запис в AI така, както е, е изтичане на лични данни към третата страна и е нарушение на KVKK / GDPR. Изчистете (маскирайте) личните зони, преди да изпратите записа. Също така внимавайте да не записвате лични данни в регистрационните файлове на вашето приложение от самото начало; Добрият дневник описва проблема, но не разкрива самоличността.
Внимание: Поправката, предложена от AI може да „заглуши грешката“, но може да не разреши първопричината. Например, обвиването на NullPointerException с нулева проверка ще спре срива, но ако не разберете защо стойността е нула, действителната логическа грешка ще продължи. Лекувайте болестта, а не симптома.
Анализ на първопричината
Целта на професионалното отстраняване на грешки не е да заглуши грешката, а да открие първопричината. Попитах AI "защо това може да е нула, къде може да се е загубило в потока от данни?" питайки „как да заглуша това?“ Много по-ценно е от искането. След като бъде открита първопричината, десетки вариации на една и съща грешка се решават наведнъж. AI е добър в тези верижни разсъждения: следвайте данните от входа до изхода и го помолете да помисли къде се разпада.
три мини калъфа
Случай 1 — 2 часа работа за 10 минути. Разработчик прекара 2 часа в търсене на грешка, която се срива само на конкретен модел на Samsung. Даде регистъра на сривовете (изчистване на лични зони) на AI; YZ каза, че грешката сочи към препълване на паметта, което възниква при различна резолюция на камерата на това устройство. С уликата причината беше открита за 10 минути. AI ускори търсенето, хората потвърдиха решението.
Случай 2 — Заглушеният бъг се завръща. Един екип заглуши повтарящ се срив, като използва AI предложение, за да се опита да го хване. Сривът спря, но потребителите започнаха да се оплакват, че „данните не се записват“; тъй като истинският проблем (връзката с базата данни) все още беше там, просто беше станал невидим. След като основната причина беше открита, сривът и загубата на данни бяха разрешени. Урок: заглушаването не е решение.
Случай 3 — Изтекли данни в регистрационния файл. Проверка установи, че пълните имена и телефонните номера на потребителите са записани в регистрационните файлове за сривове на приложението. Разработчиците рутинно поставяха тези регистрационни файлове в AI и коригираха грешки; Така че личните данни излизат от месеци. Дневниците бяха маскирани и процесът беше коригиран. Урок: поверителността се прилага дори при отстраняване на грешки.
Слаба подкана / Силна подкана
Лоша подкана: „Защо възниква тази грешка? [проследяване на стека]“
Силна подкана: „Този срив се случва в моето приложение за Android. Контекст: – Докато правя: потребител добавя към кошницата от подробности за продукта – Само на някои устройства, модели с ниска RAM памет – Свързан код: [ViewModel и част от хранилището] – Регистър на срива (личните данни са изчистени): [проследяване на стека] Избройте 3-те най-вероятни основни причини. За всяка: 1) Как да проверя, 2) Постоянна корекция (не заглушаване). Изложете предположението си там, където не сте сигурни."
Копируеми шаблони
Шаблон за анализ на срив: "Анализиране на следния срив. Контекст: [какво правите, кое устройство/версия]. Съответен код: [код]. Регистър на срива (личните данни са изчистени): [проследяване]. Дайте 3 най-вероятни първопричини и проверка + постоянна корекция за всяка. Също така маркирайте заобиколни решения, които заглушават симптома."
Шаблон на основната причина: "Тази стойност идва [null/false] неочаквано. Следвайте потока от данни от входа до тази точка: къде може да бъде загубен или повреден? Кажете ми къде трябва да проверя на всеки етап. [код]"
Шаблон за четене на регистрационния файл: „Интерпретирайте този изход от регистрационния файл: какви събития са се случили по ред, къде е аномалията, коя беше последната здравословна стъпка преди грешката? [дневник — личните данни са изчистени]“
Шаблон за възпроизвеждане: „Какви стъпки, състояния на устройството и данни трябва да опитам, за да възпроизведа надеждно тази грешка? Избройте условията, които биха могли да задействат грешката в ред на вероятност. [описание]“
Често срещани грешки
- Предоставяне на проследяване на стека без контекст. Без подходящ код и сценарий AI прави обща прогноза.
- Поставяне на лични данни в AI заедно с регистрационни файлове. Нарушаване на поверителността; първо маска.
- Заглушете симптома. Скриването на срива с try-catch оставя основния проблем и създава нови проблеми.
- Прилагане на първото предложение без проверка. Диагнозата AI е хипотеза; Потвърдете в кода.
- Опитвам се да го възпроизведа в емулатора. Някои грешки се появяват само на действителното устройство/състояние.
- Без повторно тестване след корекция. Корекцията може да е счупила нещо друго; Проверете регресията.
В обобщение
Една от областите, в които AI превъзхожда, е четенето на журнали за сривове и сортирането на възможните причини; Качеството на диагнозата се подобрява значително, когато се даде контекст. Но окончателната диагноза и корекция принадлежат на човека: предложението на AI е хипотеза, проверена в код и тестване. Целта не е да се заглуши симптомът, а да се разреши първопричината; Заглушената грешка обикновено се връща в друга форма. Журналите за сривове може да съдържат лични данни; Маскирайте го, преди да го дадете на AI и не пишете лични данни в регистрационните си файлове от самото начало.
Задача за приложение
Вземете регистър на сривовете, който имате (или извадката, която генерирате от AI), маскирайте всички лични/отличителни данни в него и ги предайте на AI с „шаблон за анализ на сривове“. Разграничете кои от списъците с първопричини за AI са действителни корекции и кои просто заглушават. Приложете постоянната корекция, която сте избрали, и се уверете, че грешката е изчезнала и не възникват нови проблеми.
контролен списък
- [ ] Дадох регистъра на сривовете със съответния код и контекст на сценария
- [ ] Маскирах лични/отличителни данни в регистрационните файлове
- [ ] Поисках AI за основната причина и трайно отстраняване, а не заглушаване
- [ ] Проверих диагнозата в код и тестване, не я приложих на сляпо
- [ ] След корекцията тествах, че грешката е изчезнала и няма регресия
- [ ] Проверих дали приложението ми не записва лични данни в регистрационните си файлове