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

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

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

ארבע השאלות שמחליפות את הסקירה הישנה

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

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

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

למה שכפול הוא הבעיה מספר אחת

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

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

מה עם שינויים גדולים?

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

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

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

ומה עם קוד שהסוכן כתב לפני חודש

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

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

מה לא צריך לסקור יותר

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

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