אילו קבצים צריך לגעת כדי לשנות פיצ’ר אחד? מזינים operationId אחד — והתשובה מגיעה.
הבעיה
באפליקציית fullstack, “פיצ’ר אחד” לא נמצא בקובץ אחד.
נניח שצריך לשנות את הפיצ’ר AcceptProposal. הפיצ’ר הזה קיים ב-API spec, בלוגיקת ה-service, ב-database schema, במדיניות ההרשאות, בדיאגרמת מעברי המצבים, בקריאות לפונקציות חיצוניות, בתרחישי הבדיקה ובצד ה-frontend.
בעבר היו שתי דרכים לאתר את כל ההיקף:
- להריץ Grep עשרות פעמים
- לעקוב אחרי הקוד ידנית
שתיהן איטיות, ושתיהן מחמיצות דברים. במיוחד הפניות שחוצות שכבות — מ-API spec אל ה-service, מה-service אל ה-DB schema, מה-service אל מדיניות ההרשאות — קשה מאוד לאדם לעקוב אחריהן במלואן.
אבל אם כל שכבה מפנה סימבולית לשכבות אחרות, ניתן לעקוב אחרי ההפניות הללו ולגלות את ההיקף המלא אוטומטית.
מהו Feature Chain
Feature Chain מחלץ את כל ה-nodes במקור שמקושרים לפיצ’ר API אחד (operationId).
מתחילים מ-operationId אחד, עוקבים אחרי הפניות הסימבוליות בין המקורות, ומדפיסים בבת אחת את כל הקבצים ומספרי השורות הרלוונטיים. עשרות ריצות Grep מוחלפות בפקודה אחת.
fullend chain AcceptProposal specs/
── Feature Chain: AcceptProposal ──
OpenAPI api/openapi.yaml:296 POST /proposals/{id}/accept
SSaC service/proposal/accept_proposal.ssac:19 @get @empty @auth @state @put @call @post @response
DDL db/gigs.sql:1 CREATE TABLE gigs
DDL db/proposals.sql:1 CREATE TABLE proposals
DDL db/transactions.sql:1 CREATE TABLE transactions
Rego policy/authz.rego:3 resource: gig
StateDiag states/gig.md:7 diagram: gig → AcceptProposal
StateDiag states/proposal.md:6 diagram: proposal → AcceptProposal
FuncSpec func/billing/hold_escrow.go:8 @func billing.HoldEscrow
Gherkin scenario/gig_lifecycle.feature:4 Scenario: Happy Path - Full Gig Lifecycle
Gherkin scenario/gig_lifecycle.feature:42 Scenario: Unauthorized Access
המבנה המלא של פיצ’ר אחד נראה במסך אחד. שכבות שאינן מקושרות לא מוצגות.
למה זה אפשרי
זה לא קסם. זה אפשרי כי המקורות כבר מפנים זה לזה.
במסגרת fullend, כל שכבת SSOT (Single Source of Truth) מפנה סימבולית לשכבות אחרות:
@get Model.Methodב-SSaC → טבלת DDL@auth action resourceב-SSaC → מדיניות הרשאות Rego@state diagramIDב-SSaC → דיאגרמת מצבים Mermaid@call pkg.Funcב-SSaC → מימוש Func Spec- operationId ב-OpenAPI → שם קובץ SSaC
- שלב action ב-Gherkin → operationId
- endpoint ב-STML → path ב-OpenAPI
ההפניות האלה תוכננו במקור עבור crosscheck — כלי לאימות עקביות בין ה-SSOTs. מאחר ש-crosscheck כבר מפענח את ההפניות הללו, ניתן לעשות שימוש חוזר באותה תשתית ולחלץ את ה-feature chain באמצעות מעבר על הגרף בלבד.
נתיב המעבר
כשמתחילים מ-operationId, גרף ההפניות נפרש כך:
operationId (נקודת התחלה)
├── OpenAPI → path + method
├── SSaC → קובץ פונקציית service
│ ├── @get → טבלאות DDL
│ ├── @auth → חוקי מדיניות Rego
│ ├── @state → מעברי stateDiagram ב-Mermaid
│ ├── @call → מימושי Func Spec
│ └── @publish → מנויי תור
├── Gherkin → תרחישים שמפנים ל-operationId
└── STML → קבצי frontend שמפנים ל-endpoint
כל ענף עוקב אחרי שלב הפניה סימבולית אחד בלבד. זהו מעבר רחב ולא עמוק. כך נחשפים כל העקבות שפיצ’ר אחד משאיר בכל שכבה.
מה זה משנה
הבנת היקף השינוי
“איפה צריך לגעת כדי לתקן את הפיצ’ר הזה?”
כדי לענות על שאלה זו אנחנו קוראים קוד, מריצים grep ושואלים עמיתים. Feature Chain מחליף את השאלה הזו בפקודה אחת. אין קבצים שנשמטים — כל עוד קיימת הפניה סימבולית.
תיקון קוד עם AI
הדבר הקשה ביותר כשמסמיכים AI לתקן פיצ’ר הוא “להסביר לו את היקף התיקון”. כדי ש-AI יתקן בדיוק, צריך להכניס לחלון ה-context את כל הקבצים הרלוונטיים — והאדם הוא שצריך להחליט אילו קבצים רלוונטיים.
עם Feature Chain זה שונה. מספיק לספק operationId אחד וכל היקף התיקון מזוהה אוטומטית. ה-context שמועבר ל-AI מוכן ללא השמטות.
code review
כשבודקים PR, ניתן לבדוק מיד את החשד “אם שינית את הפיצ’ר הזה, לא היה צריך להשתנות גם הקובץ ההוא?” על ידי השוואה ל-chain. המבנה תופס אי-עקביות בין שכבות במקום האדם.
onboarding
כשמפתח חדש שואל “אני רוצה להבין איך AcceptProposal עובד”, מספיק להראות לו Feature Chain אחד. מה-API ועד ה-DB, ממדיניות ההרשאות ועד תרחישי הבדיקה — כל הטופוגרפיה של הפיצ’ר נראית במבט אחד.
למה operationId
חשוב לבחור נקודת התחלה. Feature Chain בחר ב-operationId.
הסיבה פשוטה. באפליקציית fullstack, יחידת הפיצ’ר היא ה-API endpoint. המשתמש לוחץ כפתור, ה-API נקרא, ה-API מריץ את לוגיקת ה-service, קורא מה-DB, בודק הרשאות ומעביר מצב. נקודת ההתחלה של כל זרם זה היא ה-operationId.
ה-operationId כבר מוגדר ב-OpenAPI spec ומשותף לכל הצוות. כשאומרים “צריך לתקן את AcceptProposal”, גם מפתח backend, גם מפתח frontend וגם QA חושבים על אותו דבר. עיצוב Feature Chain הוא לחצות את כל ה-stack עם שם אוניברסלי אחד.
תנאים מוקדמים
כדי ש-Feature Chain יעבוד, יש תנאים:
המקורות חייבים להפנות זה לזה סימבולית. ה-directives
@get, @auth, @state, @callב-SSaC חייבים להצביע במפורש על ה-SSOTs האחרים. אם ההפניה מרומזת — למשל, שם טבלת DB קיים בקוד רק כ-string — לא ניתן לעקוב אחריה.חייבים לעבור crosscheck. Feature Chain עוקב אחרי הפניות סימבוליות, ולכן אם הפניה אינה תקפה התוצאה תהיה שגויה. crosscheck מבטיח את עקביות ההפניות, ו-Feature Chain מבצע את המעבר על גביו.
זו הסיבה ש-Feature Chain אינו כלי כללי. לא ניתן להחיל אותו על כל פרויקט. הוא עובד רק בפרויקטים שבהם ההפניות בין המקורות מתוכננות — מבנים כמו fullend שבהם ה-SSOTs מצביעים זה על זה במפורש.
עתיד: GEUL + SILK
כיום Feature Chain עובר על כל parser של SSOT לחילופין. הוא קורא ל-SSaC parser, ל-DDL parser, ל-Rego parser ול-Mermaid parser בנפרד ומשלב את התוצאות.
כשכל ה-SSOTs יומרו לגרף GEUL, Feature Chain יהפוך לשאילתת index אחת. בעזרת פעולת AND ביטית של SIDX ב-SILK, ניתן יהיה לחלץ את כל ה-nodes המקושרים ל-operationId בשאילתה אחת.
ממעבר לפי parser לשאילתת גרף. הממשק של Feature Chain יישאר זהה, אבל הפנים ישתנו מהותית.
סיכום
באפליקציית fullstack, “פיצ’ר” לא נמצא בקובץ אחד. הוא פרוס על פני שכבות רבות, והשכבות מפנות זו לזו. Feature Chain עוקב אחרי ההפניות הללו ומחלץ אוטומטית את ההיקף המלא של פיצ’ר אחד.
מזינים operationId אחד, ומ-API spec ועד DB schema, ממדיניות הרשאות ועד תרחישי בדיקה — עשרות ריצות Grep מוחלפות בפקודה אחת.