חוב טכני

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

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

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

גורמים 
בין הגורמים הנפוצים לחוב טכני נמצא שילוב בין:

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

סוגים 

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

השלכות 

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

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

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

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

בספר Refactoring to Patterns מ-2004, ג'ושוע קרייבסקי הציג טיעון מקביל באשר לעלויות הקשורות להזנחה תכנונית, אותן תיאר כ"חוב דיזיין".

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

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

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

ראו גם 

  (סימפטום לאיכות קוד נמוכה שיכולה לגרום לחוב טכני)
 
 
 
 
 
 
 
 
 קוד ספגטי

קישורים חיצוניים
 Ward Explains Debt Metaphor, סרטון של וורד קאנינגהאם.
 OnTechnicalDebt הקהילה הווירטואלית לדיון בחוב טכני
 ראיונות מומחים בנושא חוב טכני (באנגלית): Ward Cunningham, Philippe KRUCHTEN, Ipek OZKAYA, Jean-Louis LETOUZEY
 Steve McConnell discusses technical debt
 TechnicalDebt from Martin Fowler Bliki
 Averting a "Technical Debt" Crisis by Doug Knesek
 An Andy Lester talk entitled "Get out of Technical Debt Now!"
 חוק להמן (באנגלית)
 Managing Technical Debt Webinar by Steve McConnell
 Boundy, David, Software cancer: the seven early warning signs or here, ACM SIGSOFT Software Engineering Notes, Vol. 18 No. 2 (April 1993), Association for Computing Machinery, New York, New York, US
 Technical debt: investeer en voorkom faillissement מאת קולין ספוול
 Technical debts: Everything you need to know

הערות שוליים

דימויים
ארכיטקטורת תוכנה
תחזוקת תוכנה