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

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

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

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