מודרניזציה של תוכנה ישנה בלי שכתוב מאפס

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

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

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

למה השכתוב מאפס כל כך מפתה — וכל כך מסוכן

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

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

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

מה ״מורשת״ באמת אומר (זה לא קשור לגיל)

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

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

אבחנו לפני שאתם נוגעים בכל דבר

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

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

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

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

גישת ה-Strangler: החליפו אותה חלק אחד בכל פעם

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

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

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

איך הקצב באמת נראה

1. 1
   בחרו את החלק הכי כואב והכי עצמאי

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

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

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

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

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

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

לפעמים אתם בכלל לא צריכים להחליף אותה

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

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

מתי שכתוב מלא הוא באמת הבחירה הנכונה

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

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

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

החלק שאיש לא מזכיר: זה בעיקר על אנשים

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

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

שאלות נפוצות