אבל התכנית שלי רצה!  חוקי דו-שיח עבור מתכנתים מתחילים

ס.א. ג'וני ו- א. סולווי

S.A. Joni and E. Soloway (1986). But my program runs! Discourse rules for novice programmers. Journal of Educational Computing Research, Vol 2(1), 95-126.

התקציר המצורף נערך ע"י ד"ר ברוריה הברמן

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

הוצאת "מחשבה" – מרכז המורים הארצי למדעי המחשב, 2001. עמודים 27-31.

אודות המאמר

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

 

רשימת מושגים

 wאיתחול מרובה –       Multiple initializations

w התניה לא מתאימה – Inappropriate conditionalization

w חוקי דו-שיח בתכנות – Rules of programming discourse    

w יעילות – Efficiency

w קריאות תכנית – Program readability              

w תבניות תכנות – Programming plans

 

מבוא

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

לקויות של תכניות שאינן בנויות היטב

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

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

 הצג כפלט ('אנא הקש את המשכורת שלך')

      קלוט ערך למשתנה Salary

      כל עוד Salary < o  בצע

                     הצג כפלט ('קלט שגוי, אנא הקש שנית את המשכורת שלך')

                     קלוט ערך למשתנה NewSalary

                     NewSalary  -->  Salary

              

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

הערכת איכות של תכנית

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

מדוע יעילות אינה יכולה לשמש מדד עבור מתחילים?

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

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

מדוע צריך להגדיר חוקי דו-שיח עבור מתחילים?

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

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

קריאות של תכנית

תכנית קריאה (readable) היא תכנית הכתובה בהתאם לחוקי דו-שיח של מתכנתים. תכנית יכולה להיות נכונה אך לא קריאה בגלל שאינה כתובה בהתאם לכללים המקובלים.

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

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

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

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

אמירות תכנות וחוקי דו-שיח

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

האמירה הראשונה מתייחסת לאופן בחירת משתנים לייצוג נתונים.

אמירה 1:

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

 

פחות מדי משתנים: אמירה זו ממליצה להתאים שם אחד לכל תפקיד של מידע, אולם אינה מתייחסת למקרה שמשתנה משמש לשני תפקידים. משתנה כזה מכונה משתנה בעל תפקיד כפול  (double-duty variable). מסתבר ששימוש במשתנים כאלו עלול ליצור בעיה בקריאות תכנית. בהתאם, על בסיס האמירה, נוסח הכלל הבא:

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

 

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

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

 

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

אמירה 2:

1. וודא שכל קטעי הקוד משמשים לביצוע המשימה הנדרשת.

2. השתמש במבנים בשפה המציגים באופן ברור את מה שהתכנית מבצעת.

 

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

כלל: הקפד לאתחל כל משתנה פעם אחת בלבד.

 

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

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

כלל: השתמש במבנה IF על מנת לדלג על שורות קוד (ביצוע חד פעמי מותנה), ובמבנה WHILE רק כאשר יש צורך בביצוע חוזר מותנה.

 

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

 

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

בכל מקרה אחר, אל תגדיר את המשתנה כפרמטר משתנה.

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

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

 

אמירה 3 מתייחסת לכתיבת תכנית בה קיים מיזוג מטרות.

אמירה 3:

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

 

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

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

כלל: אל תשלב בדיקת תקינות קלט עם אף תת-משימה אחרת.

 

סיכום

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

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

חזרה לאתר