איך למצוא שגיאה בתוכנית: דיבוג Python עם דוגמה פתורה

הדרך הקצרה: לצפות, להשוות, לצמצם ולבדוק

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

הדוגמה מתאימה למי שכבר פגש משתנים, רשימה, לולאת for ותנאי if. הלולאה עוברת על איברי הרשימה לפי הסדר; התנאי קובע אם לבצע את הפעולה שבתוכו.^[3] אם אלה עדיין חדשים לכם, התחילו בקריאת הדוגמה שורה־שורה או בקשו הסבר נקודתי לפני התיקון.

1. 1. כתבו מה אמור לקרות

   נסחו כלל שאפשר לבדוק, כולל ערך הגבול. למשל: לספור כל מפגש שנמשך לפחות 30 דקות, כולל מפגש של 30 בדיוק.

2. 2. שמרו מה קרה בפועל

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

3. 3. מצאו דוגמה קטנה שמראה את הפער

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

4. 4. שנו דבר אחד ובדקו שוב

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

האם יש הודעת שגיאה, או רק תוצאה לא נכונה?

התיעוד של Python מבחין בין שגיאות תחביר לבין חריגות שמתגלות בזמן ביצוע. בהודעת חריגה, השורה האחרונה מציינת את סוג החריגה ואת הפרטים שלה; החלק שלפניה מציג את ההקשר שבו התרחשה.^[1] זו נקודת פתיחה לקריאה, לא הוראה לתקן תמיד את השורה האחרונה בקובץ.

גם הסימון בהודעת SyntaxError מצביע על המקום שבו הבעיה התגלתה, ולא בהכרח על המקום שבו צריך לתקן אותה.^[1] למשל, כדאי לבדוק גם את השורה הקודמת ואת הסוגריים והמירכאות שסביבה, ולא למחוק מיד את הקטע שסומן.

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

התרגיל: סופרים מפגשים של לפחות 30 דקות

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

לפני ההרצה, בדקו ביד את הרשימה: 20 לא נספר, 30 נספר ו־45 נספר. לכן הפלט הצפוי הוא 2. בקוד הבא השארנו טעות מכוונת. אם Python 3 כבר מותקן, שמרו אותו בקובץ session_count.py והריצו בסביבת העבודה שלכם. הקוד מקומי: אין בו רשת, קבצים חיצוניים או פרטים אישיים.

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

minutes = [20, 30, 45]
threshold = 30
count = 0

for duration in minutes:
    if duration > threshold:
        count = count + 1

print(count)

מצמצמים את הבעיה למפגש אחד של 30 דקות

שנו רק את שורת הרשימה ל־minutes = [ 30 ], והשאירו את שאר הקוד כפי שהוא. התחזית לפי הדרישה היא 1, אבל הגרסה עם הטעות מדפיסה 0. כעת אין צורך לעקוב אחרי כמה מפגשים: נתון יחיד כבר מראה את הבעיה.

ההשערה שנבדוק היא שהתנאי אינו כולל שוויון. ב־Python הסימן > משווה ׳גדול מ־׳ ואילו >= משווה ׳גדול או שווה ל־׳.^[2] לכן עבור 30 מול סף 30, התנאי בגרסה עם הטעות אינו מתקיים. זו התאמה בין הסבר לבין מקרה נכשל, ולא רק ניחוש של תו אחר.

כדי לעקוב ידנית, שאלו בכל מעבר: מהו duration, האם התנאי מתקיים ומהו count לאחריו? על הרשימה המקורית, המונה בגרסה עם הטעות נשאר 0 אחרי 20, נשאר 0 אחרי 30 ועולה ל־1 אחרי 45. המקום הראשון שבו ההתנהגות סוטה מהדרישה הוא המפגש של 30 דקות.

מתקנים תנאי אחד, בלי להחליף את התוכנית

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

הפלט כעת הוא 2. ההסבר: 20 אינו מגיע לסף, 30 שווה לסף ו־45 גבוה ממנו. שני המפגשים האחרונים נספרים. בדיקה אחת שמתאימה לציפייה היא התחלה טובה, אבל עדיין נבדוק שהשינוי לא פגע במקרים אחרים.

minutes = [20, 30, 45]
threshold = 30
count = 0

for duration in minutes:
    if duration >= threshold:
        count = count + 1

print(count)

בודקים מקרה רגיל, שוויון ורשימה ריקה

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

למה לבחור דווקא את המקרים האלה? [ 30 ] בודק את הטעות המקורית; [ 29 ] ו־[ 31 ] בודקים את שני צדי הגבול; רשימה ריקה בודקת שאין מפגש שייספר; ושתי הופעות של 30 בודקות שסופרים כל מפגש, גם אם משכו זהה לאחר. בדיקות אלה אינן הוכחה לכל תוכנית אפשרית, אלא בדיקה ממוקדת של הדרישה שהגדרנו.

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

דף תיעוד קצר: מה נכשל, מה שיניתי ואיך בדקתי

העתיקו למחברת חמש שורות: הדרישה; הקלט שמראה את הבעיה; צפוי מול בפועל; ההשערה והשינוי; בדיקות לאחר התיקון. בדוגמה שלנו: ׳לספור לפחות 30; הרשימה [ 30 ]; צפוי 1 ובפועל 0; התנאי לא כולל שוויון ולכן החלפתי > ב־>=; בדקתי גם [ 29 ], [ 31 ] ורשימה ריקה׳.

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

אפשר לבקש עזרה ממורה, חבר או כלי AI, אבל בקשו תחילה רמז: ׳עבור הרשימה [ 30 ] ציפיתי ל־1 וקיבלתי 0. איזה חלק בדרישה כדאי להשוות לתנאי? אל תכתוב לי עדיין פתרון מלא׳. השתמשו רק בקוד שאתם מורשים לשתף, בלי סיסמאות, מידע אישי או שאלות חסויות. גם הצעת תיקון שקיבלתם צריכה לעבור את הבדיקות שלכם.

התרגול הבא: משנים את הדרישה, לא מנחשים פתרון

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

כעת שאלו שאלה אחרת: מה היה צריך להשתנות אילו הדרישה הייתה ׳יותר מ־30 דקות׳ ולא ׳לפחות 30 דקות׳? במקרה הזה דווקא התנאי המקורי היה מתאים, והציפייה לרשימה המקורית הייתה 1. תו בקוד אינו נכון או לא נכון לבדו; בודקים אותו מול דרישה מסוימת.

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

שאלות נפוצות