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

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

1. למה אני משתמש ב Debugger?

בתור מפתח Front End אני משתמש ב Debugger של הדפדפן כדי "להיכנס" לתוך המערכת. נניח שיש לי את הפונקציה הבאה:

function handleClick(ev) {
    const xhr = new XMLHttpRequest();
    xhr.open('POST, '/form.php');
    xhr.addEventListener('load', onLoad);
    xhr.send({name: 'ynon'});
}

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

סיטואציה נוספת בה אני משתמש לעתים קרובות ב Debugger היא במצבים שאני לא יודע מה הוביל לקריאה מסוימת. נניח שיש לי את הפונקציה הזאת ביישום:

function onReady(data) {
    const el = document.querySelector('.info');
    el.querySelector('name').textContent = data.name;
}

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

2. מה הבעיה עם ה Debugger בדוגמה הראשונה?

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

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

3. מה הבעיה עם ה Debugger בדוגמה השניה?

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

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

4. מה אפשר לעשות במקום להיכנס ל Debugger?

קיימים מספר כלים טובים יותר מ Debugger שעוזרים לנו להבין ולכתוב קוד נקי יותר:

1. ארגון מחדש של הקוד כדי שיהיה קל לראות "מה מוביל למה"

2. שימוש ב Type Hints (בעולם ה Front End זה אומר שפה כמו TypeScript) כדי להיות מסוגלים בזמן כתיבת הקוד לדעת בוודאות מה המבנה כל אחד מהמשתנים שלנו.

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

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

בדוגמה הראשונה שימוש בספריה (או ארגון הקוד שלי כמו ספריה) ששולחת מידע ב Ajax לשרת היה מונע את הטעות בשליחת אוביקט במקום טקסט (שמובילה לשליחת המחרוזת Object object במקום ה JSON שרציתי להעביר לשרת).

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

5. מה אני מרוויח כשאני מוותר על ה Debugger?

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

אני מקווה שהדוגמאות והפוסט הזה יעזרו לכם לראות שהמציאות קצת שונה:

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