דיבאגינג בלי פאניקה: איך מוצאים באגים עם נקודות עצירה, הדפסות ובידוד הבעיה

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

במאמר הזה נבנה שיטת עבודה מעשית לדיבאגינג בקוד: פייתון, JavaScript, SQL, לינוקס, שורת הפקודה, קצת Git, וגם שימוש זהיר ב־regex כשצריך למצוא תבניות בלוגים. אם אתם בתחילת הדרך, כדאי לשמור לידכם גם את מדריך צעדים ראשונים, ובמיוחד אם אתם עובדים עם Python — את מדריך פייתון.

לפני שנוגעים בקוד: מה מכינים מראש

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

• פקודת הרצה אחת ברורה: למשל python app.py, npm test או sqlite3 app.db. אם לא ברור איך משחזרים את הבעיה, קשה לדעת אם תיקנתם אותה.
• קלט קטן: קובץ קטן, רשימה קצרה, טבלה עם שלוש שורות. באג שקל לשחזר על מעט נתונים הוא באג שקל להבין.
• מצב Git נקי: הריצו git status. אם יש שינויים לא קשורים, שמרו אותם עם git stash או בצעו קומיט זמני בענף נפרד.
• דרך לחזור אחורה: אל תערבבו עשרה ניסיונות תיקון. שינוי קטן, הרצה, בדיקה. אם צריך, חזרו עם git checkout -- file.py או בדקו הבדלים עם git diff.
• העתקה של הודעת השגיאה המלאה: לא “זה נפל”, אלא כל ה־traceback או ה־stack trace. השורה הראשונה והשורה האחרונה בדרך כלל חשובות במיוחד.

שיטת חמשת השלבים לדיבאגינג רגוע

1. משחזרים את הבעיה בלי לנחש

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

כאשר אני מריץ X עם קלט Y, אני מקבל Z במקום התוצאה הצפויה W.

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

2. מצמצמים את האזור החשוד

שאלו: האם הבעיה בקלט, בעיבוד, בפלט, במסד הנתונים, או בתצוגה? למשל, אם דף מציג סכום שגוי, אל תקפצו מיד ל־CSS או ל־JavaScript. בדקו קודם מה חוזר מה־API, מה מחושב בשרת, ומה נשמר בטבלה.

3. מוסיפים הדפסות זמניות

הדפסות הן כלי דיבאגינג לגיטימי, כל עוד משתמשים בהן בכוונה. הדפיסו ערכים בצמתים חשובים, לא בכל שורה. כתבו הודעה עם שם המשתנה והשלב בתהליך, למשל print("after parsing:", data).

4. משתמשים בנקודות עצירה

נקודת עצירה מאפשרת לעצור את התוכנית בזמן ריצה ולבדוק משתנים, תנאים וקריאות לפונקציות. בפייתון יש breakpoint(). בדפדפן יש נקודות עצירה בכלי הפיתוח. ב־Node.js אפשר לעבוד עם דיבאגר. היתרון: לא צריך לנחש מה הערך; רואים אותו.

5. מבודדים את הבאג לדוגמה מינימלית

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

דוגמה 1: דיבאגינג בפייתון עם הדפסות ונקודת עצירה

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

from decimal import Decimal
import os


def total_price(items, tax_rate):
    subtotal = sum(
        Decimal(str(item["price"])) * item["qty"]
        for item in items
    )

    if os.environ.get("DEBUG_BREAK") == "1":
        breakpoint()

    total = subtotal * (Decimal("1") + Decimal(str(tax_rate)))
    return total.quantize(Decimal("0.01"))


def main():
    cart = [
        {"name": "notebook", "price": 12.5, "qty": 2},
        {"name": "pencil", "price": 4, "qty": 3},
    ]

    print(total_price(cart, 0.17))


if __name__ == "__main__":
    main()

הרצה רגילה עם python debug_price.py תדפיס:

43.29

אם רוצים לעצור בתוך הפונקציה, מריצים בלינוקס או macOS כך: DEBUG_BREAK=1 python debug_price.py. ב־Windows PowerShell משתמשים ב־$env:DEBUG_BREAK="1"; python debug_price.py. בנקודת העצירה אפשר לבדוק את subtotal, את items, ואת tax_rate. אם הסכום שגוי, עכשיו ברור באיזה שלב הוא השתבש.

מה נפוץ להיתקע בו בפייתון

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

דוגמה 2: JavaScript — הדפסות ממוקדות במקום רעש

ב־JavaScript קל להציף את הקונסול. דיבאגינג טוב משתמש בהדפסות מעטות וברורות. הדוגמה הבאה מסננת משתמשים פעילים לפי שם. היא מתאימה להרצה עם Node.js.

const users = [
  { id: 1, name: "Dana", active: true },
  { id: 2, name: "Noam", active: false },
  { id: 3, name: "dana", active: true }
];

function findActiveByName(name) {
  const normalizedName = name.toLowerCase();

  return users.filter((user) => {
    const matchesName = user.name.toLowerCase() === normalizedName;
    return user.active && matchesName;
  });
}

const result = findActiveByName("dana");
console.log(JSON.stringify(result, null, 2));

הרצה עם node debug_users.js תדפיס:

[
  {
    "id": 1,
    "name": "Dana",
    "active": true
  },
  {
    "id": 3,
    "name": "dana",
    "active": true
  }
]

אם התוצאה ריקה, המקומות הנכונים לבדיקה הם normalizedName, הערך של user.name, והאם active באמת בוליאני ולא מחרוזת כמו "true". אותו עיקרון תקף גם בדיון של JavaScript vs TypeScript: TypeScript יכול לתפוס חלק מהבעיות לפני הרצה, אבל עדיין צריך לדעת לבודד התנהגות בזמן אמת.

