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

מפתח מבקש מעוזר פונקציה שבודקת האם משתמש רשאי להוריד דוח. הקוד עובר קומפילציה. בדיקת ה-happy-path עוברת. בקשת ה-pull נראית מסודרת. שבועיים לאחר מכן, עמית שם לב שהפונקציה בודקת שהמשתמש מחובר, אך לעולם לא בודקת שהדוח שייך לו.

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

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

מהי הכשרה לסקירת קוד שנוצרה על ידי בינה מלאכותית?

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

עובדות מהירות

1. תאר את בעיית הביצועים

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

המחקר מציע מדוע זה דורש תרגול מכוון. במחקר של GitHub Copilot, פירס ועמיתיו יצרו 1,689 תוכניות על פני 89 תרחישים שנבחרו עבור סוגי חולשות ידועים ומצאו שכ-40 אחוז מהן היו פגיעות (פירס ועמיתיו, 2021). זה היה כלי מוקדם וקבוצה ספציפית של תרחישים, לכן אין להתייחס לנתון כשיעור לעוזרים של ימינו. מחקר משתמשים נפרד ביקש מהמשתתפים לכתוב קוד עם ובלי עוזר בינה מלאכותית. אלו עם העוזר כתבו קוד פחות מאובטח באופן משמעותי, והיו נוטים יותר להאמין שהקוד שלהם מאובטח (פרי ועמיתיו, 2023אותו מחקר מצא כי משתתפים שסמכו פחות על העוזר ועסקו יותר בהנחיותיו יצרו פחות פגיעויות.

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

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

2. אבחון פערים בלמידה ובהקשר

לפני שאתם בונים משהו, השוו את המשימה למה שהתוכנית הנוכחית שלכם מתרגלת ומעריכה. שלוש שאלות בדרך כלל מפרידות בין פער אימון לדבר אחר:

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

3. הכנה ותרגול עיצובי

ברגע שאתם יודעים אילו פערים אימון יכול לסגור, תנו לכל שלב תפקיד ייחודי.

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

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

מָשׁוֹב. קשרו זאת להחלטות במקום לציון כולל. "סימנת את הלולאה אבל לא את המירוץ במונה המשותף, והבדיקה שלך לא הייתה תופסת אותה מכיוון שהיא מריץ בקשות אחת בכל פעם" שימושי יותר מ"נמצאו 2 מתוך 3".

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

4. עבדו על דוגמה מציאותית

לדוגמה. מנהל הנדסה צריך לאמת את המקרה ואת קריטריוני התשובה לפני השימוש.

המקרה. נקודת קצה שנוצרה מחזירה חשבונית של לקוח לפי מזהה חשבונית. היא בודקת שלמתקשר יש סשן תקין, משתמשת בשאילתה פרמטרית ועוברת את הבדיקה הבסיסית. אותה פונקציה מגדילה מונה הורדות משותף ללא נעילה.

המשימה. היזם מציין כל סיכון שהוא רואה, מדרג אותו ומתאר את המבחן שיאשר כל אחד מהם.

ניסיון ראשון. "נראה בסדר. השאילתה עברה פרמטרים והבדיקה עברה את המבחן." המפתח התייחס לבדיקה שעברה את המבחן כהוכחה ולא שאל מה הבדיקה לא מכסה.

משוב וניסיון חוזר. הבודק מבקש מהמפתח לציין מה בדיקת הסשן מוכיחה ומה היא לא. בניסיון החוזר יש לשקול שני לקוחות שונים ושתי בקשות בו זמנית.

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

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

5. הערכת יכולות והעברת תוכנית

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

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

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

היכן שהעברת מידע אינטראקטיבית עוזרת

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

מדוד מה השתנה

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

אילוצים שעשויים להישאר

• זמן סקירה. ביקורת אורכת יותר זמן מסקימה, ומועדי הביקורת דוהרים לכיוון הסקימה.
• כלי עבודה. ללא רתמת בדיקה או סריקה בצנרת, קשה לאמת סיכון.
• החלפת כלים. עוזרים מתחלפים במהירות, לכן חשוב לשמור על תרגילים המתמקדים בהרגל הסקירה, ולא במוצר אחד.
• כיסוי תיקים. תרגיל אחד מציג כמה סוגי פגמים. ציון אינו מתאר את שיקול הדעת של המפתח באופן כללי.
• לְהַעֲבִיר. הופעה בסדנה אינה זהה להופעה בתור עמוס לסקירה.

יש לציין את הנקודות הללו לנותני החסות מוקדם ולתכנן תיקונים נפרדים. הדרכה משפרת את מה שמפתח יכול למצוא ולהוכיח. היא לא יוצרת את הזמן או את הכלים הדרושים.

שאלות נפוצות

מהי הכשרה לסקירת קוד שנוצרה על ידי בינה מלאכותית?

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

האם קוד שנוצר פחות מאובטח מקוד אנושי?

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

כיצד אתם מעריכים האם מפתחים יכולים לבצע ביקורת על קוד שנוצר?

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

האם אתה צריך ארגז חול של קוד עבור ההדרכה?

אתם צריכים מקום שבו תוכלו לבצע את התרגילים, שבדרך כלל תהיה הסביבה שלכם. ודאו שכל כלי בו אתם משתמשים תומך במה שאתם צריכים לפני שאתם מסתמכים עליו.

איפה להתחיל

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

כדי לראות כיצד ניתן להפעיל תרגיל ביקורת בשידור חי עם הצוות שלכם, ולהשתמש בו שוב בקצב אישי לאחר מכן, חקרו AhaSlides.