פיתוח חבילת Bagisto מותאמת אישית עד הסוף

חבילת Bagisto מותאמת אישית: היכן נשברת הלוגיקה הסטנדרטית

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

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

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

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

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

מה נותן חבילה מבודדת: האפקט במספרים

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

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

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

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

אפשרויות מימוש: חבילה, תבנית או עריכת הליבה

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

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

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

תאימות לעדכונים

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

תרחיש משולב

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

שלבי הטמעת החבילה: מה� audits ועד למסירה

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

1. Audit של החנות. בוחנים את התצורה הנוכחית, ההרחבות המותקנות, התאמות אישיות של התבנית והליבה, נקודות ההתערבות בתהליך ביצוע ההזמנה ובקטלוג. מתעדים מה ניתן להרחיב באמצעים סטנדרטיים ומה דורש דריסה — זה קובע את היקף העבודה לפני תחילת הפיתוח.
2. סכמת החבילה. מתכננים את המבנה: אילו ישויות וטבלאות מתווספות, באילו אירועים ומאזינים אנו משתמשים, כיצד החבילה מתקשרת עם המודולים הקיימים. את הסכמה מתאמים אתכם לפני כתיבת הקוד — תיקונים בשלב זה עולים שעות, לאחר השחרור — ימים.
3. הגדרת אינטגרציות. מחברים את החבילה למערכות חיצוניות: מחסן, תשלומים, משלוח, מערכות חשבונאיות. כל חיבור מוגדר עם טיפול בשגיאות וניסיונות חוזרים, כדי שכשל בצד השירות לא יפיל את תהליך ביצוע ההזמנה.
4. בדיקת תרחישים. מריצים את המסלול המלא של הקונה — מהוספת מוצר ועד אישור התשלום, כולל החזרות, ביטולים חלקיים ועבודה עם מספר מחסנים. בנפרד בודקים את ההתנהגות כאשר שירות חיצוני אינו זמין.
5. מסירת תיעוד. מוסרים תיאור של ארכיטקטורת החבילה, הוראות לעדכון ולחזרה לאחור, סכמת הנתונים וסדר הפעולות בתקלות טיפוסיות. המהנדסים שלכם יכולים לתחזק את החבילה באופן עצמאי, ללא תלות בנו.

השלבים מתנהלים עם נקודות בקרה: לאחר ה-audit אתם רואים את ההיקף והתוכנית, לאחר הסכמה — מתאמים את הארכיטקטורה, לאחר הבדיקה — מקבלים דוח לפי תרחישים. תארו את המשימה — נחזור עם הערכת לוחות זמנים והרכב העבודה.

תוצרי מסירה: מה מקבלת צוות הלקוח

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

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

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

מקרה בוחן: כיצד חבילה מבודדת הסירה רגרסיות

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

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

מה היה לפני

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

מה שינו

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

מה נהיה

עדכון הפלטפורמה הצטמצם לכמה שעות: תיקונים בחבילה אינם מתנגשים עם הליבה, והחזרה לאחור היא ניתוק של תלות אחת. מספר הכשלים בסביבת הייצור ירד מ-9-12 ל-1-2 ברבעון, כיסוי הבדיקות גדל לרוב נתיבי המשתמש, והשחרורים החלו לצאת בתדירות כפולה ללא תיקונים בלילה.

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

במה שונה חבילה מעריכה ישירה של הליבה?

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

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

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

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

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

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

ספקות טכניים נפוצים בפיתוח חבילה

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

כיצד מועברים נתונים ממערכת ישנה ללא אובדן?

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

כיצד אתם בודקים את החבילה ומה עם עדכון ללא השבתה?

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

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

נדון במשימה שלכם ונחזור עם תוכנית

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

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

מה קורה לאחר הפנייה

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

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