מחזירים חוב טכני בלי לעצור את הפיתוח.

מה זה בעצם חוב טכני

וורד קנינגהם (Ward Cunningham) טבע את מטפורת החוב ב־1992, בדוח ניסיון שהציג בכנס OOPSLA. הטענה שלו הייתה ששחרור של קוד ראשוני דומה ללקיחת הלוואה: מעט חוב עוזר לצוות להתקדם מהר יותר, בתנאי שמחזירים אותו בקרוב. הסכנה היא בחוב שלא מוחזר. כל שינוי שנבנה על קוד שכבר לא מתאים לבעיה עולה יותר ממה שהיה צריך, והתוספת הזאת היא הריבית.

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

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

איך חוב טכני מתבטא בעסק

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

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

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

מודדים לפני שקובעים סדר עדיפויות

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

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

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

מחזירים חוב בשינויים קטנים והפיכים

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

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

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

דואגים שהצוות לא יהפוך לצוואר בקבוק

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

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

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

איך UVISION ניגשת לחוב טכני

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

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

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