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

אחת הבעיות עם תכנות מונחה דיבאגר היא שזו שיטת עבודה שמשמידה את עצמה.

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

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

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