דוגמה 3: SQL, ערכי NULL ו־COALESCE

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

הדוגמה הבאה משתמשת ב־SQLite דרך Python, ולכן אפשר להריץ אותה בלי להתקין שרת מסד נתונים.

import sqlite3


def main():
    connection = sqlite3.connect(":memory:")
    cursor = connection.cursor()

    cursor.execute("""
        CREATE TABLE invoices (
            customer TEXT NOT NULL,
            amount INTEGER NOT NULL,
            paid INTEGER
        )
    """)

    cursor.executemany(
        "INSERT INTO invoices (customer, amount, paid) VALUES (?, ?, ?)",
        [
            ("Dana", 100, 40),
            ("Noam", 80, None),
            ("Roni", 50, 50),
        ],
    )

    cursor.execute("""
        SELECT
            customer,
            amount,
            COALESCE(paid, 0) AS paid,
            amount - COALESCE(paid, 0) AS balance
        FROM invoices
        ORDER BY customer
    """)

    for row in cursor.fetchall():
        print(row)

    connection.close()


if __name__ == "__main__":
    main()

פלט צפוי:

('Dana', 100, 40, 60)
('Noam', 80, 0, 80)
('Roni', 50, 50, 0)

בלי COALESCE, החישוב עבור Noam היה עלול להחזיר NULL. כשמחפשים coalesce sql, זה בדיוק השימוש הנפוץ: לתת ברירת מחדל לערכים חסרים. שימו לב גם לשימוש ב־? בשאילתה. זו צורה בטוחה של פרמטרים, ולא חיבור מחרוזות ידני.

דוגמה 4: לינוקס ושורת הפקודה — למצוא רמזים בלוגים

בלינוקס וב־macOS, שורת הפקודה עוזרת לבודד תקלות מהר. הדוגמה הבאה יוצרת קובץ לוג זמני, מחפשת שורות שגיאה, ומנקה אחריה. היא מיועדת ל־bash.

#!/usr/bin/env bash
set -euo pipefail

tmp_dir="$(mktemp -d)"
trap 'rm -rf "$tmp_dir"' EXIT

cat > "$tmp_dir/app.log" <<'LOG'
INFO app started
INFO loading config
ERROR failed to read users.csv
INFO app stopped
LOG

grep -n "ERROR" "$tmp_dir/app.log" || true

פלט צפוי:

3:ERROR failed to read users.csv

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

נקודות עצירה מול הדפסות: מתי להשתמש במה

Git בזמן דיבאגינג: לא להסתבך עם עצמכם

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

• לפני התחלה: git status.
• אם יש עבודה לא קשורה: git stash.
• אם מצאתם תיקון קטן: עשו קומיט ברור.
• אם אתם מסדרים היסטוריה בענף מקומי בלבד, אפשר להשתמש ב־git rebase, אבל לא לעשות rebase לענף שמשותף לאחרים בלי תיאום.
• לפני מחיקת הדפסות: git diff כדי לראות מה באמת השתנה.

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

טעויות נפוצות והודעות שגיאה אמיתיות

NameError: name 'total' is not defined

בפייתון, ההודעה אומרת שהשם total לא קיים בנקודה שבה השתמשתם בו. בדקו שכתבתם את אותו שם משתנה, שהוא מוגדר לפני השימוש, ושאין הבדל בין total ל־totals. אם המשתנה מוגדר בתוך if, ייתכן שהענף הזה לא רץ.

TypeError: unsupported operand type(s) for +: 'int' and 'str'

זו הודעה נפוצה כשמערבבים מספר ומחרוזת. למשל קלט מקובץ או מטופס מגיע כטקסט. הדפיסו את type(value), ולא רק את הערך. הפתרון הוא המרה מפורשת עם int() או Decimal(), בהתאם לצורך.

TypeError: Cannot read properties of undefined (reading 'name')

ב־JavaScript, ניסיתם לקרוא מאפיין מתוך ערך שהוא undefined. בדקו האם המערך ריק, האם find() לא מצא כלום, או האם שם השדה שונה. תיקון טוב אינו רק ?.; צריך להבין למה הערך חסר.

sqlite3.OperationalError: no such column: paid_amount

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

error: Your local changes to the following files would be overwritten by checkout

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

איך יודעים שהבאג באמת תוקן

תיקון בלי בדיקה הוא ניחוש מנומס. אחרי שמצאתם את הסיבה, חזרו למשפט המקורי: “כאשר אני מריץ X עם קלט Y…”. הריצו שוב את אותו תרחיש. אחר כך הריצו תרחיש דומה, ותרחיש קצה: רשימה ריקה, ערך NULL, שם באותיות גדולות, קובץ חסר, או מספר אפס.

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

צ'ק־ליסט קצר לדיבאגינג בלי פאניקה

1. לשחזר את הבעיה עם פקודה אחת וקלט קטן.
2. לקרוא את הודעת השגיאה המלאה, לא רק את השורה האחרונה.
3. לצמצם: קלט, עיבוד, מסד נתונים, פלט או תצוגה.
4. להוסיף הדפסות מעטות עם שמות ברורים.
5. להשתמש בנקודת עצירה כשצריך לראות מצב פנימי.
6. לבודד לקובץ קטן או שאילתה קטנה.
7. לשמור על Git נקי, ולהפריד בין ניסוי לתיקון.
8. להוסיף בדיקה שמונעת מהבאג לחזור.

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