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

הפונקציה React.lazy משמשת לטעינה עצלה של פקדי ריאקט, כלומר היא תאפשר לנו בצורה מאוד קלה להגדיר שפקד ריאקט מסוים לא ייכלל בקובץ ה JS הגדול של העמוד וייטען רק אם מישהו ינסה לעשות לו render. דוגמא פשוטה לשימוש בה אפשר למצוא בתיעוד והיא נראית כך:

const OtherComponent = React.lazy(() => import('./OtherComponent'));

function MyComponent() {
  return (
    <div>
      <Suspense fallback={<div>Loading...</div>}>
        <OtherComponent />
      </Suspense>
    </div>
  );
}

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

קסם? לא ממש. רוב מה ש React.lazy עושה אנחנו יכולים לעשות נפלא גם בלעדיו - בואו נראה איך.

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

def v1(fin_name, fout_name):
    with open(fin_name, encoding='utf8') as fin:
        with open(fout_name, 'w') as fout:
            for line in fin:
                fout.write(line)

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

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

הנה הקוד אחרי שהוספתי את ExitStack:

from contextlib import ExitStack
def v2(fin_name, fout_name):
    with ExitStack() as stack:
        fin  = stack.enter_context(open(fin_name, encoding='utf8'))
        fout = stack.enter_context(open(fout_name, 'w'))
        for line in fin:
            fout.write(line)

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

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

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

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

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

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

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

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

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

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

הי חברים,

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

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

אני יכול לדלג על קטעים שלא מעניינים אותי.

אני יכול להתאמן בלי שאף אחד מסתכל.

ואני יכול לשאול שאלות בלי להרגיש שרק אני לא הבנתי.

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

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

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

הקורס הראשון יהיה React ומיועד למתכנתים שכבר יודעים לכתוב קוד Front End, מכירים JavaScript ברמה סבירה אבל מכל מיני סיבות לא הצליחו עדיין להיכנס לשוק העבודה למשרות ה Front End הטובות באמת. הקורס ייפתח באמצע מרץ ויימשך חודשיים.

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

לכל הפרטים על קורס ריאקט הקרוב מוזמנים לקפוץ לדף הנחיתה החדש שבניתי בקישור https://www.tocode.co.il/bundles/react

נתראה בקורס ינון

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

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

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

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

function EditableLabel_View(props) {
  const { text, startEdit } = props;
  return (<p onClick={startEdit}>{text}</p>);
}

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

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

function EditableLabel_Edit(props) {
  const { text, setText, done } = props;

  function doneIfEnter(e) {
    if (e.keyCode === 13) {
      done();
    }
  }

  return (
    <input
      type="text"
      value={text}
      onChange={(e) => setText(e.target.value)}
      onBlur={done}
      onKeyDown={doneIfEnter}
      />
  );
}

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

function EditableLabel(props) {
  const [text, setText] = useState(props.text);
  const [edit, setEdit] = useState(false);

  if (edit) {
    return <EditableLabel_Edit text={text} setText={setText} done={() => setEdit(false)} />
  } else {
    return <EditableLabel_View text={text} startEdit={() => setEdit(true)} />
  }
}

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

class App extends React.Component {
  render() {
    return (
      <div>
        <EditableLabel text="Hello world" />
      </div>
    );
  }
}

ואפשר לראות את הקסם כולו בפעולה בקודפן הבא:

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

function makeEditableComponent(View, Edit) {
  return function EditableLabel(props) {
    const [data, setData] = useState(props.defaultValue);
    const [edit, setEdit] = useState(false);

    if (edit) {
      return <Edit data={data} setData={setData} done={() => setEdit(false)} />
    } else {
      return <View data={data} startEdit={() => setEdit(true)} />
    }
  }
}

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

const EditableLabel = makeEditableComponent(EditableLabel_View, EditableLabel_Edit);

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

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

זאת שאלה טובה כי היא מחביאה הרבה ניואנסינים במיוחד המילה "שווה".

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

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

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

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

אבל... אני לא רוצה להיות מפתח Mobile כל החיים אבל ... כולם מדברים על Machine Learning אבל ... שמעתי ש Full Stack זה המקצוע הכי טוב למתכנתים אבל ... בדיקות אוטומציה זה משעמם

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

1. לבנות משהו פשוט לפי Tutorial.

2. לבנות משהו קצת יותר גדול לבד.

3. לקרוא ספר.

4. לקרוא קוד של אחרים.

5. לשמוע הרצאות מכנסים ביוטיוב.

6. לעשות Refactoring לקוד שכבר כתבנו.

7. לחזור לסעיף (2)

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

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

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

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

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

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