איתור באגים וניתוח קריסות עם בינה מלאכותית

רווחים:

• יכולת לצמצם במהירות את גורמי השורש האפשריים על ידי מתן רשומות התרסקות (עקבות מחסנית) לבינה מלאכותית עם ההקשר הרלוונטי של הקוד והתרחיש
• יכולת לפתור לצמיתות את הסיבה השורשית במקום לאמת את האבחנה של ה-AI כהשערה בקוד ובבדיקה והשתקת הסימפטום
• הגנה על הפרטיות בזמן ניפוי באגים על ידי מיסוך נתונים אישיים ברשומות קריסה וביומנים

כל יישום נותן שגיאות; מה שמייחד מפתח טוב הוא כמה מהר הם מוצאים ומתקנים באגים. איתור באגים נייד - איתור ותיקון מקור הבעיה - קשה במיוחד מכיוון שהשגיאה מתרחשת במכשיר של המשתמש, בסביבה שאינך יכול לראות. רוב הזמן, כל מה שיש לך הוא יומן קריסה (יומן קריסה / מעקב מחסנית - פירוט טכני של המקום שבו האפליקציה הלכה כשהיא קרסה). בינה מלאכותית חזקה במיוחד בקריאת הרשומות החשוכות הללו, פירוט סיבות אפשריות והצעת פתרונות. ביחידה זו נלמד כיצד להשתמש ב-AI כ"בלש באגים" אך נשאיר אתכם באחריות לאמת את האבחנה הסופית ולתקן.

קריאת יומן ההתרסקות: המקום שבו בינה מלאכותית זוהרת בצורה הבהירה ביותר

יומן קריסה הוא טקסט ארוך ומפחיד; מפתח חסר ניסיון לא יידע היכן לחפש. AI מנתח את הטקסט הזה בשניות: באיזו שורה הוא התרסק, איזה חריג נזרק, מהי הסיבה האפשרית. שגיאות ניידות נפוצות ברורות וה-AI מזהה אותן במהירות: NullPointerException (מנסה לגשת לערך null), IndexOutOfBoundsException (גישה לרכיב רשימה לא קיים) באנדרואיד, EXC_BAD_ACCESS (גישה לזיכרון משוחרר) ב-iOS, נמצא במפתיע אפס (כפיית אפס).

הסוגים הנפוצים ביותר של קריסות ניידות והסיבות האופייניות להן הן כדלקמן:

שגיאה (חריג)

פלטפורמה

סיבה טיפוסית

NullPointerException

אנדרואיד

גישה לערך null

IndexOutOfBoundsException

אנדרואיד

גישה לרכיב רשימה לא קיים

נמצא במפתיע אפס

iOS

אופציונלי לאלץ לפרוק אפס (!)

EXC_BAD_ACCESS

iOS

גישה לזיכרון משוחרר

ANR/הקפאה

אנדרואיד

עיבוד ארוך/כבד בחוט הראשי

זרימת איתור באגים שלב אחר שלב:

1. אספו את התקליט. חבר את יומן הקריסה, את הודעת השגיאה ואת השלבים לשחזר אותו במידת האפשר.
2. תן את ההקשר של AI. ספר לי לא רק את השגיאה, אלא את קטע הקוד הרלוונטי ומה הוא התרסק.
3. בקשו סיבות אפשריות. "ספר לי את 3 הסיבות הסבירות ביותר וכיצד לאמת כל אחת מהן."
4. לְאַמֵת. אשר את הסיבה המוצעת בקוד ובבדיקה; אל תתקן את זה על ידי ניחושים.
5. תקן את זה ובדוק שוב. בדוק שהשגיאה אכן נעלמה ולא נוצרות שגיאות חדשות.

טיפ: בעת מתן יומן הקריסה ל-AI, כלול גם את קטע הקוד הרלוונטי. רק עם מעקב מחסנית עושה AI חיזוי כללי; כאשר אתה רואה את הקוד, ההסתברות למצוא את הקו המדויק ואת הסיבה האמיתית עולה מאוד. ההקשר קובע את איכות האבחון.

