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

מפתח פותח בקשת משיכה (pull request) שמוסיפה חישוב הנחה לשירות קופה. הבדיקות עוברות את התוצאה והדיפרנציאציה קצרה. בודק מאשר אותה תוך שתי דקות עם "LGTM". שלושה חודשים לאחר מכן, חבר צוות צריך לשנות את אותה פונקציה ומגלה שהיא משלבת כללי תמחור, עיגול וגישה למסד נתונים במקום אחד. אף אחד לא יכול לומר בביטחון מה מותר לה לעשות.

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

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

מהם תרגילי סקירת קוד?

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

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

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

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

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

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

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

השווה את המשימה למה שמתרגל ומעריך את התוכנית הנוכחית שלך.

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

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

תנו לכל שלב עבודה נפרדת.

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

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

מָשׁוֹב. קשר את זה להחלטות שקיבל הסוקר. "שמת לב לבעיית העיגול אבל התגובה שלך אמרה 'זה נראה שגוי' בלי לציין איזה קלט שובר את זה" שימושי יותר מ"נמצאו 2 מתוך 4".

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

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

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

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

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

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

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

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

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

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

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

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

6. הפעל את התרגיל בשידור חי או בקצב אישי עם AhaSlides

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

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

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

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

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

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

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

שאלות נפוצות

מהם תרגילי סקירת קוד?

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

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

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

האם סקירת קוד עמיתים עוסקת בעיקר במציאת באגים?

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

איפה להתחיל

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

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