אני מניח שכולכם מכירים את המונח "חוב טכני" (Technical Debt), מונח שקבע Ward Cunningham בכדי לעזור ולחשוב על פשרות טכניות במערכת - שיש להן השפעות ארוכות טווח
משמעות "חוב טכני" היא שפיתחנו פיצ'ר מסוים, וידענו שהפתרון הנכון ארכיטקטונית הוא פתרון X.
משיקולי זמנים (time-to-market, בעיקר), בחרנו ליישם פתרון נחות-ארכיטקטונית שנקרא לו x`.
את הפער בין הפתרון הרצוי ארכיטקטונית X לפתרון המצוי x`, מתארים כחוב שיש להחזיר "למערכת". כמו חוב לבנק - הוא צובר "ריבית" בדמות פיתוח יקר יותר של הפיצ'רים הבאים, שייקח יותר זמן לפתח - בגלל קיצור הדרך שלקחנו.
למשל: בפיצ'ר מסוים, במקום ליצור טבלה חדשה בבסיס הנתונים המתארת בצורה מדויקת את אופי האובייקט o, החלטנו "להלביש" את קיום האובייקט o על טבלה קיימת. שחררו את הפיצ'ר מהר יותר - אבל יצרנו עיוות שעכשיו בפיצ'רים חדשים נצטרך לעשות עבודה נוספת / לפתור חוסרי-התאמה חדשים בתוך המערכת, כי לא עשינו את ה"פתרון הנכון".
למטאפורה של "חוב טכני" יש כמה צדדים מדויקים יותר, ומדויקים פחות:
מתאר יפה את המצב
• לחוב טכני יש "עלות" או "ריבית" שתכביד עלינו ונשלם עליה - עד אשר החוב יוחזר.
• בחוב טכני יש משהו גם חיובי: פעמים רבות נכון לביזנס לעשות פשרה מידית בכדי להשיג תוצאה מידית. הדבר טבעי במיוחד לשוק האמריקאי שם צמיחה של חברות היא מבוססת חובות - וזה מודל שמצליח.
לא מתאר בצורה טובה
• חוב כספי הוא מספרי וקל לחשב אותו: בדולרים. חוב טכני הוא לא מדויק, לא ניתן ממש להעריך את העלות "להחזיר אותו" וגם לא ניתן למדוד במדויק את הנזק שהוא גורם לאורך זמן.
• פריון מפתחים - הוא נושא לא-מדויק מטבעו.
• חוב כספי, גדול ככל שיהיה אפשר להחזיר ברגע אחד. חוב טכני משמעותי יוחזר על ידי עבודה ארוכה, של המשאבים הקיימים.
• יש כלים (למשל: SonarQube) שמנסים לתת מספר (זמן / דולרים) שיתאר את החוב הטכני של המערכת. קצרה היריעה מלפרט עד כמה ההערכות הללו הן סתמיות.
אין לי מטאפורה טובה יותר בכל ממד, אבל אולי מטאפורה של סמי-מרץ - היא מטאפורה משלימה למטאפורה של "חוב טכני".
• אם אנחנו ספורטאים, ואנחנו בתחרות - נסכים לעשות הרבה בכדי לעמוד יפה בתחרות.
• רופאים אומרים שהרבה קפה הוא דבר מזיק - אבל אני בטוח שיש כמה ספורטאים שהוא עוזר להם. אי אפשר לנבא ולמדוד את התוצאות השליליות - זה נושא מורכב ולא מדויק. הרבה ספורטאים הצליחו עם כמה התנהגויות שנחשבות לא בריאות (ספורט תחרותי, בכלל - הוא דבר לא בריא לגוף), וחיו לאורך שנים.
• יש גם סמים קשים יותר, עם תמורה קצרת טווח חזקה יותר - אבל גם סיכון לנזקים חמורים בהרבה.
• במידה והחלטנו להפסיק להשתמש בסמי-מרץ קשים, תהליך השיקום עומד להיות ארוך וכואב - בדומה מאוד לחוב טכני עמוק ומשמעותי. זה לא נגמר ביום, אלא זה מסע מפרך וכואב שאי אפשר לדעת מתי יגמר.
קצת מעבר להגדרה היבשה
בואו ננסה לדייק כמה נקודות, מעבר להגדרה הפשוטה של חוב טכני:
לא תמיד אנחנו צודקים בהערכה שארכיטקטורה X עדיפה על ארכיטקטורה x`.
• לעתים אנו מבצעים הערכות-יתר לחשיבות של אופן מימוש מסוים.
• לפעמים הנסיבות משתנות באופן בלתי-צפוי: דרישה או צורך באובייקט מרכזי במערכת מתבטל או משתנה, ופתאום x` הופכת לארכיטקטורה עדיפה על X. זה לא קורה כל יום, אבל זה קורה.
גם כאשר ארכיטקטורה X עדיפה - לא תמיד היתרון שלה הוא משמעותי או מוצדק.
• יכול להיות ש"לתקן" את החוב הטכני יעלה יותר מכל מחיר שנשלם אי פעם בחיי המערכת, בשל העיוותים שיצר. דוגמה קלאסית: שמות של עמודת בבסיס הנתונים: השם הלא-נכון מציק, אבל שינוי עשוי להיות יקר מאוד לביצוע.
• הצהרה על חוב טכני הוא לעתים "קלף מיקוח" בניסיון להשפיע על אחרים בכדי להסכים דרך פעולה שאני רוצה לקדם. מתוך רצון להשפיע - אני עלול להגזים (ויותר) בתיאור החוב הטכני.
"חוב טכני" הוא טיעון של אנשי-טכנולוגיה, לא אנשי ביזנס
• אחד מסוגי החובות הטכניים הנפוצים והמזיקים ביותר הוא הנדסת-יתר (over-engineering). הרבה יותר קשה להתקדם ולפתח פיצ'רים עם 6 שכבות הפשטה - אם נדרשות רק 2.
o במקרים של הנדסת-יתר לרוב לא נשמע את הקול שאומר "זהו חוב טכני. אנחנו חייבים להחזיר אותו (להסיר רמות הפשטה) בכדי להתקדם יותר מהר", אבל הרבה פעמים - זה בדיוק המצב.
• וריאציה אחרת היא סיבוך המערכת ויצירת חוב-טכני, דווקא תחת ה-ticket של "החזרת חוב טכני".
• לא תמיד מתן אשראי למי שמוכן "להחזיר חוב טכני" - היא פעולה נכונה. עולם התוכנה הוא אכן מורכב: על מנת לפעול נכון חשוב לצלול ולהבין את הדברים.
למרות ערמת ההסתייגויות למעלה, חוב טכני עמוק הוא דבר הרסני למוצר ולחברה
חובות טכניים עמוקים, בליבת המוצר והמודל שלו - עשויים לעשות את ההבדל בין מוצר מצליח לכושל.
חובות טכניים, הם לא אחידים, ולא כדאי להתייחס אליהם ככאלו. אם ניזכר לרגע בכמה חובות טכניים מפורסמים:
• באג 2000 (Y2K) - אבותינו חסכו בשטח האחסון ולכן מידלו שנה כ-2 ספרות ("95") ולא כ-4 ספרות ("1995"). מה קורה כאשר מגיעה שנת 2000? מיון? בדיקה איזה תאריך קדם לשני? - בלאגן.
החוב הטכני קיבל פרופיל תקשורתי עולמי - והיה סיכון ברור ומידי. למרות נבואות-זעם על עולם לא-מתפקד, הוא תוקן בזמן (ובמחיר עצום), ועברנו לשנות ה-2000 בשלום.
Referrer של HTTP - בתקן ה HTTP הוגדר header חשוב בשם Referrer. בתקן נפלה שגיאת כתיב (נכתב: "Referer"), אך עד שגילו את הטעות כבר היו עשרות מפתחים ואולי מאות מפתחים אשר מימשו את שגיאת הכתיב. מלבד בדיחה על בקשה שהוגשה למילון אוקספורד לתקן את הטעות במילון (שם יותר קל לתקן) - לא נעשה ניסיון אמיתי לתקן את שגיאת הכתיב. זו דוגמה טובה לחוב טכני שהוא טעות - אך לא משתלם לתקן. ככל שהזמן עובר - זה הופך למשתלם אפילו פחות.
דוגמה נוספת למשהו שאולי היה רצוי לתקן, אך בלתי-אפשרי בעליל הוא שיטת המדידה האימפריאלית הנהוגה בארה"ב. מדוע צריך לעבוד עם המרות לא נוחות כמו "מייל הוא 5280 רגל"? האם השיטה המטרית היא לא נוחה יותר? - כנראה שכן, אבל כבר מאוחר מדי.
להתחיל מערכת חדשה ללא בדיקות-יחידה / CI-CD אמיתי / תשתית לוגים סבירה - זוהי דוגמה לחוב טכני הרסני. אלו דברים שאם לא מתחילים איתם, הקושי להוסיף אותם מאוחר יותר הוא חסר תקדים. הייתי שותף להשקעה של שנות-אדם רבות בניסיון להחיל בדיקות יחידה, CI אמיתי, או תשתיות לוגים במספר מערכות שונות ש"גררו כמה שנים בלי". על אף מאמצים הרואיים, מגובי-הנהלה גבוהה - לא זכיתי לחזות במקרה שהייתי מגדיר כמוצלח.
רק להסיר ספק: קיום כל אחד מהשלושה הנ"ל הוא כלי productivity חשוב מאוד לארגון פיתוח / למערכת.
למי שלא חווה - זו עשויה להראות כמו דאגה מופרזת, אך למי שחווה הגעה לאזור האדום או הסגול - זו חוויה מדכאת, שלא תרצו לחזור אליה...
ה"טורנדו" של הסתבכות המערכת
למי שלא חווה - זו עשויה להראות כמו דאגה מופרזת, אך למי שחווה הגעה לאזור האדום או הסגול - זו חוויה מדכאת, שלא תרצו לחזור אליה.
איך (לא) מחזירים חוב טכני?
כפי שראינו, חובות טכניים הם שונים זה מזה - ולא נכון להתייחס אליהם כמקשה אחידה.
אני יכול לעסוק בהגדרות שונות ומשונות לחובות טכניים, וסיווגים שונים כיצד הם נוצרים – אך זה לא מעניין מבחינתי.
בכל מערכת יש סדרה אינסופית (מבחינה מעשית) של חובות טכניים: כמה מהותיים, קצת יותר בינוניים, והמון פצפונים. ככל שנתקדם - ייווצרו עוד.
הניסיון "להחזיר את החוב עד תומו" - הוא נאיבי וחסר-בסיס.
הזדמן לי פעם לעבוד בארגון גדול שבו ניתנה הזדמנות נדירה להשקיע חצי שנה של כל גוף הפיתוח על מנת לנקות "חובות טכניים" ממוצר שלא היה חריג מבחינת החובות הטכניים שבו (אני יודע לומר בדיעבד).
תוך כדי פתרון חובות טכניים מסוימים - נוצרו גם אחרים.
בשום רגע, לא הייתה הסכמה מלאה מהו חוב טכני ומה לא. עשרה יהודים = מאה דעות.
זה היה פשוט תרגיל נפלא ביתירות הנדסית. לאחר חצי-שנה המוצר שוחרר לשוק - שם זכה לכישלון מסחרי נחרץ, והוא נסגר זמן קצר לאחר מכן.
את החובות הטכניים המשמעותיים - לא יגלו לכם כלי בדיקה אוטומטיים (כגון Static Analysis tools): הם יגדלו את הקטנים עד הפצפונים - והמון מהם, אך גם לא את כולם.
החובות הטכניים הגדולים הם דברים ש"עקומים" במערכת, בארכיטקטורה שלה, בתהליכים שלה, ובתיאור המציאות שלה. אנחנו נלמד עליהם ממי שמכיר היטב את המערכת ועובד איתה ביום-יום, אם כי לעתים זקוקים לעתים לנקודת מבט של מישהו שעדיין לא התרגל לרעות החולות - ויכול להצביע עליהן, ועל האפשרות לעשות את הדברים טוב יותר.
בחובות הטכניים הגדולים לא קשה כ"כ לשכנע את ההנהלה - כי אפשר להסביר להם מה עובד לא בסדר, ויש לכך לרוב כמה עדויות.
הרבה פעמים קשה לשכנע בקיום חוב טכני משמעותי לפני שהוא מתחיל לתת את אותותיו, והרבה יותר קל לשכנע אחרי שנזק הולך ונגרם. יש הוכחות.
בתפיסת ה Lean Architecture, חשוב מאוד להבין את הדינמיקה הזו.
כאשר אנו מזהים חוב טכני שהולך להיות מיושם, שווה לעשות מאמץ ולנסות למנוע אותו מבעוד-מועד.
לא תמיד נצליח לשכנע שזה אכן מדובר בחוב טכני משמעותי - לפעמים פשוט לא תהיה הסכמה על קיומו של החוב או משמעותו. בפעמים אחרות, תהיה הסכמה - אך עדיין החלטה לקחת אותו ולהתקדם הלאה.
גם במקרים כאלו, לא כדאי להתייאש או לריב עם כל הארגון, על מה שהארגון כרגע לא מסוגל לראות.
עומדים לרשותנו עדיין שני כלים:
• לנסות להשפיע על סדר הפעולות, כך שחוב הטכני ייחשף ויוכח מוקדם יותר (ובשאיפה לנזק מינימלי).
• להשתיל "מנופים" לתיקון החוב: עדיף לתקן בדיעבד בקלות רבה יותר - מאשר ל"הילחם בטחנות רוח" ללא הצלחה.
להזכיר: גם אנו לעתים לא מבינים נכון את הדברים. ומה אם אנחנו טועים?
לפעמים, ניסיונות חוזרים ונשנים להתמודד עם חוב טכני מהותי - שהארגון מסביב לא מסכים להכיר בו הוא סימן שכדאי להחליף ארגון. זה עשוי להיות טוב לשני הצדדים - ובלי לקבוע מי באמת צודק. בסיבוב הבא (ב-2 הצדדים), כנראה שתהיה הפקת לקחים.
סיווג אחד (מני רבים) של סוגים שונים של חובות טכניים ומקורותיהם (מקור: Martin Fowler).
כדאי מאוד להימנע ככל האפשר מחובות טכניים משמעותיים ומיותרים. סיווג המקור - פחות חשוב.
בחלק הבא נעסוק באיך (כן) מחזירים חוב טכני.
מאת: ליאור בר און, ארכיטקט ראשי בחברת Gett וכותב בבלוג http://www.softwarearchiblog.com
אני מניח שכולכם מכירים את המונח "חוב טכני" (Technical Debt), מונח שקבע Ward Cunningham בכדי לעזור ולחשוב על פשרות טכניות במערכת - שיש להן השפעות ארוכות טווח
משמעות "חוב טכני" היא שפיתחנו פיצ'ר מסוים, וידענו שהפתרון הנכון ארכיטקטונית הוא פתרון X.
משיקולי זמנים (time-to-market, בעיקר), בחרנו ליישם פתרון נחות-ארכיטקטונית שנקרא לו x`.
את הפער בין הפתרון הרצוי ארכיטקטונית X לפתרון המצוי x`, מתארים כחוב שיש להחזיר "למערכת". כמו חוב לבנק - הוא צובר "ריבית" בדמות פיתוח יקר יותר של הפיצ'רים הבאים, שייקח יותר זמן לפתח - בגלל קיצור הדרך שלקחנו.
למשל: בפיצ'ר מסוים, במקום ליצור טבלה חדשה בבסיס הנתונים המתארת בצורה מדויקת את אופי האובייקט o, החלטנו "להלביש" את קיום האובייקט o על טבלה קיימת. שחררו את הפיצ'ר מהר יותר - אבל יצרנו עיוות שעכשיו בפיצ'רים חדשים נצטרך לעשות עבודה נוספת / לפתור חוסרי-התאמה חדשים בתוך המערכת, כי לא עשינו את ה"פתרון הנכון".
למטאפורה של "חוב טכני" יש כמה צדדים מדויקים יותר, ומדויקים פחות:
מתאר יפה את המצב
• לחוב טכני יש "עלות" או "ריבית" שתכביד עלינו ונשלם עליה - עד אשר החוב יוחזר.
• בחוב טכני יש משהו גם חיובי: פעמים רבות נכון לביזנס לעשות פשרה מידית בכדי להשיג תוצאה מידית. הדבר טבעי במיוחד לשוק האמריקאי שם צמיחה של חברות היא מבוססת חובות - וזה מודל שמצליח.
לא מתאר בצורה טובה
• חוב כספי הוא מספרי וקל לחשב אותו: בדולרים. חוב טכני הוא לא מדויק, לא ניתן ממש להעריך את העלות "להחזיר אותו" וגם לא ניתן למדוד במדויק את הנזק שהוא גורם לאורך זמן.
• פריון מפתחים - הוא נושא לא-מדויק מטבעו.
• חוב כספי, גדול ככל שיהיה אפשר להחזיר ברגע אחד. חוב טכני משמעותי יוחזר על ידי עבודה ארוכה, של המשאבים הקיימים.
• יש כלים (למשל: SonarQube) שמנסים לתת מספר (זמן / דולרים) שיתאר את החוב הטכני של המערכת. קצרה היריעה מלפרט עד כמה ההערכות הללו הן סתמיות.
אין לי מטאפורה טובה יותר בכל ממד, אבל אולי מטאפורה של סמי-מרץ - היא מטאפורה משלימה למטאפורה של "חוב טכני".
• אם אנחנו ספורטאים, ואנחנו בתחרות - נסכים לעשות הרבה בכדי לעמוד יפה בתחרות.
• רופאים אומרים שהרבה קפה הוא דבר מזיק - אבל אני בטוח שיש כמה ספורטאים שהוא עוזר להם. אי אפשר לנבא ולמדוד את התוצאות השליליות - זה נושא מורכב ולא מדויק. הרבה ספורטאים הצליחו עם כמה התנהגויות שנחשבות לא בריאות (ספורט תחרותי, בכלל - הוא דבר לא בריא לגוף), וחיו לאורך שנים.
• יש גם סמים קשים יותר, עם תמורה קצרת טווח חזקה יותר - אבל גם סיכון לנזקים חמורים בהרבה.
• במידה והחלטנו להפסיק להשתמש בסמי-מרץ קשים, תהליך השיקום עומד להיות ארוך וכואב - בדומה מאוד לחוב טכני עמוק ומשמעותי. זה לא נגמר ביום, אלא זה מסע מפרך וכואב שאי אפשר לדעת מתי יגמר.
קצת מעבר להגדרה היבשה
בואו ננסה לדייק כמה נקודות, מעבר להגדרה הפשוטה של חוב טכני:
לא תמיד אנחנו צודקים בהערכה שארכיטקטורה X עדיפה על ארכיטקטורה x`.
• לעתים אנו מבצעים הערכות-יתר לחשיבות של אופן מימוש מסוים.
• לפעמים הנסיבות משתנות באופן בלתי-צפוי: דרישה או צורך באובייקט מרכזי במערכת מתבטל או משתנה, ופתאום x` הופכת לארכיטקטורה עדיפה על X. זה לא קורה כל יום, אבל זה קורה.
גם כאשר ארכיטקטורה X עדיפה - לא תמיד היתרון שלה הוא משמעותי או מוצדק.
• יכול להיות ש"לתקן" את החוב הטכני יעלה יותר מכל מחיר שנשלם אי פעם בחיי המערכת, בשל העיוותים שיצר. דוגמה קלאסית: שמות של עמודת בבסיס הנתונים: השם הלא-נכון מציק, אבל שינוי עשוי להיות יקר מאוד לביצוע.
• הצהרה על חוב טכני הוא לעתים "קלף מיקוח" בניסיון להשפיע על אחרים בכדי להסכים דרך פעולה שאני רוצה לקדם. מתוך רצון להשפיע - אני עלול להגזים (ויותר) בתיאור החוב הטכני.
"חוב טכני" הוא טיעון של אנשי-טכנולוגיה, לא אנשי ביזנס
• אחד מסוגי החובות הטכניים הנפוצים והמזיקים ביותר הוא הנדסת-יתר (over-engineering). הרבה יותר קשה להתקדם ולפתח פיצ'רים עם 6 שכבות הפשטה - אם נדרשות רק 2.
o במקרים של הנדסת-יתר לרוב לא נשמע את הקול שאומר "זהו חוב טכני. אנחנו חייבים להחזיר אותו (להסיר רמות הפשטה) בכדי להתקדם יותר מהר", אבל הרבה פעמים - זה בדיוק המצב.
• וריאציה אחרת היא סיבוך המערכת ויצירת חוב-טכני, דווקא תחת ה-ticket של "החזרת חוב טכני".
• לא תמיד מתן אשראי למי שמוכן "להחזיר חוב טכני" - היא פעולה נכונה. עולם התוכנה הוא אכן מורכב: על מנת לפעול נכון חשוב לצלול ולהבין את הדברים.
למרות ערמת ההסתייגויות למעלה, חוב טכני עמוק הוא דבר הרסני למוצר ולחברה
חובות טכניים עמוקים, בליבת המוצר והמודל שלו - עשויים לעשות את ההבדל בין מוצר מצליח לכושל.
חובות טכניים, הם לא אחידים, ולא כדאי להתייחס אליהם ככאלו. אם ניזכר לרגע בכמה חובות טכניים מפורסמים:
• באג 2000 (Y2K) - אבותינו חסכו בשטח האחסון ולכן מידלו שנה כ-2 ספרות ("95") ולא כ-4 ספרות ("1995"). מה קורה כאשר מגיעה שנת 2000? מיון? בדיקה איזה תאריך קדם לשני? - בלאגן.
החוב הטכני קיבל פרופיל תקשורתי עולמי - והיה סיכון ברור ומידי. למרות נבואות-זעם על עולם לא-מתפקד, הוא תוקן בזמן (ובמחיר עצום), ועברנו לשנות ה-2000 בשלום.
Referrer של HTTP - בתקן ה HTTP הוגדר header חשוב בשם Referrer. בתקן נפלה שגיאת כתיב (נכתב: "Referer"), אך עד שגילו את הטעות כבר היו עשרות מפתחים ואולי מאות מפתחים אשר מימשו את שגיאת הכתיב. מלבד בדיחה על בקשה שהוגשה למילון אוקספורד לתקן את הטעות במילון (שם יותר קל לתקן) - לא נעשה ניסיון אמיתי לתקן את שגיאת הכתיב. זו דוגמה טובה לחוב טכני שהוא טעות - אך לא משתלם לתקן. ככל שהזמן עובר - זה הופך למשתלם אפילו פחות.
דוגמה נוספת למשהו שאולי היה רצוי לתקן, אך בלתי-אפשרי בעליל הוא שיטת המדידה האימפריאלית הנהוגה בארה"ב. מדוע צריך לעבוד עם המרות לא נוחות כמו "מייל הוא 5280 רגל"? האם השיטה המטרית היא לא נוחה יותר? - כנראה שכן, אבל כבר מאוחר מדי.
להתחיל מערכת חדשה ללא בדיקות-יחידה / CI-CD אמיתי / תשתית לוגים סבירה - זוהי דוגמה לחוב טכני הרסני. אלו דברים שאם לא מתחילים איתם, הקושי להוסיף אותם מאוחר יותר הוא חסר תקדים. הייתי שותף להשקעה של שנות-אדם רבות בניסיון להחיל בדיקות יחידה, CI אמיתי, או תשתיות לוגים במספר מערכות שונות ש"גררו כמה שנים בלי". על אף מאמצים הרואיים, מגובי-הנהלה גבוהה - לא זכיתי לחזות במקרה שהייתי מגדיר כמוצלח.
רק להסיר ספק: קיום כל אחד מהשלושה הנ"ל הוא כלי productivity חשוב מאוד לארגון פיתוח / למערכת.
למי שלא חווה - זו עשויה להראות כמו דאגה מופרזת, אך למי שחווה הגעה לאזור האדום או הסגול - זו חוויה מדכאת, שלא תרצו לחזור אליה...
ה"טורנדו" של הסתבכות המערכת
למי שלא חווה - זו עשויה להראות כמו דאגה מופרזת, אך למי שחווה הגעה לאזור האדום או הסגול - זו חוויה מדכאת, שלא תרצו לחזור אליה.
איך (לא) מחזירים חוב טכני?
כפי שראינו, חובות טכניים הם שונים זה מזה - ולא נכון להתייחס אליהם כמקשה אחידה.
אני יכול לעסוק בהגדרות שונות ומשונות לחובות טכניים, וסיווגים שונים כיצד הם נוצרים – אך זה לא מעניין מבחינתי.
בכל מערכת יש סדרה אינסופית (מבחינה מעשית) של חובות טכניים: כמה מהותיים, קצת יותר בינוניים, והמון פצפונים. ככל שנתקדם - ייווצרו עוד.
הניסיון "להחזיר את החוב עד תומו" - הוא נאיבי וחסר-בסיס.
הזדמן לי פעם לעבוד בארגון גדול שבו ניתנה הזדמנות נדירה להשקיע חצי שנה של כל גוף הפיתוח על מנת לנקות "חובות טכניים" ממוצר שלא היה חריג מבחינת החובות הטכניים שבו (אני יודע לומר בדיעבד).
תוך כדי פתרון חובות טכניים מסוימים - נוצרו גם אחרים.
בשום רגע, לא הייתה הסכמה מלאה מהו חוב טכני ומה לא. עשרה יהודים = מאה דעות.
זה היה פשוט תרגיל נפלא ביתירות הנדסית. לאחר חצי-שנה המוצר שוחרר לשוק - שם זכה לכישלון מסחרי נחרץ, והוא נסגר זמן קצר לאחר מכן.
את החובות הטכניים המשמעותיים - לא יגלו לכם כלי בדיקה אוטומטיים (כגון Static Analysis tools): הם יגדלו את הקטנים עד הפצפונים - והמון מהם, אך גם לא את כולם.
החובות הטכניים הגדולים הם דברים ש"עקומים" במערכת, בארכיטקטורה שלה, בתהליכים שלה, ובתיאור המציאות שלה. אנחנו נלמד עליהם ממי שמכיר היטב את המערכת ועובד איתה ביום-יום, אם כי לעתים זקוקים לעתים לנקודת מבט של מישהו שעדיין לא התרגל לרעות החולות - ויכול להצביע עליהן, ועל האפשרות לעשות את הדברים טוב יותר.
בחובות הטכניים הגדולים לא קשה כ"כ לשכנע את ההנהלה - כי אפשר להסביר להם מה עובד לא בסדר, ויש לכך לרוב כמה עדויות.
הרבה פעמים קשה לשכנע בקיום חוב טכני משמעותי לפני שהוא מתחיל לתת את אותותיו, והרבה יותר קל לשכנע אחרי שנזק הולך ונגרם. יש הוכחות.
בתפיסת ה Lean Architecture, חשוב מאוד להבין את הדינמיקה הזו.
כאשר אנו מזהים חוב טכני שהולך להיות מיושם, שווה לעשות מאמץ ולנסות למנוע אותו מבעוד-מועד.
לא תמיד נצליח לשכנע שזה אכן מדובר בחוב טכני משמעותי - לפעמים פשוט לא תהיה הסכמה על קיומו של החוב או משמעותו. בפעמים אחרות, תהיה הסכמה - אך עדיין החלטה לקחת אותו ולהתקדם הלאה.
גם במקרים כאלו, לא כדאי להתייאש או לריב עם כל הארגון, על מה שהארגון כרגע לא מסוגל לראות.
עומדים לרשותנו עדיין שני כלים:
• לנסות להשפיע על סדר הפעולות, כך שחוב הטכני ייחשף ויוכח מוקדם יותר (ובשאיפה לנזק מינימלי).
• להשתיל "מנופים" לתיקון החוב: עדיף לתקן בדיעבד בקלות רבה יותר - מאשר ל"הילחם בטחנות רוח" ללא הצלחה.
להזכיר: גם אנו לעתים לא מבינים נכון את הדברים. ומה אם אנחנו טועים?
לפעמים, ניסיונות חוזרים ונשנים להתמודד עם חוב טכני מהותי - שהארגון מסביב לא מסכים להכיר בו הוא סימן שכדאי להחליף ארגון. זה עשוי להיות טוב לשני הצדדים - ובלי לקבוע מי באמת צודק. בסיבוב הבא (ב-2 הצדדים), כנראה שתהיה הפקת לקחים.
סיווג אחד (מני רבים) של סוגים שונים של חובות טכניים ומקורותיהם (מקור: Martin Fowler).
כדאי מאוד להימנע ככל האפשר מחובות טכניים משמעותיים ומיותרים. סיווג המקור - פחות חשוב.
בחלק הבא נעסוק באיך (כן) מחזירים חוב טכני.
מאת: ליאור בר און, ארכיטקט ראשי בחברת Gett וכותב בבלוג http://www.softwarearchiblog.com
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר