תפסיקו לבזבז זמן על Debugging

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

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

לפני זמן מה שאלתי בלינקדאין (LinkedIn): "כמה זמן אתם מבזבזים על Debugging?" קיבלתי מספר תשובות מעניינות. אחד העונים כתב: "לא הייתי רוצה לומר כמה זמן אני משקיע בכך… מדובר בהמון זמן וכן, זה מטריד אותי! ההערכה שלי היא שיותר מ-50% מהזמן שלי מושקע בניסיון להבין למה משהו בקוד לא מתנהג כפי שהוא אמור להתנהג".

משיב אחר כתב: "כשעה מתוך יום עבודה של שמונה שעות הולכת על Debugging". זה לא נשמע הרבה, נכון? מדובר ב-12%. אבל שימו לב לתשובה הבאה: "אני יכול להשקיע יום עבודה שלם בפתרון בעיות רק כדי שהקוד יעבוד כמו שצריך". יום עבודה שלם. ותשובה נוספת: "אני יודע שזה לא תהליך העבודה היעיל ביותר, אבל אני שייך לאסכולה של 'ניסוי וטעייה', ולכן אסכם זאת כך: כ-99% מהזמן שלי מושקע ב-Debugging".

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

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

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

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

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

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

סיכום
אם Debugging הוא מזימה של קונגולמרטים למכור לנו כלים לפתרון בעיות ובזבוז משאבים אדיר – מה נותר? אין תשובה חד משמעית, אבל מחקרים שנעשו בתחום חקר עלויות של באגים הוכיחו מעבר לכל ספק כי ככל שהורגים אותם כשהם קטנים יותר, העלות נמוכה יותר. אחת הדרכים היעילות ביותר למזער נזקים של באגים תוך שיפור איכות הקוד וקיצור תהליך הפיתוח והתחזוקה של הקוד לאורך כל חיי המוצר, שלא לדבר על הוזלת עלויות התהליך כולו (ALM), היא בדיקות יחידה אוטומטיות (Automated unit testing). בדיקות אלה מאפשרות למתכנתים לבחון את הקוד שלהם באופן מתמשך ויומיומי, לבדוק בדיוק איפה הוא נשבר ולמה, ולהכניס שינויים לקוד מבלי חשש לשבור דברים אחרים בתהליך.

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

לכתבה הראשונה בסדרה: על ההבדל בין בדיקות יחידה (unit tests) לבדיקות אינטגרציה (integration tests)

אודות הכותב
גיל זילברפלד הוא מנהל המוצר של חברת Typemock – The Unit Testing Company. בזמנו החופשי (למרות שאין לו הרבה ממנו) הוא מרצה וכותב על Agile, בדיקות יחידה (Unit testing) ו-TDD, ולפעמים גם חוטא בהרצאות על עניינים עסקיים ושיווקיים, הקשורים לעולם ההיי-טק ופיתוח התוכנה.