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

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

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

2. אין טעם לכתוב הערה כדי להסביר פיצ'רים של השפה.

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

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

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

6. אין טעם לכתוב הערה בשביל לספר סיפור רקע על הפיצ'ר או להסביר על מקרה קצה מסוים שהקוד מטפל בו (עדיף לכתוב הודעת קומיט טובה).

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

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

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

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

זאת הסיבה שכולם מתחילים דואולינגו אבל אף אחד לא מתמיד מספיק בשביל ללמוד שפה חדשה.

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

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

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

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

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

שיר? ברור שיהיה מה לזמזם בפעם הבאה שאין לכם כח ללכת לחדר כושר:

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

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

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

כי הנה שתי אמיתות-

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

2. מתכנתים טובים באים בהרבה מאוד גוונים.

הנה גישה אחת שעובדת הרבה יותר טוב:

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

או נסו את זה:

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

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

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

For any meaningful application, putting all your update logic into a single reducer function is quickly going to become unmaintainable.

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

אבל הניואנס במשפט שקל לפספס אותו הוא שיש יותר מדרך אחת לפצל Reducer. השיטה הפופולרית של combineReducers (שנקראת בתיעוד Slice Reducer) היא רק אחת מהן.

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

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

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

הראשונה היא לבצע 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 או בכל נושא אחר שתלמדו.