תיקון ושיפור מערכת קיימת

מה בודקים קודם?

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

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

מה סדר העבודה הנכון?

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

במערכות עם AI או סוכנים, חשוב להוסיף tracing, לוגים ו־guardrails כדי להבין מה קרה בכל פעולה ולזהות טעויות מהר יותר.

איך משנים קוד בלי לשבור את מה שעובד?

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

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

איך איתי קרקסון עובד על מערכת קיימת?

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

רכיבים שצריך לתכנן

שאלות נפוצות

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

רק אם המערכת לא ניתנת לתחזוקה או שהשינוי הנדרש עמוק מדי. בהרבה מקרים שיפור ממוקד עדיף.

כמה זמן לוקח לייצב מערכת?

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