טכניקות תכנות ישנות אליהן לא תתגעגעו - עולמי - TheMarker
 

אתם מחוברים לאתר דרך IP ארגוני, להתחברות דרך המינוי האישי

טרם ביצעת אימות לכתובת הדוא"ל שלך. לאימות כתובת הדואל שלך  לחצו כאן

תיק מניות

רשימת קריאה

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

לחיצה על כפתור "שמור", בתחילת הכתבה תוסיף את הכתבה לרשימת הקריאה שלך.
לחיצה על "הסר" תסיר את הכתבה מרשימת הקריאה.

לרשימת הקריאה המלאה לחצו כאן

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

פקודות GOTO? ניהול זיכרון? קבלו 11 טכניקות ומיומנויות אותן נזקק בעבר כל מתכנת רציני להכיר, שיכולות היום, לשמחת כולנו, לשקוע בתהום הנשייה

תגובות

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

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

אלגוריתמי מיון ומטרדים נוספים של קידוד ידני

יישומים שנכתבים היום עדיין חייבים למיין מידע, אבל כל מה שאתם צריכים לעשות זה לקרוא לפרוצדורת מיון. אולם עד שלהי שנות ה-80, תוכניתנים היו מנהלים מלחמות עולם בהקשר של אלגוריתמי מיון: עצים בינאריים מול מיון בועות משופר, והכול מהר וביעילות! זה לא רק שתוכניתנים היו צריכים לבחור באיזה אלגוריתם להשתמש, הם היו צריכים לכתוב את הקוד בכל פעם מחדש. דונלד קנות' כתב כרך שלם על הנושא בסדרת הספרים "The Art of Computer Programming". בימים ההם לא הייתם תוכניתנים רציניים אלא אם כן לפחות רציתם לקנות את הספר.


יצירה של ממשק משתמש גרפי משלכם

היו ימים בהם ממשקים טקסטואליים שלטו בעולם. עד אי שם בשנות ה-80, כל תוכניתן שרצה לפתח תוכנה בעלת ממשק חלונות היה צריך לכתוב את הממשק המופשט בעצמו, ולבדוק אותו על כרטיסי CGA, EGA, ו-VGA, באותו אופן בו אתם בודקים כיום על פיירפוקס, IE, וספארי. לא פלא שכל כך הרבה ממשקים היו מורכבים מ"להוספת רשומה לחץ 1, לעריכת רשומה לחץ 2, למחיקת רשומה לחץ 3". כיום, על מנת לייצר GUI, אתם עושים שימוש בווידג'טים של ממשק המובנים כחלק מסביבת פיתוח התוכנה החביבה עליכם, או עושים שימוש בכלי תכנון GUI נפרד. אתם גוררים ומשחררים רכיבים, קוראים לכמה פונקציות, ומוסיפים קצת לוגיקה. פשוט וקל.


פקודות GOTO וקוד ספגטי

או בעצם כל מתודולוגיות התכנות שהיו בשימוש לפני שתכנות מובנה ופיתוח מונחה עצמים באו לאוויר העולם. בשפות תכנות מוקדמות רבות, זרימת היישום נשלטה על ידי פקודות כמו למשל GOTO 10, פקודה שאמרה לתוכנה לקפוץ לשורה 10, שאולי (ואולי לא) נמצאת בין שורות 9 ל-11, ולהמשיך את הריצה משם. היה קל באופן מפחיד לקפוץ ממקום למקום בקוד, ולייצר קשר גורדי של שורות קוד, קשר שהפך סיוט תחזוקתי - מכאן למעשה צמח הביטוי קוד ספגטי. "תכנות מובנה (Structured programming), שגרס שקוד צריך להיות מחולק להחלטות, רצפים, ולולאות, היה מתנה משמיים בשנות ה-70, והיה מוצלח הרבה יותר מאשר גישת ה'קודד עכשיו, תכנן אחר-כך' אותה הוא החליף", מספר ג'יי אלקס, שהיה מתכנת קובול בשנים ההם. שפות תכנות חדשות יותר, מונחות עצמים (החל מ-C++ בתחילת שנות ה-90), האירו את הדרך עבור התכנות המובנה - מה שלא מנע מכמה מפתחים לסגור מעגל ולהמציא GOTO בעצמם.


