הבלוג של ינון פרק

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

״למה לי להתחיל פרויקט מאפס? עדיף להשתמש ב create-react-app ולקבל שלד לפרויקט שכבר כולל את כל מה שאני צריך?״

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

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

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

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

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

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

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

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

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

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

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

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

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

אתם יכולים לראות את הסידרה שכולם מדברים עליה (ואז בטוח יהיה לכם עם מי לדבר ותרגישו בעניינים), או שתבחרו סידרה שאף אחד לא שמע עליה.

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

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

בשדה הטכנולוגי כדאי לזכור שיש מעט מאוד טכנולוגיות שהן באמת ללכת על בטוח. Java היא כזו וכנראה גם JavaScript, תתחילו ללמוד אותן היום ובעוד שנתיים עדיין כולם ידברו על זה.

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

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

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

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

BookCategory.all.select {|bc| bc.category.nil? }

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

במקום זה אפשר להשתמש בשאילתה שקולה לחלוטין שנראית כך:

BookCategory.left_outer_joins(:category).where("categories.id is null")

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

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

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

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

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

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

ובכל זאת רוב האנשים לא מבלים את ימיהם ולילותיהם בלימוד נושאים חדשים, למרות שיש לנו זמן, ולמרות שיש לנו את כל הכלים להצלחה.

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

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

התמדה יוצרת מוטיבציה, לא להיפך.

בפוסט של אתמול הופיעה שורה קצת מוזרה:

  constructor() {
    this.inc = this.inc.bind(this);
  }

למה לקשור את הפונקציה לעצמה? איך זה משפיע על הקוד? והאם דברים יעבדו גם בלי זה? בואו ניקח 5 דקות לדבר קצת על bind ו this ואני מקווה שבסופן נבין את התעלומה.

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