מלכודת נתונים אישיים

יומני קריסה ויומנים מכילים לעתים קרובות נתוני משתמש: דואר אלקטרוני, מזהה משתמש, מיקום, אפילו תוכן טופס. הדבקת רשומה זו ב-AI כפי שהיא מדליפת נתונים אישיים לצד השלישי ומהווה הפרה של KVKK / GDPR. נקה (מסכה) אזורים אישיים לפני שליחת ההקלטה. כמו כן, היזהר לא לכתוב נתונים אישיים ליומני היישום שלך מההתחלה; יומן טוב מתאר את הבעיה אך אינו חושף את הזהות.

זהירות: התיקון המוצע על ידי ה-AI עשוי "להשתיק את הבאג" אך עשוי שלא לפתור את סיבת השורש. לדוגמה, גלישת NullPointerException עם בדיקת null תעצור את הקריסה, אך אם לא תבין מדוע הערך הוא null, שגיאת הלוגיקה בפועל תמשיך. לטפל במחלה, לא בסימפטום.

ניתוח סיבת השורש

המטרה של איתור באגים מקצועי היא לא להשתיק את השגיאה אלא למצוא את הסיבה השורשית. שאלתי את ה-AI "למה זה יכול להיות ריק, איפה זה יכול ללכת לאיבוד בזרימת הנתונים?" שואל, "איך אני משתיק את זה?" זה הרבה יותר יקר מלבקש. ברגע שמקור השורש נמצא, עשרות וריאציות של אותה שגיאה נפתרות בבת אחת. בינה מלאכותית טובה בהנמקת השרשרת הזו: עקוב אחר הנתונים מהקלט לפלט ובקש ממנו לחשוב היכן הם מתקלקלים.

שלושה מיני תיקים

מקרה 1 - שעתיים עבודה ב-10 דקות. מפתח בילה שעתיים בחיפוש אחר באג שקרס רק בדגם ספציפי של סמסונג. נתן את יומן ההתרסקות (ניקוי אזורים אישיים) ל-AI; YZ אמר כי השגיאה מצביעה על הצפת זיכרון המתרחשת ברזולוציית מצלמה שונה של אותו מכשיר. עם הרמז, הסיבה נמצאה תוך 10 דקות. AI האיץ את החיפוש, אנושי אימת את הפתרון.

מקרה 2 - הבאג המושתק חזר. צוות אחד השתיק התרסקות חוזרת על ידי שימוש בהצעת בינה מלאכותית כדי לנסות לתפוס אותה. הקריסה פסקה, אך משתמשים החלו להתלונן ש"הנתונים לא נשמרים"; מכיוון שהבעיה האמיתית (חיבור מסד הנתונים) עדיין הייתה שם, היא פשוט הפכה לבלתי נראית. לאחר שנמצאה סיבת השורש, גם הקריסה וגם אובדן הנתונים נפתרו. לקח: השתקה לא פותרת.

מקרה 3 - נתונים דלפו ביומן. בביקורת נמצא כי השמות המלאים ומספרי הטלפון של המשתמשים נכתבו ביומני הקריסה של האפליקציה. מפתחים הדביקו באופן שגרתי את היומנים האלה ב-AI ותיקנו באגים; אז נתונים אישיים יוצאים כבר חודשים. יומנים הוסו והתהליך תוקן. לקח: סודיות חלה גם בעת ניפוי באגים.

הנחיה חלשה / הנחיה חזקה

הודעה גרועה: "מדוע שגיאה זו מתרחשת? [מעקב מחסנית]"

הנחיה חזקה: "התרסקות הזו מתרחשת באפליקציית אנדרואיד שלי. הקשר:- תוך כדי: משתמש מוסיף לעגלת הקניות מפרט המוצר- רק במכשירים מסוימים, דגמי זיכרון RAM נמוך- קוד קשור: [ViewModel and Repository part]- יומן קריסה (נתונים אישיים נוקו): [מעקב מחסנית]רשום את 3 הסיבות הבסיסיות הסבירות ביותר. לכל אחד:1) איך אני מוודא את הסתיימה שלך (2) הנחה שבה אתה לא בטוח."

