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

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

מהו חוב טכני?

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

סיבות למראה החיצוני

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

מִיוּן

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

1. חוב טכני מכוון.

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

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

   גישה לפתרון חוב טכני מסוג זה

   המומחה מייעץ לתעד מקרים כאלה בקפידה על מנת לחזור אליהם ולתקן אותם בטרם יאבד חוב טכני זה, ויהפוך לחלק בלתי נפרד ממבנה הפרויקט.

2. חוב טכני שהוא מקרי או נובע מארכיטקטורת פרויקט מיושנת.

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

   גישה לפתרון חוב טכני מסוג זה

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

3. חוב טכני המתעורר עם הזמן.

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

   גישה לפתרון חוב טכני מסוג זה

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

פתרונות ניהול חובות טכניים

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

1. הקצו אחוז קבוע מזמן העבודה שלכם לעבודה על חוב טכני.

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

   זה יכול להיעשות בדרכים שונות.

2. עבודה על חוב טכני יום אחד בשבוע

   Если выделять на работу над устранением ТД всей командой один день в неделю, это How раз будет около 20% от общего рабочего времени. Для некоторых команд такой подход работает просто отлично и, говорят, даже повышает мораль, ведь в этот конкретный день недели вся команда занимается решением проблем, которые достают их все остальное время разработки.

3. Посвящать работе над ТД каждую четвертую задачу

   Такая система подходит тем командам, которые склонны разделять работу над проектом на примерно равномерные по времени и усorям для их выполнения задачи. Если один из каждых четырех тасков посвящать “выплате” ТД, это будет занимать около четверти всего времени разработки. А введение такого подхода в качестве правила позволит убедиться, что codeеры не будут откладывать технический долг “на потом”.

4. Переходящая роль

   Еще одним подходом к проблеме устранения технического долга будет назначать на данную задачу разных членов команды поочередно, чтобы равномерно распределить эту порой далеко не самую приятную работу среди членов коллектива. Количество разработчиков, назначенных заниматься “разгребанием” ТД, может быть разным — для команды из 4-5 человек будет достаточно одного, тогда How коллективы побольше могут назначать двух-трех. Но суть остается прежней — на работу над ТД должно уходить около 20-25% всех ресурсов и человеко-часов.

5. Правило бойскаутов.

   Правило бойскаутов состоит в том, чтобы всегда оставлять туристический лагерь (стоянку для палаток) в лучшем состоянии, чем он был до их прихода, то есть убирать даже тот мусор, который был оставлен не ими. Этот принцип, How выяснor заокеанские codeеры, отлично подходит и для управления техническим долгом. Согласно данному правилу, все члены команды должны заниматься исправлением ТД каждый раз, когда сталкиваются с ним в том or ином виде. Конечно, это правило нужно применять разумно, чтобы время, которое уходит на исправление ТД, не превышало “разумные” 25-30% от общих временных ресурсов.

6. Приоритизация “дорогого” технического долга

   Также эксперты в массе своей рекомендуют не забывать о том, что технический долг может различаться в том числе и по важности. Далеко не каждый тип ТД требует немедленного устранения, поэтому важно работать над классификацией разных видов технического долга и приоритезацией работы с ними соответственно. Проще говоря, прежде всего закрывать надо те долги, которые оказывают прямое влияние на speed разработки продукта, будучи частью его базовой архитектуры. Такие долги являются самыми опасными, потому что ведут к появлению новых долгов, которые могут расти How снежный ком.

Заключение

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