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

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

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

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

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

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

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

אבל כמובן שבשדה המקצועי הבחירה הזאת נראית הרבה יותר משמעותית - אתם יכולים ללמוד 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) נקרא משתני מחלקה פרטיים. בואו נראה בגדול מהם ואיך משתמשים בהם.

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

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

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

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

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

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

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

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

ההבדל בין:

[print(x) for x in range(10)]

ל:

for i in range(10):
    print(i)

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

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

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

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