פסאודו-קוד לנוער — מתכננים אלגוריתם לפני שכותבים קוד
לפני שבוחרים Python, JavaScript או Java, אפשר לבדוק אם הרעיון בכלל ברור. פסאודו-קוד הופך משחק או משימה לרצף צעדים שאפשר לקרוא, להריץ על הנייר ולשפר.
התרגיל נשמע קל עד שמנסים לנסח אותו. איפה הדמות מתחילה? איך יודעים שנגעה בכוכב? מה משתנה אחרי האיסוף? מתי המשחק נעצר? כל שאלה כזו חושפת החלטה שהמחשב לא יכול להשלים לבד.
כאן נכנס פסאודו-קוד: תיאור מסודר של אלגוריתם בשפה אנושית, בלי להתחייב עדיין לתחביר של שפת תכנות. הוא מספיק מדויק כדי לבדוק את הלוגיקה, אבל מספיק חופשי כדי שגם מי שעובד ב-Scratch וגם מי שלומד Python או Java יוכל להשתמש באותו רעיון.
בחומרי Python ו-Java שנמסרו למכללה מופיעים מבנה של אלגוריתם, תכנון, מימוש, תנאים, לולאות ופונקציות. אלה מקורות ההקשר למאמר. הפרטים מתארים עקרונות לימודיים ואינם התחייבות לתוכן של מסלול או מחזור נוכחי.
מה פסאודו-קוד כן עושה
שומר על ההיגיון
הוא מציג סדר, תנאים, חזרות ונתונים משתנים כך שאפשר לעקוב אחרי התהליך מתחילתו ועד סופו.
חושף חורים בתכנון
אם אי אפשר להסביר מה קורה במקרה מסוים, כנראה שגם הקוד עדיין לא ידע לטפל בו.
ומה הוא לא עושה?
פסאודו-קוד אינו שפה תקנית והמחשב לא מריץ אותו. אין צורך להתווכח אם חסר סוגר או נקודה ופסיק; המבחן הוא האם אדם אחר יכול לבצע את הצעדים בלי לנחש החלטות נסתרות.
מרעיון של משחק לשבע שורות שאפשר לבדוק
במקום לכתוב ״בנו משחק איסוף״, מנסחים את השלד. לא מתארים עדיין גרפיקה, מקשים או ספרייה; מתמקדים במה שהמערכת חייבת לדעת ולעשות.
- 1
קבעו ניקוד ל־0 - 2
כל עוד נותר זמן במשחק: - 3
קראו את הפעולה של השחקן - 4
אם השחקן נוגע בכוכב: - 5
הוסיפו 1 לניקוד - 6
העבירו את הכוכב למקום חדש - 7
הציגו את הניקוד הסופי
ארבע שאלות שמארגנות כמעט כל אלגוריתם ראשון
- רצף
- מה חייב לקרות קודם ומה אחר כך?
- קודם מאתחלים ניקוד, אחר כך מתחילים את המשחק.
- תנאי
- מתי הדרך מתפצלת?
- אם השחקן נוגע בכוכב, הניקוד משתנה.
- חזרה
- איזו פעולה צריכה לקרות שוב?
- כל עוד המשחק פעיל, ממשיכים לקרוא קלט ולעדכן.
- מצב
- איזה מידע משתנה לאורך הדרך?
- הניקוד, הזמן והמיקום הם מצב שצריך לנהל.
מריצים את האלגוריתם עם אצבע ועיפרון
בוחרים סדרת אירועים קטנה ועוברים שורה־שורה. בכל תחנה רושמים את הקלט, את המצב לפני הפעולה ואת התוצאה. כך אפשר לגלות תנאי חסר לפני שהוא הופך לבאג בתוך תוכנית ארוכה.
- 1
תחילת המשחק
- קלט:
- אין פעולה
- מצב:
- ניקוד 0, זמן פעיל
- תוצאה:
- ממתינים לפעולת השחקן
- 2
בדיקה ראשונה
- קלט:
- השחקן זז ימינה
- מצב:
- אין מגע בכוכב
- תוצאה:
- הניקוד נשאר 0
- 3
בדיקה שנייה
- קלט:
- השחקן נוגע בכוכב
- מצב:
- התנאי מתקיים
- תוצאה:
- הניקוד עולה ל־1 והכוכב עובר
אותו תכנון, תרגום שונה בכל סביבת עבודה
פסאודו-קוד טוב מפריד בין הבעיה לבין כלי המימוש. לכן אפשר לשמור על חוקי המשחק ולעבור מסביבה חזותית לשפה כתובה בלי להמציא מחדש את כל הלוגיקה.
בזמן התרגום עשויים להתגלות פרטים טכניים חדשים, כמו דרך קריאת המקלדת או ציור למסך. מוסיפים אותם לתוכנית, אבל לא משנים בשקט את חוקי המשחק. אם החוק משתנה, חוזרים גם למסמך התכנון ומעדכנים אותו.
Scratch
״כל עוד״ הופך ללולאת חזרה, ו״אם נוגע בכוכב״ לבלוק תנאי עם חיישן מגע.
Python
מצב המשחק נשמר במשתנים, והצעדים מתורגמים ללולאה, לתנאי ולפונקציות קטנות.
JavaScript
אירועי מקלדת מעדכנים את המצב, ולולאת המשחק בודקת מגע ומציירת את התוצאה בדפדפן.
ארבע מלכודות שמחלישות את התכנון
כותבים משפט גדול מדי
ניסוח חלש: תפעילו את המשחק ותדאגו שהכול יעבוד.
שיפור: פרקו לקלט, עדכון מצב, בדיקת מגע והצגה למסך.
מסתירים החלטה בתוך מילה
ניסוח חלש: אם השחקן מצליח, תנו נקודה.
שיפור: הגדירו מה נחשב הצלחה: מגע בכוכב בזמן שהמשחק פעיל.
מדלגים על מקרה קצה
ניסוח חלש: ממשיכים לשחק עד שמסיימים.
שיפור: כתבו מה קורה כשנגמר הזמן או כשאין מקום פנוי לכוכב.
מחקים תחביר מוקדם מדי
ניסוח חלש: מתווכחים על סוגריים לפני שהרעיון ברור.
שיפור: נסחו בעברית פשוטה ורק אחר כך בחרו תחביר של שפה.
איך יודעים שהתכנון בשל לקוד?
לא צריך מסמך מושלם. צריך תיאור שאפשר לבדוק ולתקן. היכולת להסביר החלטה, לשנות צעד ולחזות את התוצאה היא סימן חשוב יותר משימוש במונחים מרשימים.
- אפשר לזהות בבירור היכן האלגוריתם מתחיל ומתי הוא מסתיים.
- כל צעד מתאר פעולה אחת שאפשר לבצע או לבדוק.
- לכל תנאי יש ניסוח מדויק, ולא מילים עמומות כמו ״אם זה עובד״.
- ברור אילו ערכים משתנים ומתי הם מקבלים ערך התחלתי.
- בדיקת נייר אחת לפחות עברה גם במקרה רגיל וגם במקרה קצה.