עוד שתי סיבות טובות לחוב טכני
המונח "חוב טכני" (Technical Debt) מתאר מצב שבו אנחנו עושים פשרה במערכת כדי להתקדם מהר יותר. הבחירה במונח "חוב" באה להזכיר לנו שלפשרה הזאת יש מחיר, ושעוד מעט נצטרך "להחזיר" את החוב כלומר לארגן מחדש את הקוד בצורה נכונה. למי שצובר הרבה חובות טכניים יהיה קשה להתקדם ובסופו של דבר יצטרך להכריז על "פשיטת רגל", כלומר לזרוק את כל הקוד ולהתחיל מחדש.
הסיבות הקלאסיות לחוב טכני כוללות-
בחירת פריימוורק שייתן פיתרון מהיר למרות שאנחנו יודעים שהוא לא מספיק גמיש או כולל בעיות ביצועים (היוש פונגאפ)
כתיבת קוד ללא בדיקות או ללא תיעוד
כתיבת קוד שלא מטפל במקרי שגיאה נפוצים
אי שידרוג תלויות כשגירסאות חדשות יוצאות
בכל המקרים האלה אנחנו בוחרים "לוותר" על איכות של קוד כדי להגיע מהר יותר ללקוחות עם מוצר שעובד (גם אם לא עובד מושלם), כדי שנוכל לקבל פידבק על המוצר ואחרי זה להמשיך לסבב תיקונים.
חוץ מהסיבות הקלאסיות לחוב טכני יש עוד שני מקרים שמצדיקים חזרה אחורה ותיקון, למרות שהם הרבה פחות מכוונים:
1. כשאין לנו מספיק ידע כדי לפתור בעיה
בפרויקט מסוים הייתי צריך לבנות ללקוח תשתית בדיקות אבל הפרויקט השתמש בכמה ספריות שלא עבדו טוב עם jest. באותו זמן, איך שלא סובבתי את הגדרות הבניה לא הצלחתי לגרום ל jest לבדוק את הפרויקט ובסופו של דבר כתבנו את הבדיקות עם mocha ו sinon.
בפרויקט הזה לא היתה בחירה מודעת להשתמש בפיתרון מסוים שיהיה מהיר יותר מהאלטרנטיבות רק בשביל לפתור את הבעיה, אלא הפיתרון שנבחר היה היחיד שהיה נראה אפשרי באותו זמן.
2. כשאנחנו לא מספיק מכירים את הדריכות
בפרויקט אחר כתבתי ללקוח קומפוננטת ריאקט לטבלה שהיתה מאוד מושקעת מבחינת ביצועים - היא יכלה להכיל מאות אלפי שורות וכל פעם עשתה render רק לשורות שרואים על המסך, כדי שאפשר יהיה להפעיל סינונים ומיונים מהירים.
הקוד עבד מצוין רק אחרי שהם הגיעו לפרודקשן שמתי לב שהם משתמשים בטבלה כדי להציג מספר מאוד קטן של נתונים, בדרך כלל פחות מעשר שורות. כששאלתי על זה הסתבר שבאמת בהתחלה היתה איזו אי הבנה והם רצו משהו בתור הכנה לעתיד אבל בסוף העתיד הזה לעולם לא יגיע.
3. מה עושים
בשתי הדוגמאות יש לנו פיתרון טוב שעובד. מוקה וסינון, למרות שהם ישנים, עדיין מתוחזקים ואין שום בעיה להמשיך להשתמש בהם גם היום וגם בעתיד הנראה לעין. טבלה שיודעת לטפל גם במאות אלפי שורות היא קומפוננטה טובה, גם אם בפועל היא מציגה הרבה הרבה פחות.
ובכל זאת שתי הדוגמאות נכנסות אצלי לקטגוריה של חוב טכני ודורשות Refactoring. אלה פיתרונות יותר מורכבים ממה שהיה צריך וכל הרחבה שלהם תחייב השקעה גדולה יותר. בסופו של דבר אנחנו "משלמים שכירות" על כל שורת קוד במערכת, וגמישות יותר חשובה ממנגנונים מתוחכמים שלא משתמשים בהם.