חוב טכני (Tech Debt) , קוד מורשת (Legacy code) ומה שביניהם - איך להישאר מובילי שוק לאורך שנים?
חוב טכני (Tech Debt) , קוד מורשת (Legacy code) ומה שביניהם - איך להישאר מובילי שוק לאורך שנים?
יש הסבורים כי אנו מצויים כיום בליבה של המהפכה הטכנולוגית הרביעית, מהפכה שמביאה איתה כמויות מידע עצומות שעוברות ברשת ונשמרות במאגרי מידע שונים. מהפכה זו מביאה עימה טכנולוגיות חדשות בקצב מהיר מאי פעם ומעלה את הצורך באמצעי ניתוח והגנה מתקדמים. הדרישה לעובדים גדלה גם היא והמהנדסים זזים בקצב מהיר ממקום למקום.
אחת מהשלכות המהפכה הטכנולוגית הנוכחית היא הגידול המואץ בקצב צבירת החוב הטכנולוגי וקוד המורשת. אלו מהווים תוצר לוואי בלתי נמנע לכל מוצר מצליח ששורד לאורך שנים. מחקרים אף מראים שכמעט לכל חברה הפועלת בשוק לפחות 4-5 שנים, ישנה מערכת מפתח המבוססת על טכנולוגיות מדור קודם.
נוכח התפתחות דינמית זו עולה השאלה מדוע אנו כמהנדסים רואים בקוד מורשת ובחוב טכני מילות גנאי? שאלה משנית שעולה היא כיצד ניתן לנהל את תוצר הלוואי הבלתי נמנע הזה כך שמוצר יוכל להצליח ולהוביל לאורך שנים? התשובות לשאלות הללו דורשת את ההקדמה החיונית לפיה אף על פי שחוב טכנולוגי וקוד מורשת מגיעים לרוב יחד, מדובר בשתי תופעות שונות ועל כן הן צריכות להיות מנוהלות בצורה קצת שונה.
קוד מורשת, כשמו כן הוא, קוד שהתקבל בירושה. עבור מהנדס חדש בארגון, קוד שנכתב ע״י מישהו אחר ועכשיו באחריותו, הינו קוד מורשת - גם אם מדובר במוצר חדש וצעיר. קוד מורשת מהווה אתגר לארגון שכן רוב המהנדסים לא אוהבים לטפל בקוד שמישהו אחר כתב, מתקשים להיכנס לקוד ולדרך חשיבה של מהנדס אחר ומעדיפים לכתוב קוד חדש ונוצץ.
התמודדות עם הקשיים בקוד מורשת מצריכה עבודה של חינוך והדרכה:
• כללי כתיבת קוד נקי וקריא
• מחיקת קוד שאינו בשימוש - הקוד לא נועד לשמור היסטוריה, לשם כך קיימים כלי source control
• תיעוד קצר, ענייני ונגיש - התמקדות ב״למה״ ולא ב״מה״
חוב טכני לעומת זאת הינו העלות המשוערת של פיתוח עתידי שנועד לשמר את המוצר ברמה אופטימלית לתחזוקה ופיתוח שותף. חוב זה כולל בתוכו קוד, ארכיטקטורה, ספריות חיצוניות ואת המערכות שתומכות במוצר ובבדיקות שלו. מטבע הדברים, החוב גדל כל הזמן אלא אם עובדים אקטיבית לצמצם אותו.
ישנן שלוש אפשרויות עיקריות להתמודדות עם חוב טכני, לכל שיטה יתרונות וחסרונות וכל ארגון יבחר את הדרך בהתאם לסיטואציה הספציפית שלו:
• שכתוב (refactoring)
שינוי ממוקד של קטעי קוד מיושנים שזקוקים לשיפור מבלי לייצר שינויים חיצוניים משמעותיים. שכתוב קטעים בקוד מטפל לרוב בבעיות כמו ניקוי קוד, קריאות והתאמה טובה יותר לדרישות שמשתנות עם הזמן ופחות נוגע בשינויי ארכיטקטורה כלליים. שכתובים שיטתיים ותכופים יכולים להיעשות ללא עצירה מוחלטת של הפיתוח ולאפשר שליטה ובדיקה. שימוש בשכתוב כאסטרטגיה בעבודה השותפת ולא כפעולה חד פעמית יכול להאריך את חיי המוצר ולאפשר התקדמות מתמדת.
• כתיבה מחדש
שיכתוב מודולים לוגיים שלמים, כולל הוצאת חלקים לשירותים נפרדים, ללא התבססות על קוד או טכנולוגיית המקור, אך תוך כדי שימור של הפונקציונליות המקורית. בשיטה זו ניתן להגיע בצורה הדרגתית לשכתוב כולל של המערכת והתאמתה לטכנולוגיות חדשות וארכיטקטורה מתקדמת.
• בניית מוצר חדש
כתיבה של כל המערכת מחדש. שיטה זו יקרה לארגון וצופנת בחובה לא מעט סיכונים אך גם לא מעט יתרונות. לרוב נפנה לדרך זו כשאין דברים משמעותיים אותם רוצים לשמר מהמערכת הישנה וכאשר קיים קושי אמיתי בשימור לקוחות והכנסות בגלל החוב הטכנולוגי. שמירה על לקוחות והכנסות תיעשה במצב זה ע״י הבטחה לשמירה על הפונקציונאלית העיקרית שחשובה ללקוחות, שמירה על סטנדרט איכות גבוה ומסלול מעבר נוח מהמערכת הישנה למערכת החדשה. היתרון הברור הוא קבלת מערכת חדשה, נקייה מחובות ומתאימה לדרישות העכשוויות.
למעשה ניתן לדמות את הטיפול הנכון בקוד מורשת וחוב טכני כמשחק מתמיד של איזון בין תכנון לטווח קצר ולטווח ארוך. הכוח המוביל שדוחף לצמצום החוב הטכני צריך להיות צורך עסקי שנפגע בגלל החוב הקיים דוגמת קושי באספקת תכונות חדשות, קשיים בעמידה בלוחות זמנים, בעיות איכות ומוצר שביר - אך לא הטכנולוגיה עצמה. יחד עם זאת, תשלום חוב מוקדם הוא תמיד זול יותר וכך גם לגבי חוב טכני. צבירת חוב טכני היא דבר בלתי נמנע, המודעות לחוב שנצבר ותכנון נכון של ההחזר הם קריטיים ליכולת של מוצר לשרוד לאורך זמן.
קוד פשוט ונקי תמיד יהיה קל יותר לתמיכה שכן עם הזמן וכמות הלקוחות, מתווספות למוצר המצליח תכונות חדשות. נתונים סטטיסטיים מראים שרק כ-20% מתכונות מוצר נמצאות בשימוש לעתים קרובות בעוד שכ-45% מהתכונות אינן בשימוש כלל. לכן חלק חשוב בניהול מוצר אחראי הוא זיהוי התכונות שאינן בשימוש וביטולן.
אם כן מדוע ארגונים מזניחים לעיתים קרובות את הטיפול בחובות טכניים למרות השלכותיהם המשמעותיות? באופן טבעי, הלחצים של הטווח הקצר חזקים יותר מהמחשבה לטווח ארוך. מבחינת המהנדס הבודד, בטח בשוק בו המהנדסים זזים לעיתים קרובות מחברה אחת לשנייה – תיעוד, קריאות וניקיון הן בעיות של זה שיגיע אחריי. גם מבחינת הארגון קשה מאוד לכמת את מחיר החוב הטכני. מה המחיר האמיתי של פיתוח איטי? מה מחירם של באגים ומוצר שביר? לעומת זאת, את הרווח של העסקה הבאה, שלא ניתן לסגור מבלי להוסיף בצורה מהירה תכונה חסרה, מאד קל להנהלת החברה למדוד.
לסיכום, ניהול קוד מורשת וחוב טכני מהווים חלק בלתי נפרד מה- engineering excellence. ניהול פיתוח מוצלח מאפשר לכמת את התועלת ולהראות כיצד היגיינת תוכנה הינה קריטית ליעילות ואפקטיביות במתן ערך עסקי, סיפוק צרכי הלקוח ושימור תרבות של חדשנות טכנולוגית. לא פחות חשוב מכך הם מהווים כלי משמעותי בסיפוק הצורך של המהנדסים להיות חלק ממוצר איכותי, מודרני ומצליח.
מאת דפנה ליטוין, Sr engineering director, Imperva
d&b – לדעת להחליט
