מערכת ישנה שאף אחד לא מבין: איך משדרגים

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

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

קודם כל, לוודא שאפשר לחזור אחורה

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

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

סביבת בדיקה שדומה לייצור

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

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

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

לתעד את מה שהמערכת עושה, לא את מה שהיא אמורה לעשות

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

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

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

מיפוי סיכונים: איפה מתחילים

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

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

שדרוג הדרגתי במקום כתיבה מחדש

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

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

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

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

מתי כן לכתוב מחדש

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

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

הערכת זמן ואחריות

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

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

מה צוות חיצוני יכול לתרום

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

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

ארגון הידע: התיעוד שכדאי לכתוב ראשון

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

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

השורה התחתונה

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

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