איך כותבים הערות review שסוכן קוד או תורם יכולים להפוך לתיקון בדוק?
בפוסט שלי על התרומה ל-real-browser-mcp סיפרתי על תורם שחזר אחרי review עם שני PRs נפרדים ותיקונים למקרים שעלו בבדיקה. המדריך הזה מציע דרך עבודה שאפשר להחיל על תרומה נוספת, בלי להניח שכל שינוי כבר נבדק.
בקצרה
מתארים את ההתנהגות הבעייתית, את התנאים שבהם היא מופיעה ואת התוצאה שרוצים לשמור. מבקשים תיקון ממוקד ובדיקה שתיכשל מול ההתנהגות הישנה. מפרידים בין בעיה שחוסמת merge לבין הצעת שיפור שאפשר לדחות.
מתחילים מתרחיש, לא מהעדפה
הערה כמו "צריך לסדר את זה" משאירה את העבודה האמיתית אצל מי שקיבל אותה. כדי להפוך הערה למשימה, כותבים מה אפשר לעשות במערכת ומה קורה בעקבות זאת.
בדיון הציבורי על PR מספר 60 ב-real-browser-mcp מופיעות בעיות קונקרטיות: שתי פעולות במקביל על אותו טאב עלולות ליצור שתי קבוצות, ושני חיבורים ל-debugger עלולים להשאיר יותר מטאב אחד מחובר כשעוקבים רק אחרי אחד. התגובה ב-PR מתארת גם מה צריך לבדוק. אלה מקורות לתרחיש, לא הוכחה שכל סביבת דפדפן אפשרית נבדקה.
כותבים חוזה קצר לתיקון
הנוסח הבא הוא תבנית מוצעת:
כששתי בקשות מגיעות לאותו משאב לפני שהראשונה מסתיימת, המערכת צריכה לשמור על התוצאה שסוכמה. הראה בדיקה שמשחזרת את ההתנגשות מול הגרסה הישנה, תקן את ההתנהגות והראה אותה בדיקה מול הגרסה החדשה. ציין מה לא נבדק.
את "התוצאה שסוכמה" צריך להחליף בדרישה ממשית: קבוצה אחת, חיבור אחד או הודעת שגיאה ברורה. כל אחת מאלה היא החלטה אחרת. אם אין הסכמה, פותחים דיון לפני שמבקשים מהסוכן לבחור.
מפרידים בלוקר מהצעה
ב-review אפשר להתייחס לתקלה, לשאלת תכנון ולניקיון קוד. כדאי לציין איזה סוג הערה נכתבה. הצעה לשם משתנה אינה שקולה לתיקון הרשאה, גם אם שתיהן מופיעות באותו דיון.
בתיעוד GitHub מתוארים שלושה מצבי review: תגובה, אישור ובקשת שינויים. היכולת של בקשת שינויים לחסום merge תלויה בכללי ההגנה של הענף. עצם כתיבת המילה "בלוקר" בתגובה אינה הגדרה טכנית של כלל במאגר.
שומרים את הדיון קטן מספיק לבדיקה
כששינוי כולל שני מנגנונים נפרדים, אפשר לבקש פיצול. בדוגמה הציבורית, ניהול קבוצות טאבים והטיפול ב-debugger הופרדו לשני PRs. הפיצול מאפשר לבדוק כוונה וראיות לכל חלק בלי לקשור אותם לחבילת שינויים אחת.
פיצול הוא כלי עבודה, לא יעד בפני עצמו. אם שני חלקים חייבים להיכנס יחד כדי לשמור על התנהגות תקינה, צריך לתעד את התלות ואת סדר המיזוג. סוכן יכול להכין את הענפים, אבל החלטה על החוזה המשותף נשארת אצל בעל השינוי.
בודקים מה השתנה אחרי ההערה
לפני אישור, קוראים את ה-diff החדש ואת הבדיקה שנוספה. מוודאים שהבדיקה נוגעת להתנהגות שעלתה בדיון, ולא רק לדרך שבה הקוד הנוכחי כתוב. בקשו תוצאת הרצה, גרסה ופקודה. רשימת בדיקות מתוכננת בגוף PR אינה תוצאת הרצה.
אם הסוכן מסכם "כל ההערות טופלו", החזירו אותו לרשימה המקורית. לכל הערה צריך להיות תיקון, הסבר למה אינה נדרשת או החלטה לדחות אותה. שיחה שנעלמה מהמסך אינה ראיה שהבעיה נפתרה.
מסיימים עם החלטה שאפשר לשחזר
תיקון טוב מחבר בין ההערה, הדרישה והראיה. כך מי שיקרא את ה-PR בהמשך יוכל להבין למה השינוי נכנס ומה הוא אמור לשמור. מטרת ה-review היא לשפר את ההתנהגות ולתת דרך לבדוק אותה, בלי להפוך את מי שמקבל את ההערה למנחש.
מקורות ופרטים נוספים
ההמלצות ודוגמאות הבדיקה הן דרך עבודה מוצעת. הדיון הציבורי ותיעוד GitHub ו-Chrome נבדקו ב-14.10.2026.
שאלות נפוצות
מה ההבדל בין תגובה לבקשת שינויים?
GitHub תומך בתגובה, אישור ובקשת שינויים כמצבי review. החסימה בפועל תלויה בכללי הענף, לא רק בניסוח התגובה.
האם סוכן יכול לטפל בכל הערות ה-review?
הוא יכול להכין תיקונים וראיות בגבולות שסוכמו. שאלת תכנון או שינוי בחוזה דורשים החלטה מפורשת.
מתי כדאי לפצל PR?
כשיש מנגנונים נפרדים שאפשר לבדוק בנפרד. כשיש תלות, מתעדים אותה ואת סדר הכנסת השינויים.