Coroid מסיים את פעולתו על ידי פתיחת pull request בענף נפרד, מול הענף הבסיסי שלך. הוא אינו מבצע מיזוג. ההחלטה נותרת בידיך.
מה מגיע יחד איתו
- שינוי הקוד
- מבחנים שנכתבו או עודכנו יחד עם השינוי
- תוצאת ריצת חבילת המבחנים הקיימת שלך
- תוצאת בדיקות האיכות שהארגון שלך הגדיר
- בדיקה של ה־diff, עם ממצאים שכבר תוקנו או רשומים ברשימה
המטרה אינה להחליף את הבדיקה שלך. המטרה היא שהבדיקה שלך לא תהיה הראשונה.
מה בדיוק לבדוק
הדברים המכניים כבר נבדקו. הקדש את תשומת ליבך לדברים שרק אתה יכול לשפוט:
- האם זה פותר את הבעיה הנכונה? השווה זאת לקריטריוני הקבלה של המפרט, ולא לזיכרון שלך לגבי מה שביקשת.
- האם זה מתאים למאגר הקוד? כללי קידוד, שמות, צורת ההפשטה. Coroid קורא את הקוד שלך כדי להסיק את הכללים האלה, ובדרך כלל מנחש נכון – אך לא תמיד.
- על מה זה משפיע שלא ציפית לכך? התבונן ברשימת הקבצים לפני ה־diff.
- האם המבחנים החדשים משמעותיים? מבחן שעובר אך אינו מאשר דבר גרוע יותר מאשר отсутствие מבחן.
החזרת עבודה
יש לך שלוש אפשרויות, בסדר עולה מבחינת עלות:
- הוסף תגובה ובקש שיפוץ — המשימה חוזרת לסוכן המפתח עם הממצאים שלך, תוך שמירה על ההקשר שלה. הטוב ביותר למקרים של "זה נכון אך חסר".
- דחה את התוכנית ובצע ריצה מחדש — כאשר הגישה שגויה, ולא הביצוע.
- בטל את המשימה — כאשר העבודה אינה צריכה להתבצע כלל. ביטול עוצר את הריצה ומשחרר את מקום הסוכן.
היות ספציפי בתגובות לגבי שיפוץ כפי שהיית עושה עם עמית. "זה אינו מטפל במקרה הריק ב‑ parseRange" מניב תיקון; "זקוק לשיפוץ" מוביל לניחוש.
ביצוע מיזוג
בצע מיזוג דרך הספק שלך, תוך שימוש בהגנת הענפים, בדיקות החובה וכללי האישור הרגילים שלך. Coroid פותח את ה־pull request; התהליך הקיים שלך קובע מה יקרה איתו.
שום דבר בנוגע למיזוג אינו ייחודי – וזו כוונה מכוונת. ה־pull request הוא רגיל לחלוטין, כך שהוא עובר דרך אותן בדיקות ותהליכי CI שאתה כבר סומך עליהם.
הבא
לאן ללכת הלאה — מפנה ליתר התיעוד לפי מה שאתה מנסה לעשות.