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

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

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

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

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

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

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

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

הנה דוגמא קטנה שמבוססת על קוד שראיתי היום בקורס. שימו לב ל HTML הבא:

<label>
  Stuff
  <table>
    <tr>
      <td>One</td>
      <td><button onClick="alert('one')">Ouch!</td>
    </tr>
    <tr>
      <td>Two</td>
      <td><button onClick="alert('two')">Ouch!</td>
    </tr>
    <tr>
      <td>Three</td>
      <td><button onClick="alert('three')">Ouch!</td>
    </tr>
  </table>
</label>

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

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

• אין טעם לבנות עכשיו אפליקציית React Native, כי בניתי כבר את ה Hello World שלהם ואני מבין את התיאוריה.

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

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

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

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

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

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

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

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

וכשאנחנו שומעים שהגיע הזמן להפוך את התפקידים אנחנו מתחילים לפחד-

1. ואם לא אמצא את הזמן ללמוד?

2. ואם לא יהיו לי פרויקטים מעניינים לכתוב?

3. ואם לא תהיה לי מספיק מוטיבציה?

4. ואם אני לא הבן אדם שיודע להוביל תהליך לימודי?

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

וכן, בדיוק בגלל זה אתם צריכים להצטרף.

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

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

כי חוץ ממנו יש את הקוד שאנחנו כותבים כדי ללמוד:

1. את הקוד שראיתי בוידאו ואני מקליד כדי לראות איך זה עובד.

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

3. את הקוד בשביל לפתור חידת תכנות שמצאתי.

4. את הקוד שאני כותב כדי לענות על שאלה של תלמיד, או של מישהו אקראי מ Stack Overflow.

5. את הקוד שאני כותב כדי ללמוד שפת תכנות חדשה.

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

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

לפעמים התשובה הטובה ביותר תהיה בתוצאה הראשונה בגוגל. לפעמים היא תהיה ב Stack Overflow. לפעמים היא תהיה באיזה בלוג פוסט של בלוגר מפורסם ולפעמים בפוסט של בלוגר שאף פעם לא שמעתם עליו.

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

1. לפעמים באמת התשובה הטובה ביותר היא לא התוצאה הראשונה. וזה קורה לעתים יותר קרובות ממה שהייתם מדמיינים.

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

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

אחד הרעיונות שלקח לי המון זמן להבין ב git אבל אחרי שהבנתי שינה לגמרי את כל מה שעשיתי הוא הכלל הבא:

קומיטים הם לנצח, בראנצ'ים הם רק מדבקות

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

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

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

$ git log --oneline
4980b49 (HEAD -> master) initial commit

$ git commit --amend -m 'initial commit - take 2'
$ git log --oneline
392bc0d (HEAD -> master) initial commit - take 2

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

$ git log --oneline 4980b49
4980b49 initial commit

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

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

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

$ git switch -c history 4980b49
$ git log --oneline
4980b49 (HEAD -> history) initial commit

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

$ git branch -f master history
$ git switch master
$ git branch -f history 392bc0d

והנה הסיפורים אחרי השינוי:

$ git log --oneline history
392bc0d (history) initial commit - take 2

$ git log --oneline master
4980b49 (HEAD -> master) initial commit

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

הפעלתי היום npm run eject בתוך יישום שנוצר עם create-react-app וקיבלתי קובץ וובפאק של 669 שורות ועוד 6 קבצי הגדרות קטנים יותר.

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

אז מה קיבלנו שם אתם שואלים? סקירה זריזה של הדברים שקפצו לי לעין:

1. קובץ manifest.json שממש יעזור לכם אם השרת שלכם צריך לבנות דינמית את ה HTML ולשתול בו בצורה דינמית את קבצי הסקריפט (אה, אתם מגישים קובץ HTML סטטי? תמשיכו ללכת אתם לא צריכים את זה).

2. הגדרות אליאס לריאקט נייטיב (אה, אתם לא כותבים ריאקט נייטיב? לא משנה, שיהיה לכם)

3. מנגנון שגורם ל webpack לא לטעון קבצי locale גדולים מספריית moment.js (חשוב, מה אתם לא משתמשים ב moment.js?).

4. מנגנון file-loader שמאפשר לנו לבצע import לקבצים רגילים מתוך קוד ה js שלנו כדי לקבל את שם הקובץ (למשל בשביל לשלב תמונות בתוך javascript).

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

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

בשני החלקים הקודמים למדנו איך לצמצם Boilerplate ביישום Redux באמצעות טיפול ב Action Creators וב Reducer. היום אני רוצה לדבר על הקומפוננטות ולהראות איך לכתוב הרבה פחות קוד בתוך קומפוננטה שמחוברת ל Redux ועדיין לקבל בדיוק את אותה תוצאה.