יום שישי, 27 בפברואר 2009

פודקאסט מספר 8 - Debugger - ידידו הטוב של המפתח... או שלא?


היי לכולם.
שוב איתנו יוסי גיל והיום... הפתעה - איסור מוחלט על שימוש ב-DEBUGGER.
  • האם אפשר לחיות בלי Debuggers?
  • שיטת ה"דלות" - או -DALUT (תיעוד, התראות, לוגים, ויחידות בדיקה).
  • "קודם כל לחשוב" - טוב זה תמיד נכון.
  • String- בירושלמית זה "סדרית".
  • "לדבג" זה יותר מהיר או איטי?
  • Debugger- העיניים שמראות לנו את מקרי הקצה.
  • אספקטים של חיזוי זמן פיתוח.
  • חוויותיו של יוסי בשוחות הקוד.
  • לוגים - פסטיבל מספרי סיפורים של מה שקורה לקוד שלך בזמן אמת, אצל הלקוח.
  • MULTI-THREADING - דיבאגגינד בסביבה מרובת פתילים.
  • קריאת קוד מעמיקה של כמה אנשים יכולה למצוא באגים ממש קשים.
  • האם יש מקרים לגיטימיים להשתמש ב-Debugger?
  • חיפוש באגים כמו שמחפשים אריה במדבר.
  • Code Review - כלי נוסף לשפר איכות קוד ולעלות על באגים.
גלשנו בזמן כי היה לנו מאוד מעניין - אז קבלו את התנצלותנו על כך.
ועוד התנצלות - אנחנו מאוד משתדלים לדבר בעברית תקנית אבל חוטאים בזה לעיתים קרובות ומשרבבים יותר מדי מילים באנגלית. נשתדל להמעיט.

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

16 תגובות:

  1. שאלתי שאלה בנושא ב stackoverflow ויש הרבה תגובות... חלקן גם מצחיקות. שווה קריאה!
    http://stackoverflow.com/questions/602138/is-a-debugger-the-mother-of-all-evil

    השבמחק
  2. לאורך כל הפודקאסט נעתי בין הסכמה עם יוסי לבין אי הסכמה איתו. לבסוף הבנתי את הדבר הבא: מתכנת טוב לא נמדד בזה שהוא ישתמש ב-DALUT בשביל לפתור את הבאג הבא שלו, אלא הוא ימדד בזה שהוא ידע להבדיל בין באגים שצריך עבורם דיבאגר לבין אלא שצריך עבורם להשתמש ב-DALUT. כי ישנם באגים ש-Unit Testing טוב יעלה עליהם, ויש כאלו שבשביל לפתור אותם עם DALUT צריך לכתוב לוג אחרי כל שורה של קוד (מה שלא הגיוני ולא נדרש ב-long run), לעומת ריצה אחת עם דיבאגר.

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

    בקיצור - כמו עם כל דבר, קיצוניות זה רע וצריך למצוא את האיזון בין הדברים.

    ותמשיכו עם התוכניות המצוינות האלו :)

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

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

    השבמחק
  5. Hi Yoni, we did try iCast, but it was very problematic for us so we quit.
    We don't like the hosting features there and we much prefer the ones on ourmedia.
    We would like to host on ourmedia and have that listed on iCast but it seems iCast don't allow that, or at least I wasn't able to find it.
    If you have friends at iCast, drop them a line, (or drop me a line) perhaps I missed something
    Thanks and enjoy 

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

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

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

    לסיכום - דיברתם על פרדיקטביליות (תחזיתיות? צפיינות?) ועל deadline - אנא ישמו זאת בפודקאסט. קרה המקרה ונסחפתם? ערכו לאחר מעשה ותוציאו מזה שני פוסטים.

    השבמחק
  8. הערה שניה ושלישית, והפעם לגוף הענין

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

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

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

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

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

    השבמחק
  10. רן ידידי יודע כי אני שמח לחרחר מלחמות דת, אך הרבה פחות מכן להשתתף בהן אחר פרוץ הקרבות.

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


    -יוסי גיל.

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

    השבמחק
  12. הי איל, ד"ש לילדים. אף פעם לא מוקדם מידי להתחיל עם השכלה במדעי המחשב

    השבמחק
  13. מסכים עם הקביעה ש DALUT הוא עדיפות ראשונה, אבל לוותר על כלי מארגז הכלים זה טעות. לכל כלי יש יתרונות וחסרונות וכמו כן גם לDALUT. על פי Dijkstra "testing can be used very effectively to show the presence of bugs but never to show their absence". בתוכנות מורכבות קשה מאוד לבדוק את כל מצבי המכונה ולא בלתי סביר שהמשתמש קצה יציג מצב שהתכנת לא חשב עליו (כמו arithmetic overflow) ולא נראה לו שצריך לתעד בלוג (כל פעולה אריטמטית למשל). סביר גם שבתוכנות מורכבות המבצעות אלפי חישובים בשניה לא ניתן לתעד בלוג את כל מצבי התכנה (מפאת ביצועים וזיכרון).

    מעניין לשמוע מה דעתכם על בן דודו של הDebugger הוא הProfiler.

    השבמחק
  14. תודה ישי
    profiler אכן נושא מעניין - נירשם.

    השבמחק
  15. זה מה שדוד בוב כתב על הנושא:
    http://www.artima.com/weblogs/viewpost.jsp?thread=23476

    השבמחק