ניהול ידני של ריבוי תהליכי ריצה וריבוי משימות

כיום, אנחנו מצפים מהמחשבים שלנו לעשות הרבה דברים בו-זמנית באמצעות ריבוי משימות (multitasking - הרצה של כמה תהליכים על מערכת הפעלה יחידה) וריבוי תהליכי ריצה (multithreading - הרצה של כמה תהליכים במסגרת אותה תוכנה). אולם מערכות הפעלה מוקדמות למחשבים אישיים כמו למשל CP/M ו-MS-DOS היו בנויות לבצע רק דבר אחד בכל פעם. תוכניתנים מבריקים עם ידע מתאים יכלו לייצר פתרונות, אבל מדובר היה על חוויה מבולגנת וכואבת. תוכניתני C למשל, יכולים היו לפנות לפקודות setjump ו-longjump על מנת ליישם ריבוי תהליכים, מה שהיה מתכון לסוף שבוע ארוך של ניפוי שגיאות וצריכת קפה מוגברת. גם היום ריבוי תהליכי ריצה אינו דבר פשוט, אבל כלי פיתוח ומערכות הפעלה הפכו את הנושא לקל הרבה יותר.


קוד המשנה את עצמו

בשנות ה-60, כאשר זיכרון היה נמדד ב-"K" (כלומר 1,024-בייט), תוכניתנים עשו כל מה שביכולתם על מנת לדחוס תוכנה בגודל מסוים לאריזה בעלת מחצית הקיבולת. אחת הדוגמאות הייתה כתיבה של תוכנות ששינו את הקוד שלהן עצמן תוך כדי ריצה. למשל, אחד התוכניתנים איתם שוחחנו הצליח לדחוס דרייבר הדפסה בגודל 7K, לגודל של 5K בלבד על ידי ביצוע מה שנקרא הסטה (shifting) של קוד שפת המכונה ביט אחד ימינה. כמה מהפתרונות הללו היו אלגנטיים בצורה עוצרת נשימה ממש, אבל מבחינת תחזוקה מדובר היה על לא פחות מסיוט גמור.

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


ניהול זיכרון

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


כרטיסי ניקוב וסביבות פיתוח מוקדמות אחרות

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

אזכורים של כבוד:

מגבלה של 8 תווים לשם קובץ - אפילו בימי חלונות 3.11 - מישהו זוכר?
מקלדת APL. APL הייתה שפת תכנות מצוינת בתקופתה, אבל הסמלים שלה דרשו מקלדת מיוחדת והיו קשים יותר לזכירה אפילו ממרבית האייקונים חסרי התועלת של חלונות.
השלכת זיכרון (Memory dump). אם הקוד שלכם קרס, מחשבי המיינפריים היו יורקים החוצה לפחות 100 דפים עליהם הדפסה ירוקה צפופה המייצגת את תוכנו המלא של הזיכרון. הייתם צריכים לעבור באופן מייגע על הרשימה כולה על מנת לגלות, למשל, שניסיתם לחלק באפס. תוכניתנים מומחים למדו טכניקת ניפוי שגיאות שכללה מילוי של הזיכרון במחרוזות DEADBEEF (ערך הקסדצימלי "קריא"), מה שסייע להם למצוא את הדליפה בזיכרון.


מתמטיקת מצביעים והמרות תאריכים

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


Hungarian Notation ומגבלות שפה אחרות

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

אזכורים של כבוד:

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



לעשות דברים מוזרים על מנת שהקוד ירוץ מהר יותר

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

אזכורים של כבוד:

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



סבלנות

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

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

תצלום: pyxopotamus, אתר Flickr


 הירשמו לניוזלטר שלנו
 עקבו אחרינו
 בטוויטר
 רוצים להיות חברים שלנו בפייסבוק?



תגובות

דלג על התגובות

בשליחת תגובה זו הנני מצהיר שאני מסכים/מסכימה עם תנאי השימוש של אתר TheMarker

סדר את התגובות

כתבות ראשיות באתר

כתבות שאולי פיספסתם

*#