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

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

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

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

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

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

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

לפני כמה שבועות הסברתי לאנשים בקורס React על Redux ועל כל הדברים המדליקים שאפשר לעשות איתה. ההתחלה היתה מלהיבה וכולם אפילו הצליחו לשרוד את הסיפור על ה Stores והפונקציה reducer. ואז הגענו לחבר את כל העסק הזה ל React ויכולתי לראות קבוצה שלמה של תלמידים מרוכזים נעלמת והופכת לאוסף של מבטים מיואשים. והאמת? אני די מבין אותם.

נניח שיש לי State של אפליקציה שנראה ככה:

const initialState = {
  home: [
    { id: 1, text: "buy stuff", done: false },
    { id: 2, text: "clean the kitchen", done: false },
    { id: 3, text: "cook dinner", done: true }
  ],
  work: [
    { id: 4, text: "prepare webinar text", done: true },
    { id: 5, text: "write daily post", done: false },
    { id: 6, text: "prepare slides for talk", done: false }
  ],
  hobbies: [{ id: 7, text: "write a cool tetris game", done: false }]
};

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

const TaskGroup = connect((state, ownProps) => ({
  tasks: state[ownProps.group],
  group: ownProps.group
}))(function TaskGroup({ tasks, group }) {
  return (
    <div>
      <h2>{group}</h2>
      <ul>
        {tasks.map(task => (
          <li>{task.text}</li>
        ))}
      </ul>
    </div>
  );
});

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

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

function TaskGroup({ group }) {
  const tasks = useSelector(state => state[group]);

  return (
    <div>
      <h2>{group}</h2>
      <ul>
        {tasks.map(task => (
          <li>{task.text}</li>
        ))}
      </ul>
    </div>
  );
}

הפקודה useSelector מושכת מידע מה State ומחזירה אותו, וחוסכת לנו את כל העבודה המעיקה עם connect. וכן יש גם useDispatch שמחזירה את הפונקציה dispatch. פרטים נוספים ודוגמאות בתיעוד https://react-redux.js.org/api/hooks.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

זד שו הוא אחד ממדריכי ה Python האהובים עליי בעולם כולו. הקורס שלו Learn Python The Hard Way מציג גישה טובה שמתאימה גם לאנשים בלי כל רקע מוקדם ואת העקרונות שראיתי אצלו אני מנסה ליישם גם בקורסים פה באתר.

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

אבל לא הייתי שולף אותו מהארכיון אלמלא היה לקח חשוב לקחת מהסיפור הזה: הבחירה שלנו לאמץ או להדוף טכנולוגיה כמעט תמיד מושפעת (גם) מהדברים שאנחנו יודעים וממה יש לנו לאבד. אם אני מתחיל פרויקט חדש ואני כבר יודע React אבל לא יודע Angular, הרבה פעמים אני אתבלבל ואנסה להעלות טיעונים כאילו טכניים נגד אנגולר ובעד ריאקט, רק בגלל שאני מכיר אחד ולא את השני. זה קרה לי, זה קרה לזד שו וזה כנראה יכול לקרות גם לכם.

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

"יש לי כבר את כל החומרים ב Python2 וכרגע לא באג'נדה שלי להעלות קורס חדש ב Python3"

"אני לא מכיר Angular, וכרגע לא באג'נדה שלי ללמוד אותו"

"לא ניסיתי עדיין לכתוב קוד ב React Native, אבל אני די מהיר ב Swift ומעדיף לעבוד על כלים שאני כבר מכיר"

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

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

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

1. כמה Refactoring מוצלחים עשיתי החודש? וכמה כושלים?

2. עד כמה הכלים ושיטות העבודה שפיתחתי החודש עוזרים לי לפתור בעיות מהר יותר?

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

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

5. באיזו מידה הצלחתי לעזור לחברים לצוות לשפר את העבודה שלהם? באיזו מידה עזרתי להם לחשוב על רעיונות חדשים ויצירתיים שהם התקשו למצוא לבד?

6. איזה רעיונות חדשים ושיטות עבודה חדשות הצלחתי לשלב בתהליך הפיתוח בארגון שהשפיעו לטובה על תרבות העבודה?

רק בגלל שקל למדוד משהו לא אומר שזה כדאי.

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

Fixed some stuff

והשניה:

Disabled server-side rendering because it was too slow.

In the future before turning this back on make sure to add caching support so we'll be able to reuse server-side rendered fragments between requests.

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

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