תכנון וביצוע ב-Spec Mode

בפרק הקודם השתמשנו ב-Vibe Mode כדי להוסיף אלמנטים פשוטים כמו כפתור ביטול. גישה זו עובדת בצורה מושלמת כשהדרישות פשוטות וההיקף של המשימה ברור. אבל מה קורה כשאתם צריכים לבנות פיצ'ר שחוצה מספר קבצים וגבולות שונים במערכת?

כאן נכנס לתמונה ה-Spec Mode. פיתוח מונחה-Spec מפריד למעשה את שלב התכנון (Design) משלב המימוש עצמו. מצב זה מאפשר לכם להגדיר דרישות ברורות לפני כתיבת הקוד, לקבל החלטות ארכיטקטוניות מראש, ולפרק פיצ'רים מורכבים למשימות שקל לנהל.

מתי לבחור ב-Vibe ומתי ב-Spec?

כדי לעשות סדר, המערכת של Kiro מציגה בחירה ברורה בין שתי הגישות בכל פעם שמתחילים משימה חדשה:

אז איך בוחרים את מסלול העבודה הנכון? הנה המדריך המהיר לקבלת החלטות:

• מתי להשתמש ב-Vibe Mode: כאשר מדובר בשינוי של קובץ אחד (לרוב UI בלבד), או בשינויים של 1-2 קבצים הכוללים לוגיקה פשוטה.
• מתי להשתמש ב-Spec Mode: כאשר השינוי דורש תיאום בין ה-Frontend ל-Backend, או כשאתם צריכים ליצור מודל נתונים (Data model) חדש למערכת. בנוסף, זהו המצב האידיאלי כאשר לפיצ'ר שלכם יש מספר קריטריוני קבלה (Acceptance criteria) שונים או כאשר יש צורך בסקירת העיצוב על ידי הצוות לפני תחילת היישום.

זרימת העבודה (The Workflow): שלושת שלבי הברזל

ברגע שתזינו את הבקשה הראשונה שלכם ב-Spec Mode, תגלו ש-Kiro לא מתחיל "לזרוק" קבצים בצורה עיוורת. המערכת עוצרת ושואלת אתכם סדרת שאלות מיקוד (Input required) כדי להבין בדיוק מה הכוונה שלכם ואיך תרצו לנהל את התהליך:

שלב השאלות המקדימות

• הגדרת המשימה: תחילה, המערכת תשאל האם אתם בונים פיצ'ר חדש (Build a Feature), מתקנים באג מורכב (Fix a Bug), או רוצים "תוכנית מהירה" שתייצר דרישות ועיצוב אוטומטית ללא צורך באישורכם (Quick Plan).

• נקודת ההתחלה: אם בחרתם בבניית פיצ'ר (המסלול המומלץ), Kiro ישאל מאיפה תרצו להתחיל. תוכלו לבחור לאסוף ולתעד קודם את מסמך הדרישות (Requirements), או לדלג ישר לעיצוב הטכני (Technical Design) ולגזור את הדרישות ממנו בדיעבד.

יצירת מסמכי התכנון

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

שלב 1 - דרישות (requirements.md)

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

שאלות הבהרה (Trade-offs)

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

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

סקירה, אישור והמשך התהליך (Review & Continue)

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

מה אפשר לעשות בשלב הזה?

• בקשת שינויים בצ'אט: אם משהו חסר או דורש דיוק, פשוט כתבו ל-Kiro בחלונית הצ'אט והוא יעדכן את המסמך עבורכם מיד.
• תפריט ה-Continue: כשאתם מרוצים מהדרישות, לחיצה על כפתור "Continue" תפתח את אפשרויות ההמשך:
  • Generate Design: התקדמות לשלב הבא ויצירת מסמך העיצוב הטכני (design.md) בלבד.
  • Generate Design & Tasks: "הילוך מהיר" – יצירת מסמך העיצוב ומיד לאחריו יצירת מסמך המשימות (tasks.md) ברצף אחד.
  • Analyze requirements: הרצת ניתוח נוסף על הדרישות הקיימות כדי לוודא ששום מקרה קצה לא התפספס לפני שעוברים לעיצוב טכני.

שלב 2 - עיצוב (design.md)

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

