בסיס קוד מיושן: היכן ריפקטורינג קוד ב-AI נתקע
התקלה היקרה ביותר בקוד מיושן נראית שגרתית: תיקון של תנאי אחד במודול החישובים גורר אחריו בנייה מחדש של הדיווח, של החלפת הנתונים עם מערכות חיצוניות ושל חישוב מחדש לילי של היתרות.
השינוי עצמו אורך שעות, והבדיקה — מחזור שחרור שלם, כי את הרשימה המלאה של המקומות המושפעים אף אחד לא מחזיק בראש.
השורש — הצימוד בין המודולים והתלויות הנסתרות. לוגיקת המיסוי משוכפלת בשלושה מקומות, המצב משתנה ממטפלי אירועים תוך עקיפת שכבת הגישה לנתונים, וחלק מהקריאות עוברות ישירות דרך השכבות.
ניתוח סטטי ברמה של SonarQube יראה כפילויות ומתודות ארוכות, אבל לא יראה שהסרת ענף "מת" שוברת את החישובים עם הלקוחות — הידע הזה חי אצל שני מהנדסים והולך איתם.
החוב הטכני כאן נמדד לא בשורות, אלא במחיר השינוי: חלקם של התיקונים הנוגעים ביותר מחמישה קבצים עולה, וחלקם של התיקונים עם תוצאה צפויה יורד.
בדיוק על זה ריפקטורינג קוד ב-AI נתקע — המודל משכתב בביטחון קובץ בודד, אבל לא רואה את המערכת: בלי מפת תלויות כל "שיפור" או שלא משנה דבר, או שמשחזר את אותו צימוד בתחביר חדש.
אנחנו מפרקים כיצד זה נסגר: תחילה נבנית מפת קשרים וכפילויות על פני המאגר, אחר כך השינוי נחתך לצעדים, שכל אחד מהם נבדק בבדיקות ויכול להיות מוחזר אחורה.
מהירות הבנייה, סוג הכשלים שנעלמו, זמן הפיתוח הנוסף
האפקט של הריפקטורינג נמדד לא ב"נהיה נקי יותר", אלא בארבעה מספרים: זמן הבנייה, זמן הרצת הבדיקות, מספר תיקוני ההד לפר מאה שינויים וחלקם של השחרורים עם החזרה אחורה.
אנחנו מודדים את הערכים הללו לפני ההתחלה וחוזרים על כך אחרי — אחרת השיחה על איכות הקוד נשארת עניין של טעם ואינה מוגנת בישיבת התכנון.
סוג הכשלים הראשון שנעלם — פניות לערכים ריקים, מרוצי תנאים בכתיבה מקבילה למטמון משותף, חריגות שלא טופלו בקריאות אסינכרוניות. כללי הניתוח נבנים לפרויקט באופן ידני: הסטים הבסיסיים ב-SonarQube מייצרים הרבה רעש, והצוות מתרגל לדפדף בדוח בלי לקרוא. סט מוגדר חותך את הפגמים הללו לפני מיזוג הענף, ולא בניתוח אירוע.
זמן הבנייה וזמן הבדיקות יורדים בזכות הסרת כפילויות של לוגיקה וענפים מתים: הבנייה מתקצרת מ-18 ל-7 דקות, הרצת הבדיקות — מ-40 ל-15, כי הסט מפסיק להריץ נתיבים שאינם בשימוש. כיסוי הבדיקות על הקוד שהשתנה עולה משליש לשני שלישים — הרגרסיה נתפסת לפני השחרור, ולא ביום הפריסה.
את זמן הפיתוח הנוסף אוכלים תיקוני ההד: אותה שגיאה בדיוק חיה בחמש עותקים של פונקציה ומתוקנת חמש פעמים במקומות שונים. לאחר חילוץ מודולים משותפים, התיקון נעשה פעם אחת, ולא בארבעה מקומות.
יציבות השחרורים עולה בהתאם: שיעור ההחזרות אחורה יורד פי שלושה, תיקוני חירום בפרודקשן מפסיקים להיות נוהג קבוע, ותכנון האיטרציה הבאה לא מתפורר.
מצבי אוטומציה: ניתוח מרוכז, מפולח, היברידי
בחירת המצב נקבעת לפי שני מאפיינים של הבסיס: הנפח והצימוד. אם המודולים מחליפים נתונים דרך מבנים משותפים ועשרות נקודות קריאה, אי אפשר להכניס תיקונים באופן מבודד — תחילה מקבעים את גבולות השינויים ואת סדר יישומם. להלן השוואה לפי הקריטריון "מתי מתאים / מגבלות", שבו אנחנו משתמשים בשלב ההערכה.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| ניתוח מרוכז | בסיס עד מאות אלפי שורות, המודולים בעלי צימוד חלש, נדרש מעבר חד-פעמי על כל הקוד | במונוליטים גדולים גדלים זמן ההרצה ומספר הקונפליקטים; סקירת שינויים בגוש אחד מעמיסה על המבקר |
| עיבוד מפולח | בסיס גדול או צימוד גבוה, התיקונים נוגעים בקטעים קריטיים | יותר מחזורי תיאום, יש לעקוב אחרי המצב בין המנות |
| מצב היברידי | בסיס מעורב: חלק מהמודולים אוטונומיים, חלק צמודים זה לזה | נדרשת מפת תלויות וכללים שלפיהם נקבע איזה קטע נכנס לאיזו תור |
| תיקונים אינקרמנטליים | פרויקט ארוך, הקוד משתנה במקביל לעבודה | עובד רק כשמוגדרות בדיקות אוטומטיות בצינור הבנייה |
בפועל, לרוב אנחנו מתחילים בניתוח מרוכז על מודולי הפריפריה: הוא מראה במהירות היכן הצימוד גבוה מהצפוי, ומדייק את מפת התלויות. אחר כך הליבה הצמודה עוברת לעיבוד מפולח, ואת השאר מרימים התיקונים האינקרמנטליים. מצב היברידי כזה נותן גודל מנה צפוי לסקירה — המבקר רואה גוש לוגי אחד שלם, ולא מאה שורות מפוזרות.
כיצד בנויה העבודה: מניתוח המאגר ועד ההעברה
ריפקטורינג בהשתתפות המודל מתחיל לא בתיקונים, אלא במלאי: כל עוד אין מפת תלויות וגבולות מודולים, כל שינוי אוטומטי נוגע בקוד הסמוך. לכן העבודה מתקדמת בשלבים, וכל אחד מסתיים בארטיפקט שאפשר לבדוק לפני המעבר לבא אחריו.
- ביקורת המאגר. אנחנו בוחנים את המבנה, את היסטוריית השינויים, את הקטעים המשוכפלים ואת מה שמכוסה בבדיקות. התוצר — רשימת אזורי סיכון: היכן התיקונים יניבו אפקט, והיכן לגעת בקוד יקר יותר מלהשאירו.
- מפת תלויות. אנחנו בונים גרף של קשרים בין המודולים לספריות חיצוניות, מסמנים מחזורים וקשרים סמויים דרך מצב משותף. המפה קובעת את הסדר: תחילה מודולים מבודדים, אחר כך הפריפריה, והליבה אחרונה.
- כללי הבדיקה. אנחנו מקבעים מה נחשב לשינוי תקין — סגנון, טיפול בשגיאות, איסור על מבנים מסוימים. הכללים מוטמעים בלינטרים ובבנייה, כדי לדחות את התיקון אוטומטית, ולא בסקירה.
- תיקונים מפולחים. השינויים מוכנסים בסטים קטנים, ולכל מנה מטרה אחת. הסקירה נשארת ניתנת לצפייה, ומנה כושלת אפשר להחזיר אחורה בלי לפרק את כל הנפח.
- בדיקות קבלה. אנחנו מריצים בדיקות ומשווים את ההתנהגות לפני ואחרי בתרחישי בקרה. אם אין די כיסוי, תחילה מוסיפים בדיקות לנתיבים המושפעים.
- העברה. אנחנו מוסרים את הסכמה, את כללי הבדיקה, את יומן המנות ואת הרשימה של מה שהשארנו ביודעין מחוץ לריפקטורינג.
מכאן והלאה הצוות שלכם עובד לפי אותם כללים בעצמו — בלי תלות בנו.
מה נשאר במאגר ובמסמכים לאחר ההעברה
ריפקטורינג אוטומטי מניב תוצאה רק כשהצוות ממשיך לשנות את הקוד בלי מחברי התיקונים. לכן ההעברה היא לא סט של קבצים שהשתנו, אלא סביבת עבודה: כללים שלפיהם הקוד מובא לצורה אחידה, גבולות המודולים וסדר הפעולות בעת תקלה. מה בדיוק נשאר אצלכם בידיים:
- תצורת כללים — קובצי הגדרות של ניתוח סטטי ותיקונים אוטומטיים, עם הסבר מדוע הכלל מופעל או מושבת ואילו חריגים נעשו לקוד שירש.
- סכמת המודולים — מפת הקשרים בין הרכיבים: היכן הועברו הגבולות, אילו תלויות מותרות, אלו נחשבות להפרה ונופלות בבדיקה.
- נוהל סקירה — מה בודק מחבר השינוי, מה בודקת האוטומציה, אילו פערים חוסמים מיזוג ומי מקבל החלטה במקרים שנויים במחלוקת.
- הוראות החזרה אחורה — החזרה צעד-אחר-צעד של הענף למצבו הקודם, עם בדיקת תאימות של שינויי סכמת הנתונים ובלי אובדן תיקונים שנצברו.
- תיעוד ממשקים — ההתנהגות של פונקציות ציבוריות בעת שגיאות ורשימת המקומות שבהם האוטומציה לא הופעלה בכוונה, כדי שלא ישכתבו אותם בעיניים עצומות.
- דוח כיסוי — אילו נתיבים מכוסים בבדיקות, אילו נותרו בלעדיהן ומדוע.
כל זה נמצא במאגר לצד הקוד ומתעדכן באותן בדיקות — אחרת ההוראות מתיישנות מהר יותר משמצליחים לקרוא אותן.
מקרה בוחן: ריפקטורינג של מודול תשלומים בלי לעצור את המוצר
מודול התשלומים הוא מקום שבו תיקון עולה הכי ביוקר: דרכו עוברים חיובים, החזרים והתאמות מול ספקים, וטעות נראית ללקוח מיד. לפני ההתחלה מדדנו מדידות בסיס: זמן התגובה לפעולות טיפוסיות, שיעור הכשלים לפי היומנים, המורכבות של פונקציות המפתח ואיזה חלק מהקוד מכוסה בבדיקות. המספרים הללו היו לנקודת ייחוס — לפיהם גם השווינו את התוצאה.
לפני: היכן בדיוק כאב
התרחישים העיקריים חיו בפונקציה ארוכה אחת עם הסתעפויות לכל אמצעי תשלום ולכל סוג החזר. תיקון במקום אחד נגע בשכנים, כל שינוי גרר הרצה ידנית של כל המודול, והמדידות הראו: כשליש מהלוגיקה אינו מכוסה בבדיקות אוטומטיות.
אחרי: מדידות והיעדר רגרסיות
תיקנו במנות: תחילה תשלום, אחר כך החזר, ואחר כך התראות הספק. כל מנה הופעלה במתג על תעבורה חיה — הענף החדש והישן חישבו במקביל את אותן פעולות, והתוצאות הושוו שורה-בשורה.
לאחר המסירה המורכבות של פונקציות המפתח ירדה בערך בחצי, זמן התגובה התקצר כמעט פי שלושה, והכיסוי בבדיקות עלה משליש לכמעט מלא.
רגרסיות לא אירעו: הן נתפסו בעזרת סט בדיקות על פעולות היסטוריות, הרצה מקבילה של שני הענפים והחלפה הדרגתית לפי חלקי תעבורה. סכומי ביקורת ביומן התשלומים הושוו שורה-בשורה — אי-התאמה ברשומה אחת החזירה את הגרסה הקודמת.
את המדידות לקחנו באותם כלים כמו לפני ההתחלה: SonarQube — מורכבות וכיסוי, גרפי הניטור הפנימיים — השהיות ושיעור הכשלים.
מה לעשות אם בפרויקט אין בדיקות ותיעוד ברור?
תיקונים בפרויקט בלי בדיקות נתקעים בדבר אחד: לא ברור מה נחשב לעובד. פורמלית המשימה נפתרה, אבל האם משהו נשבר בנתיב הסמוך, איש לא יכול לומר. לכן הצעד הראשון הוא לא שכתוב הקוד, אלא קיבוע ההתנהגות שהמערכת מפיקה כעת.
הקיבוע יוצא מהנצפה, ולא מהרצוי. אנחנו מריצים תרחישים אמיתיים על העתק של הנתונים, מתעדים קלטים ופלטים של מודולים ציבוריים וכותבים בדיקות אפיון שמתארות את ההתנהגות הנוכחית כפי שהיא — כולל ענפים מוזרים, עיגולים וטיפול בערכים ריקים. בדיקות כאלה אינן מתיימרות לנכונות התוצאה; תפקידן להבחין שהיא השתנתה.
במקביל נאסף תיאור המערכת: מפת המודולים, כיווני הקריאות, המקומות שבהם הנתונים משתנים, התלויות החיצוניות ותופעות הלוואי. המודל מאיץ את העבודה הזאת — קורא את הקוד ואת טיוטת המפה, והמהנדס בודק כל ענף בקריאה חיה. המסמך יוצא קצר ולעניין: לא סיכום של הקוד, אלא גבולות המודולים וההסכמות ביניהם.
מכאן — סדר התיקונים. משנים קטע אחד בכל פעם, מהפריפריה אל הליבה, ואחרי כל צעד מריצים את סט הבדיקות שנצבר. נקודות הבקרה מוצבות במקומות שבהם השינוי נראה מבחוץ: תגובה לבקשה, כתיבה למאגר, אירוע שנשלח. אם בדיקה מאדימה, החזרה למצב הקודם אורכת דקות, ולא שעות של ניתוח.
בסוף השלב הפרויקט מפסיק להיות קופסה שחורה: יש סט בדיקות להתנהגות הנוכחית, תיאור קצר של המערכת ונקודות בקרה. זו הביטוח שמאחוריו ריפקטורינג ב-AI ואוטומציית התיקונים מפסיקים להיות סיכון — כל שינוי נראה ומוחזר אחורה.
ספקות טכניים: אבטחה, פרטיות, החזרת שינויים
מהנדסים שואלים בצדק מה קורה למאגר כשמחברים אליו ריפקטורינג אוטומטי. הסוכן אינו נוגע בענף הפרודקשן: הוא עובד בקו מבודד על העתק של הקוד, והגישה ניתנת בטוקנים קצרי-מועד עם תחום ראייה למאגר אחד. הפניות והפקודות נרשמות ביומן בדיוק כמו עבור מהנדס מן השורה.
התיקונים מגיעים כסטים נפרדים של שינויים, ולא ככתיבה לענף הראשי. כל סט עובר בדיקות אוטומטיות וניתוח סטטי, השינויים מפורקים לצעדים קטנים עם תיאור מובן — מוחזרים אחורה גם תיקון בודד וגם הסדרה כולה, בלי בנייה מחדש של השחרור. להלן שלושה ספקות שנשמעים לרוב בהתחלה.
מי מקבל גישה לקוד המקור?
רק מהנדסי הפרויקט והסוכן השירותי במסגרת התפקיד שהוקצה. הגישה היא למאגר ספציפי ולפרק זמן מוגבל, וההרשאות על ענפים מוגנים נשארות בידי הצוות. בעת הצורך העבודה מתבצעת על חיתוך מנותק-מזהות — בלי היסטוריה ובלי סודות בתצורה.
האם אפשר להחזיר אחורה סדרת תיקונים?
כן. הריפקטורינג מפורק לצעדים אטומיים, ולכן מבוטל גם תיקון בודד וגם הסדרה כולה. הבדיקות והבנייה בכל צעד מראים את הנקודה שבה התנהגות המערכת סטתה מהמצופה.
מי אחראי לרגרסיות?
את הגבולות מקבעים לפני ההתחלה: אילו מודולים נוגעים, אילו חוזים נחשבים ללא שינוי, ובאילו בדיקות מאשרים את ההתנהגות. קטע לא מכוסה סוגרים בבדיקה לפני התיקון — השינוי לא עובר הלאה אם ההתנהגות נשברה.
נדון במשימה: מה לשלוח כדי לקבל הערכה ותוכנית
כדי לחזור עם הערכת עבודות ותוכנית עבודה, אין צורך בגישה מלאה לקוד — בשלב הראשון די בנתוני הקלט שבדרך-כלל נמצאים בהישג יד. מהם רואים את הנפח, את סוג המשימות, והיכן האוטומציה תניב תשואה והיכן יהיה צורך לעבוד ידנית. חשוב להסכים מראש על מגבלות הגישה: מהן תלויים גם סכמת העבודה וגם לוחות הזמנים.
- מבנה הקוד: עץ התיקיות, המודולים הגדולים ביותר, היכן מרוכזת הלוגיקה העיקרית ולאן מתכנסות התלויות.
- נפח ומצב: מספר הקבצים, הקטעים שלא נגעו בהם זמן רב, חלק הקוד שאינו מכוסה בבדיקות.
- מקומות תיקון תכופים: הקבצים שמשתנים בתדירות הגבוהה ביותר — שם הריפקטורינג משתלם מהר מכולם.
- כללי הפרויקט: הסגנון המקובל, הלינטרים, נוהל בדיקת השינויים, ומה אסור לשנות בשום תנאי.
- מגבלות גישה: האם אפשר לעבוד על העתק של המאגר, האם קיים קו מבודד, ואילו נתונים אסור להוציא מחוץ לגבולותיו.
- שתיים-שלוש משימות טיפוסיות: דוגמאות של תיקונים שהייתם רוצים להאיץ — לפיהם אנחנו מתאימים את הציפיות.
- מטרה: להאיץ את הוצאת השינויים, להפחית את מספר הפגמים או להכין הגירה לענף התפתחות אחר.
מכאן הדיון במשימה תופס שיחה אחת: אנחנו שואלים שאלות הבהרה, מתאימים את המגבלות וחוזרים עם הערכת לוחות זמנים, פירוק לפי שלבים וקריטריון מוכנות ברור. תארו את המשימה ושלחו את נתוני הקלט — זה מספיק כדי להתחיל.