#41 הקלות הבלתי נסבלת של התכנות

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

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

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

אם תבדקו את המקלדות של מפתחי תוכנה, תוכלו לראות שהמקשים הדהויים ביותר הם CTRL, C וְ V. כל היום רק העתק-הדבק. ללא ספק כתיבת תוכנה היא אחר המקצועות העתיקים בעולם, מלשון העתקה כמובן.

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

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

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

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

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

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

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

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

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

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

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

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

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

באנגלית זה נשמע יותר טוב:

If debugging is the process of removing bugs, then programming must be the process of putting them in

–Edsger W. Dijkstra