אנשים שמנוסים בתחום כלשהו ויש להם את הניצוץ שמבדיל בין ידיעה (הבנה שטחית) ובין תפיסה (הבנה מעמיקה) אינם זקוקים כמעט לכללים: חוקים, כללי אצבע, נוסחאות, תרשימי החלטה וכן הלאה. זה מצוין לצרכים שימושיים - כי הם יודעים לפתור בעיות ולעשות דברים מבלי להזדקק לזמן או לחומר כתוב כדי לבחור את הפעולות הנכונות, זה לא כל כך טוב לצרכי הוראה והדרכה. דובר שפה מלידה לא מכיר את הכללים בצורה פורמלית (אלא אם למד אותם) למרות שהוא משתמש בשפה מצוין, ולכן לא יכול להיות מורה טוב ללמד את השפה הזו בצורה שיטתית (דידקטית), אלא בחניכה בלבד (שזו גם שיטה טובה, אבל יש לה חסרונות). פעם חבר שלי שלמד הנדסת תעשייה וניהול והוצרך לעסוק קצת בתכנות תוך כדי לימודי התואר, ביקש ממני לעזור לו ללמוד למבחן. אחד מהנושאים שבהם הוא התקשה הוא הגרלת מספר אקראי בטווח מבוקש. הוא הציג לי את הנוסחה שלימד אותם המרצה (איני זוכר את השפה; random מחזיר בין 0 ל-1): x = toInteger(random() * (max - min + 1) + min). הוצרכתי לזמן מה כדי להבין את הנוסחה, אבל יותר מכך הוצרכתי לזמן להבין למה צריך נוסחה. הוא מצידו שינן אותה על פה כי לא ידע איך לפתור את התרגיל בלעדיה.
רשומה זו נועדה לספר לאנשים שאין להם נסיון בתכנות או שעדיין אין להם ניצוץ מה הם הכללים שעל פיהם המתכנתים המנוסים עובדים (בהכללה). כמובן, אחרי שאתם מוכשרים מספיק, אתם כבר לא צריכים את הכללים - כי יהיה לכם ניצוץ. הרשומה מתאימה גם לאנשים שיש להם ניצוץ והם צריכים להדריך וללמד מתכנתים חדשים שלא יודעים לפתור בעיות, אבל הם לא מצליחים להסביר למתכנתים החדשים מה בדיוק לא בסדר בדרך שבה הם פותרים בעיות.
יש מתכנתים מתחילים שקשה להם לנסות או לבצע את כל השלבים ולעמוד בכללים שיתוארו להלן כי חשוב להם מאד שהקוד
(המונחים "תכנות", "קוד" וכ' מתייחסים הן לשפות תכנות ותסריט, הן לשפות סימון, הן לשאילתות בסיס נתונים, וככלל לכל טקסט שנותן הוראות למחשב) יעבוד או לראות תוצאות "עכשיו". לכן הם קופצים ישר לסוף ומבקשים עזרה ממי שנמצא לידם. זה טוב כשצריך להגיש עבודה בתוך רבע שעה ועוד לא סיימנו אותה וכד'; בכל תהליך פיתוח רגיל, זה לא רק לא-נחוץ, זה רע ומזיק לתהליך הלמידה. רע ומזיק! המורה או המדריך צריך לתת תמיכה למתלמד אם הוא נמצא על סף תסכול (או מעבר לסף זה); כל עוד לא הגענו לשם, עזרה למתכנת - לפתור את בעיותיו - כמעט תמיד מזיקה. זה דבר שצריך להיות ברור הן למלמד והן למתלמד. דין ההתלמדות בתכנות הוא כדין לימוד ההליכה: פעוט שלומד ללכת, ובכל פעם נותנים לו ידיים כדי שילך, לא עוזרים לו אלא מפריעים לו. גם כשהוא מבקש עזרה - "עזרה" זו היא לא עזרה אלא הזקה. עזרה צריך להושיט רק כאשר הפעוט נמצא על סף התסכול או מעבר לו, כי שם תהליך הלמידה של ההליכה נעצר ואין טעם להאריך את הסבל בלי תועלת (אמנם יש בזה תועלת אחרת - ללמד את הפעוט להתרגל לתסכולים; אבל זה לא חלק מהלמידה שאנו מכוונים אליה). כך גם כל אתגר תכנותי, גם אם הוא לא חלק מה"הכשרה" הרשמית של המתכנת אלא הוא חלק משגרת העבודה, אין לראות בו רק את עצמו ("אני צריך למצוא את הבאג"; "אני צריך לקחת את הביסקוויט") ואז נרצה לעשותו יותר מהר ונחפש קיצורי דרך בדמות היסמכות על אנשים אחרים, אלא יש לראות בו מטרה גדולה יותר - לימוד וחישול ("אני צריך לדעת למצוא באגים לבד"; "אני צריך לדעת איך להגיע לביסקוויט לבד").
"יש לי באג"
כשאנו כותבים קוד או מקבלים קוד קיים, ורואים שהוא מפיק תוצאה לא רצויה, עלינו להבין מה גרם לתוצאה זו ומנע את התוצאה המקווה. עלינו לעבור על השלבים הבאים בזה אחר זה, כדי להגיע לפתרון מהיר ועצמאי. ככל שמיומנותנו גבוהה יותר, הפתרון – ככלל – יימצא בשלב מוקדם יותר, וככל שהבעיה מורכבת יותר או שאינה בתחום הנסיון שלנו, הפתרון יימצא בשלב מאוחר יותר. כך או כך, עבודה לפי סדר השלבים היא תנאי הכרחי לפיתוח מיומנויות של תכנות (מציאת תקלות ופתרון בעיות) ולכן עלינו להקפיד לעבור שלב שלב ולא לקפוץ מראש לשלב האחרון. המטרה היא, בכל השלבים, מציאת השורה המדויקת שפועלת פעולה שגויה והבנה מדוע השורה הזו פועלת את הפעולה השגויה. עוברים לשלב הבא רק אם ניסינו את השלב הקודם והוא לא עזר לנו לאתר את הבעיה או לפתור אותה, או שנוכחנו לדעת שבמקרה המסוים שלנו השלב הקודם מסובך מדי או ממושך מדי (ניפוי עדין פעמים רבות יהיה מתיש יותר מניפוי גס, לדוגמה).
שלבי הפתרון הם:
- התבוננות – עלינו להתבונן בתוצאה ולהבין מה שגוי בדרך שבה הקוד נכתב, מתוך היכרות מוקדמת עם הקוד.
- קריאה – עלינו לקרוא את הקוד ולהבין, תוך מעקב בעיניים, מהי הנקודה הגורמת לתוצאה השגויה.
- ניפוי עדין – עלינו להשתמש בכלי ניפוי עדינים (watch, step in/out/over וכו') ולהבין מהי הנקודה שגורמת לתוצאה להתעוות.
- ניפוי גס – עלינו לשנות את התנהגות הקוד (להזיז את נקודת הריצה, לשתול בקוד הדפסות, לשנות שורות כדי לדלג על תהליכים וכד') ולהבין מהי הנקודה שגורמת לתוצאה להתעוות.
עד שלב זה צריכה להיות בידינו השורה הבעייתית. אם אין לנו אותה, כנראה לא ביצענו את שלבי הניפוי בצורה מספקת, אם כי ישנם מקרים שבה בכל זאת לא נמצא אותה, כי יש פעילות כלשהי שרלוונטית אלינו אבל חלקה פועלת מאחורי הקלעים. אבל גם אם יש לנו את השורה הבייעתית, ייתכן שהבעיה עדיין לא פתירה, כי אנחנו לא מבינים מה בעייתי בה. נמשיך...
- צמצום – עלינו לצמצם את הבעיה לקונסטרוקציה המינימלית (קובץ אחד של C# עבור בעיה ב-C#, קובץ אחד ב-HTML עבור בעיות של CSS/JS/HTML. במידת הצורה, שני דפים (אם זו בעיה שנוגעת לקישור בין דפים); וכיוצ"ב) שבה היא מתרחשת. עלינו לבודד את קטעי הקוד שיוצרים תוצאה לא צפויה, ולעשות מהם יחידת פעולה (ריצה – עבור שפות תכנות ותסריט, פעולות אחרות – עבור שפות סימון ושאילתות וכו') עצמאית. אפשר לעשות את זה מתוך הקוד הקים על ידי השמטת כל החלקים הלא רלוונטיים, או על ידי יצירת מודל שממחיש את הבעיה. יש לוודא אחרי השלמת הצמצום:
- שאין חלקים מיותרים בצמצום (אם יש – להשמיטם);
- שהקוד המצומצם אכן מפיק תוצאה בעייתית (אם לא – לחזור לקוד המלא ולצמצם).
לאחר הצמצום, עלינו לחזור ולעבור על השלבים הקודמים עם הקוד המצומצם. במקרים רבים מאד שלב זה יגלה לנו שיש שורת קוד כלשהי שרצה לפני שורת הקוד שבה חשדנו, והיא זו שגורמת לבעיה בשורה שאותה מצאנו, ולעיתים נבין שפעולה כלשהי של מערכת ההפעלה או של ספרייה שבה אנחנו משתמשים פועלת אחרת ממה שציפינו.
- חיפוש – עלינו לחפש במדריכים, רפרנסים, קבצי עזרה, שו"תים בפורומים וכיוצ"ב, הסבר להתנהגות הבלתי צפויה. החיפוש יתבצע על פי הפקדוה שיוצרת את הבעיה. השפה שבה נכתבה הבעיה, המטלה המבוקשת או כל דרך אחרת שנדמית כיכולה לתאר את הבעיה.
- בקשת עזרה – זהו. זה השלב שבו, אם בצענו את כל השלבים הקודמים כמו שצריך ובלי רישול, אנו פונים לעזרה של מישהו אחר. בקשת העזרה יכולה להיות מאדם שאנו מכירים (עמית לצוות וכד') או מפורום שבו אנו חברים. בד"כ עדיף לבקש עזרה מאדם שאנו מכירים לפני ששואלים בפורום (בפרט בקשיים התחלתיים), אבל אסור לנו להתרגל כל כך לבקשת עזרה מחבר עד שנשכח שישנה אפשרות לשאול בפורומים בצורה יזומה (ואז אם אין לנו חברים או שהם לא יודעים לעזור, אנחנו חושבים שאנחנו אבודים. לא כך!). בקשת עזרה, בין אם מחבר ובין אם בפורום, צריכה להיעשות כך: הצגת קוד בצורה המצומצת שלו (כאמור, תוך כדי הצמצום רוב הבעיות שלנו תפתרנה מאליהן ולא נצטרך לפנות לעזרה, אבל אם קרה שלא נפתרו...), והסבר ברור של הבעיה (מה אנו מצפים שיקרה ומה קורה בפועל), מיקוד לשורה החשודה כבעייתית, תיאור כל עובדה היקפית שייתכן שהיא רלוונטית (גרסת שרת, גרסת VS, גרסת מכונת דוטנט וכו') ותיאור נסיונותינו להבנת הבעיה ונסיונות לפתור אותה או לעקוף אותה. עלינו לכתוב בבירור כל דבר שאנו יודעים או חושבים שאנו יודעים על הגורמים לבעיה (ומה הן הראיות התומכות בהסבר שלנו לגורמים); אין להטריח אנשים נחמדים שרוצים לעזור לנו, לחינם.
"אני לא יודע איך עושים"
ייתכן שבמהלך אחד מהשלבים לעיל, יתברר לנו שכל הקוד ברור לנו, אלא שבעצם אנו לא יודעים איך לעשות מה שאנו רוצים לעשות, למרות שחשבנו שאנו יודעים. ייתכן גם שמראש לא תהיה לנו כל תקלה, אלא שאנו מנסים לעשות משהו ואנו לא יודעים איך לעשות אותו.
שלבי הפעולה במקרה זה הם (בדומה לשלבים 5, 6, 7 לעיל):
- ניסוי וטעיה ("אני לא יודע אם זה יעבוד" לא זהה ל"אני לא יודע איך לעשות"; אם אני לא יודע האם הרעיון שלי 'עובד' או לא – עליי לנסות ולגלות אם הוא 'עובד' או לא).
- חיפוש ב'עזרה', ברפרנסים ומדריכים ברשת ובמקומות אחרים על פי מטלות דומות, פונקציות קרובות, מילות מפתח;
- פנייה לחבר/לפורום בצורה ממוקדת ועניינית תוך פרישת מלוא העובדות הרלוונטיות בצורה המצומצמת שלהן (לא את תיאורו של כל פרוייקט הגמר שלנו, כאשר מה שאנו מבקשים לדעת זה איך מחשבים שורש ריבועי). אין לצפות שהחבר או הפורום יכתבו עבורנו את הקוד או יסבירו הכול; סביר יותר ומקובל יותר שיתנו הסבר קצר ובסיסי ויפנו אותנו למקום אחר. זה מצוין; עלינו לדעת לקרוא וללמוד לבד רפרנסים, מדריכים ומאמרים.
