אף אחד לא אוהב חוב טכני. כמו שאף אחד לא אוהב חובות פיננסים. ובשני המקרים באמת התנהלות נכונה ומחושבת יכולה להוריד את שניהם באופן דרמטי. אבל בניגוד לחובות פיננסיים שהמטרה היא לסיים אותם בכל מחיר, אז בחוב טכני זה לא בהכרח כך. מה??? למה?? אבל אותנו חינכו שחובות צריך לחסל ושקוד צריך להיות תמיד יפה!
אז יש חובות שכדאי מאוד לפתור ויש חובות בעיני שלא. וגם החובות שכדאי לפתור – לא נולדו כולם שווים.
חובות שכדאי לפתור:
אחרי שהתרכזנו בחובות הטכניים החשובים, אחלק את החובות הטכניים פה ל-3 קטגוריות מרכזיות:
סוג 1: חוב טכני מכוון
כשמפתחים כותבים קוד, הם יודעים הרבה פעמים שיש את הדרך הנכונה והיפה ויש את הדרך המהירה. לפעמים הדרך המהירה היא גם הדרך הנכונה או נכונה מספיק כי היא פשוטה יותר, לא עושה OVER-Engineering. לפעמים הדרך המהירה היא ממש הדרך הלא נכונה, זו שמתעלמת ממקרי קיצון אפשריים, זו שמניחה הנחות יסוד שלא תמיד מתקיימות וכו’. וחובות כאלה צריך לקחת ישר חזרה לרשימת הרכיבים שיש לפתח לפני שהזמן לטיפול בתקלות יעלה על הזמן של לתקן את הקוד 🙂
סוג 2: חוב טכני בטעות/ עובד כמתוכנן אבל שונה מהמצופה
לפעמים נקרא חוב טכני נאיבי כי מגיע מתכנון שלא לוקח בחשבון אפשרויות מסוימות או תכנון שמגיע מכך שהמשתמשים ציפו להתנהגות מסוימת ששונה ממה שחשבו אנשי המוצר או כאשר המערכת פועלת לפי מה שהתכוונו כאשר תכננו אותה אבל כיום אנחנו מצפים מהמערכת לפעול אחרת מכל מיני סיבות. לדוגמא – ברכיב שעושה קיבוץ לכרטיסיות (tickets), אפשר לטעון שיש tickets שלא מתקבצים והתשובה תהיה של-tickets האלה אין קיבוץ לפי תכנון הפיצ’ר כיום.
סוג 3: חוב טכני שנובע משינויים מתמידים המבוצעים בצורה לא טובה מספיק
אפשר לזהות אותו על ידי רכיב טכני שלאורך הזמן הולך ומואט, הסיבוכיות שלו עולה ועולה בלי סיבה נראית לעין וכו’.. זה קורה בעיקר במקרים שבהם יש יותר מדי ידיים עובדות ופחות מדי ידע על הרכיב. עדיף מלכתחילה לא להגיע למצב הזה על ידי יצירת סטנדרט עבודה והדרכות מספקות ובעיקר על ידי תיקונים מידיים שוטפים כאשר רואים שינויי קוד לא טובים שיביאו בסוף לתפקוד לא טוב של הרכיב. אני יודעת שלפעמים זה קל לומר לעשות ושזה פותח פתח להגדרות סובייקטיביות של מהו “שינוי קוד טוב”.
והנה החובות שלא חייבים לפתור:
אני ראשית כל רוצה לשים בצד ולא להתחייב על לפתור חובות טכניים שהם יושבים במקומות אשר:
- חובות שלא משפיעים על הלקוח מבחינת פונקציונליות במערכת – יש מקומות שלא משפיעים בכלל על הלקוחות או משפיעים רק במקרים מאוד נדירים.
- חובות טכניים שנמצאים באזורי קוד יציבים שאין בהם נגיעה שוטפת – יש מקומות בקוד שלא נראים יפה. אבל אם הם יציבים לאורך זמן ולא עושים בהם שינויים או נוגעים בהם באופן שוטף, אז אפשר פשוט להשאיר כך.
אבל עכשיו, מה עושים עם חוב הטכני? איך מתעדפים אותו מול רכיבים אחרים? איך מתמחרים אותו? אז הדרכים “הנכונות” לפתור חוב טכני משתנות מחברה לחברה, ממוצר למוצר ובשלבי חיים שונים שלהן. אבל יש כמה מתודולוגיות מרכזיות שכדאי להכיר ושעליהם אפרט בפוסט הקרוב הבא.
האם גם אתם אנשי אופרציה העוסקים בתהליכי עבודה, מתודולוגיות וכלים בעולמות הפיתוח? אם כן, נשמח שתצטרפו לקבוצת Engineering Operations בוואטסאפ ותעקבו אחרינו בעמוד ה- Linked In שלנו.
מסכים עם כל הכתוב. אחלה פוסט!