תבניות הניתנות להעתקה

תבנית ניתוח קריסות: "נתח את הקריסה הבאה. הקשר: [מה אתה עושה, איזה מכשיר/גרסה]. קוד רלוונטי: [קוד]. יומן קריסה (נתונים אישיים נוקו): [מעקב]. תן 3 סיבות שורש ואימות ככל הנראה + תיקון קבוע לכל אחד. סמן גם דרכים לעקיפת הבעיה המשתיקה את הסימפטום."

תבנית שורש: "ערך זה מגיע [null/false] באופן בלתי צפוי. עקוב אחר זרימת הנתונים מהקלט עד לנקודה זו: היכן הוא עלול ללכת לאיבוד או פגום? אמור לי היכן עלי לבדוק בכל שלב. [קוד]"

תבנית קריאת יומן: "פרש את פלט היומן הזה: אילו אירועים התרחשו לפי הסדר, היכן החריגה, מה היה השלב הבריא האחרון לפני השגיאה? [יומן - נתונים אישיים נוקו]"

תבנית רפרודוקציה: "אילו שלבים, מצבי מכשיר ונתונים עלי לנסות לשחזר בצורה מהימנה את השגיאה הזו? רשום את התנאים שיכולים להפעיל את השגיאה לפי סדר ההסתברות. [תיאור]"

טעויות נפוצות

• מתן עקבות מחסנית ללא הקשר. ללא קוד ותרחיש רלוונטיים, AI עושה חיזוי כללי.
• הדבקת נתונים אישיים ב-AI יחד עם יומנים. הפרת סודיות; מסכה קודם.
• השתיק את הסימפטום. הסתרת ההתרסקות עם try-catch משאירה את בעיית השורש ויוצרת בעיות חדשות.
• יישום ההצעה הראשונה מבלי לאמת אותה. האבחנה של AI היא השערה; אשר בקוד.
• מנסה לשחזר את זה באמולטור. שגיאות מסוימות מופיעות רק במכשיר/מצב בפועל.
• לא בודקים מחדש לאחר תיקון. ייתכן שהתיקון שבר משהו אחר; בדוק רגרסיה.

לסיכום

אחד התחומים שבהם AI מצטיין הוא קריאת יומני קריסה ומיון סיבות אפשריות; איכות האבחון משתפרת מאוד כאשר ניתן הקשר. אבל האבחנה והתיקון הסופיים שייכים לאדם: ההצעה של ה-AI היא השערה, מאומתת בקוד ובבדיקה. המטרה היא לא להשתיק את הסימפטום אלא לפתור את הסיבה השורשית; השגיאה המושתקת חוזרת בדרך כלל בצורה אחרת. יומני קריסה עשויים להכיל נתונים אישיים; מסווה אותו לפני מתן אותו ל-AI ואל תכתוב נתונים אישיים ביומנים שלך מההתחלה.

משימת יישום

קח יומן קריסה שיש לך (או את הדוגמה שאתה מייצר מה-AI), מסווה בו כל נתונים אישיים/מיוחדים, ותן אותו ל-AI עם "תבנית ניתוח התרסקות". הבדיל אילו מרשימות השורש של AI הן תיקונים ממשיים ואילו רק משתיקות. החל את התיקון הקבוע שבחרת וודא שהשגיאה נעלמה ושלא מתעוררות בעיות חדשות.

רשימת בדיקה

• [ ] נתתי את יומן הקריסה עם הקוד הרלוונטי ותרחיש ההקשר
• [ ] הסתרתי נתונים אישיים/מיוחדים ביומנים
• [ ] ביקשתי מ-AI סיבת שורש ותיקון קבוע, לא השתקה
• [ ] אימתתי את האבחנה בקוד ובבדיקה, לא יישמתי אותה בצורה עיוורת
• [ ] לאחר התיקון, בדקתי שהשגיאה נעלמה ולא הייתה רגרסיה
• [ ] בדקתי שהאפליקציה שלי לא כותבת נתונים אישיים ביומנים שלה