• תקציר (Overview): סקירה ברורה של מהות הפיצ'ר או התיקון ברמת הקוד, שמסבירה אילו קבצים או חלקי מערכת הולכים להשתנות.
• ארכיטקטורה (Architecture): פירוט של השינויים המבניים במערכת (או ציון מפורש שאין כאלו, אם מדובר בתיקון נקודתי). לעיתים קרובות, Kiro ייצר כאן דיאגרמות טקסטואליות (כמו תרשימי זרימה ב-ASCII) כדי להמחיש בצורה חזותית את מבנה הרכיבים.
• רכיבים וממשקים (Components and Interfaces): ירידה לפרטים הטכניים העמוקים ביותר, כולל שמות מדויקים של מחלקות (Classes), פונקציות, וקטעי קוד (Markup/CSS) שיתווספו. סעיף זה כולל גם הסבר על "החלטות העיצוב" (Design decisions) שהתקבלו – למשל, מדוע נבחר צבע מסוים או למה נבחרה מתודולוגיית כתיבה ספציפית.
• מודל הנתונים (Data Models): תיאור של כל שינוי במסדי הנתונים, במצב האפליקציה (State ב-Frontend), או בקריאות ה-API.
• טיפול בשגיאות (Error Handling): הגדרה של נתיבי שגיאה חדשים במידה וישנם, או ציון מפורש שהפיצ'ר אינו פוגע במנגנון השגיאות הקיים.
• תכונות נכונות (Correctness Properties): סעיף מתקדם המגדיר הצהרות פורמליות לגבי ההתנהגות המצופה מהמערכת (למשל, "המודל לעולם לא יעבור גובה מסוים"), המשמשות כגשר בין הדרישות האנושיות למערכות בדיקה.
• אסטרטגיית בדיקות (Testing Strategy): תכנון מפורט של בדיקות יחידה (Unit tests) ובדיקות מקיפות אחרות שנועדו לוודא כי הקוד החדש עומד בכל הדרישות והתכונות שהוגדרו.

שלב 3 - משימות (tasks.md)

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

הנה מה שהופך את מסמך המשימות לכלי עבודה עוצמתי:

• תקציר ואסטרטגיה (Overview): המסמך נפתח בהסבר על אסטרטגיית הפיתוח. הוא מוודא שכל משימה נבנית על גבי הקודמת (Incremental progress) ושלא נשאר קוד "באוויר" שאינו מחובר למערכת.
• הפעלת משימות נקודתית (Start task): מעל כל תת-משימה מופיע כפתור פעולה (עם סמל של ברק). לחיצה עליו תגרום ל-Kiro להתחיל לכתוב את הקוד הספציפי של אותה משימה, מה שמאפשר לכם לבקר את הקוד צעד אחר צעד.
• הרצה אוטומטית (Run all tasks): מרגישים בטוחים בתכנון? בראש המסך תמצאו כפתור סגול להרצת כל המשימות. לחיצה עליו תעביר את Kiro למצב של "טייס אוטומטי" שבו הוא יבצע את כל המשימות ברצף.
• פירוק טקטי: המשימות הגדולות מפורקות לצעדים קטנים וממוקדים (למשל, 1.1). כל סעיף כולל הנחיות מדויקות לאילו קבצים יש לגשת, איזה קוד להוסיף, ולעיתים גם אזהרות לגבי קוד שאסור לגעת בו.
• מעקב דרישות (Traceability): בתחתית כל משימה תראו קישור ישיר לדרישות שעליהן היא עונה (למשל, Requirements: 1.1, 1.3). הקישוריות הזו מבטיחה שום סעיף מהאפיון לא "נופל בין הכיסאות" במהלך הפיתוח.

לסיכום – מה למדנו בפרק זה?

• ההבדל בין הגישות: הבנו מתי נכון להשתמש ב-Vibe Mode (לשינויים נקודתיים ומהירים) ומתי חובה לעבור ל-Spec Mode (עבור פיצ'רים מורכבים שדורשים תיאום בין Frontend ל-Backend ומספר קבצים).
• שלושת שלבי הברזל: הכרנו את זרימת העבודה המובנית ב-Spec Mode, שמתחילה משלב איסוף הדרישות (requirements.md), עוברת לתכנון הארכיטקטורה (design.md), ומסתיימת בגזירת המשימות לביצוע (tasks.md).
• דיוק דרישות (Trade-offs): ראינו כיצד המערכת לא מנחשת כוונות, אלא מציגה לנו שאלות הבהרה (אפשרות פשוטה מול מורכבת) כדי להבטיח שהפיצ'ר יתנהג בדיוק כפי שאנחנו רוצים.
• מסמך משימות חכם: גילינו שקובץ ה-tasks.md הוא לא רק רשימת טקסט, אלא לוח בקרה אינטראקטיבי שמאפשר להריץ משימות בודדות, לעקוב אחרי התלויות שלהן לדרישות המקוריות, או להפעיל את הכל על "טייס אוטומטי".
• אתם תמיד על ההגה: הפנמנו את הכלל החשוב ביותר בפיתוח מונחה-Spec – המערכת מחכה לסקירה ולאישור שלכם (Review & Continue) בכל אחת מהתחנות בדרך, מה שמבטיח שליטה מלאה בתוצר הסופי.