הכלי שיגרום לקוד שלכם לדבר GitHub Copilot Spaces

Jane Bot
לפני 5 ימים
זמן קריאה 4 דקות

עודכן: לפני יום אחד (1)

הכלי שגורם לקוד הארגוני לדבר GitHub Copilot Spaces

אתם מכירים את הרגע הזה שבו מישהו מהצוות שואל שאלה תמימה?

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

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

ואז עצרתי רגע. אם כבר יש לנו AI שעוזר לכתוב קוד, למה שהוא לא יעזור לנו גם להנגיש את הקוד בצורה קריאה?

חיפשתי פתרונות, בדקתי כיוונים, ואז גיליתי שהפתרון היה לי ממש מתחת לאף: GitHub Copilot Spaces.

הכירות קצרה, מה זה Space?

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

בתוך ה־Space אפשר לרכז תכולות שונות כמו repositories, קבצים, pull requests, issues, טקסט חופשי, מסמכים וקבצים נוספים. לאחר מכן אפשר לשאול את Copilot שאלות שמבוססות על כל ההקשר הזה, ולא רק על קובץ בודד או repository אחד.

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

כשתהליכים שלמים הולכים לאיבוד

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

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

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

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

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

ופה Copilot Spaces נכנס לתמונה.

כשאין תיעוד הקוד הוא מקור האמת

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

מה שרציתי לקבל זה משהו אחר לגמרי: מסמך מסודר / workflow שמסביר מה התהליך.

כלומר, לא תשובה טכנית, אלא הסבר עמוק לתהליך. אפיון פונקציונלי. PRD.

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

איך מתחילים?

אז למי שיש היום GitHub Copilot בארגון, אפשר להיכנס לאזור האישי שלו ומשם לגלוש ל: https://github.com/copilot/spaces

לבנות Space חדש, לבחור את הארגון, את ה־repos ועוד מקורות מידע.

בנוסף, אפשר להגדיר Instructions שהן ההוראות שמגדירות ל Copilot איך לענות. במקום לשאול שאלה נקודתית כמו “איפה מוגדר login?”, עדיף לשאול שאלה רחבה יותר, למשל: "תסביר לי איך עובד תהליך ההזדהות מקצה לקצה, כולל טיפול בשגיאות."

באותה צורה, במקום לשאול “מה עושה הפונקציה הזאת?”, אפשר לבקש מ־Copilot לנתח תהליך שלם ולשאול: "תנתח את התהליך העסקי XXX, תציג את הזרימה המלאה, ותציין אילו מערכות צד שלישי מעורבות."

המטרה היא לא להשתמש ב־Copilot רק כדי למצוא שורה בקוד, אלא כדי להבין תהליך שלם, את ההיגיון שמאחוריו, ואת המקומות שבהם הקוד מתחבר למערכות אחרות בארגון.

היתרונות ברורים

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

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

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

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

ומה קורה כשאורי בחופש? או במילואים? או החליט להרים טברנה בסלוניקי? הבנתם את הפואנטה :)

אל תבקשו תשובה, תבקשו מסמך אפיון

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

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

לכן אני ממליץ להגדיר ל־Space הנחיות קבועות מראש, ולא להסתפק בשאלה כללית. במקום לקבל “תשובה של צ’אט”, אפשר לבקש מ־Copilot לייצר מסמך מובנה לפי פורמט קבוע.

לדוגמה, אם אתם רוצים לנתח תהליך קיים מתוך הקוד, אפשר להשתמש בפרומפט:

כתוב מסמך ניתוח מסודר על בסיס הקוד והמקורות הקיימים ב-Space.
מבנה המסמך:
1. מטרת המסמך
2. הסבר עסקי
3. הסבר התהליך / הזרימה
4. ממצאים מתוך הקוד
5. נקודות לא ברורות / חסרות בקוד
6. סיכונים או בעיות אפשריות
7. המלצות
8. עדויות מהקוד

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


אפיון טכני: [שם הפיצ׳ר / השינוי]
כתוב אפיון טכני מסודר על בסיס הקוד, המסמכים והמקורות הקיימים ב-Space.
מבנה האפיון:
1. מטרת הפיצ׳ר
2. מצב קיים לפי הקוד
3. דרישה פונקציונלית
4. פתרון טכני מוצע
5. תהליך flowchart digram
6. מבנה API, פרמטרים ומבנה
7. מבני נתונים, טבלאות ופרוצדורות
8. תהליכים
9. אבטחת מידע והרשאות
10. שגיאות
11. עדויות מהקוד

כבר לא מדובר בתשובה קצרה מהצ’אט, מדובר בבסיס למסמך מקצועי.