ToCode

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

# לכתוב או לא לכתוב הערות בקוד? מתכנתים משתמשים בהערות בקוד כדי לעשות המון המון דברים שרק חלק קטן מהם באמת עוזר לקוד להיראות טוב יותר. הנה כמה כללי אצבע שעוזרים לי: 1. אין טעם לכתוב הערה כשאפשר לשנות שם של משתנה או פונקציה והקוד יהפוך לברור יותר. עדיף לשנות את השם. 2. אין טעם לכתוב הערה כדי להסביר פיצ'רים של השפה. 3. אין טעם לשים קטעי קוד ארוכים בהערה רק בשביל שאולי נצטרך אותם בעתיד (עדיף ללמוד להשתמש בגיט). 4. בהרבה שפות יש הפרדה בין תיעוד ל API לבין הערות בגוף הקוד. את תיעוד הממשק אנחנו בדרך כלל נכתוב הרבה יותר מסודר עם הסבר על כל פרמטר, ערכי החזר ודוגמאות שימוש. גם בשפות שאין הפרדה רשמית משתמשים בדרך כלל בשיטת כתיבה אחרת לתיעוד API לעומת הערות בגוף הקוד. 5. אין טעם לכתוב הערה אם אפשר להוציא קטע קוד לפונקציה ולתת לה שם מסודר. עדיף להוציא לפונקציה. 7. אין טעם לכתוב הערה בשביל לספר סיפור רקע על הפיצ'ר או להסביר על מקרה קצה מסוים שהקוד מטפל בו (עדיף לכתוב הודעת קומיט טובה). 8. כדאי לכתוב הערה בגוף הקוד כשאתם עושים משהו לא הגיוני אבל בכוונה. משהו שיעזור לכם להיזכר בעוד חודש כשתגיעו לקוד הזה מה עבר לכם בראש. אז לכתוב או לא לכתוב הערות בקוד? האמת שהערות בקוד הן מנגנון די גרוע לשמור ידע. גיט או ויקי עוברים הרבה יותר טוב. הן גם מנגנון די גרוע לשמור היסטוריה של קוד (שוב, גיט עובד הרבה יותר טוב). הערות כן עובדות כדי לכתוב אזהרות ("קובץ זה מיוצר באופן אוטומטי אל תגעו בו", או "אל תשכחו לעשות ריסטרט לשרת אחרי שינוי בקובץ זה") או בשביל להסביר שטויות שעשיתם בכוונה בשורה מסוימת. ברוב המקרים עדיף לארגן מחדש את הקוד כך שיהיה יותר ברור גם בלי ההערה.

# שלום עולם Linux אחרי כמעט עשר שנים באקוסיסטם של אפל חזרתי הבוקר ל Linux. אלה הסיבות העיקריות למעבר וכמה טיפים למהגרים נוספים. ## מק ואני את המק הראשון קניתי ב 2011 בעיקר מתוך אילוץ. תכננתי לכתוב אפליקציות לאייפון ובשביל זה היית צריך מק. אחרי כמה אפליקציות שכתבתי הבנתי שאיחרתי את הרכבת ושהיה הרבה יותר קל להתעשר מכתיבת אפליקציות אם הייתי מתחיל שנתיים קודם, אבל כן הספקתי להתאהב במקבוק פרו שקניתי (מחשב שעדיין נמצא בשימוש כאן כמחשב ביתי). הבעיה היחידה עם המקבוק פרו הישן היתה האיטיות. למחשב לא היה SSD וכל פעם שהיית פותח את המסך היה צריך לחכות לא מעט עד שיכול להתחיל לעבוד. כשאפל הכריזו על ה Air מיהרתי לעבור אליו בהחלטה שהתגלתה כמאוד מוצלחת. האייר היה זריז, קל, נדלק מהר ולקח כמה שנים עד שהתחלתי להרגיש את המפרט החלש שלו. ב 2016 נפרדתי מהאייר לטובת מקבוק פרו נוסף אבל הפעם אחרי שידרוג הסידרה. המחשב הרגיש יותר מהפרו הקודם שהיה לי, עם מפרט חזק ודיסק SSD. אבל מהר מאוד היה ברור שמדובר בדגם לא בשל. המקלדת התקלקלה לעתים קרובות, המחשב עשה ריסטרט בצורה אקראית או התחמם יותר מדי ובאופן כללי היה קשה לעבוד עליו. במקביל אפל הבינה שכמה שיותר סגור זה גם יותר ריווחי אז היא מכרה מתאמים במחירים מופקעים ומדי פעם גרמה למחשב להתעלם ממתאמים זולים יותר של חברות אחרות, ושינתה את מערכת ההפעלה כדי לדחוף מפתחים לתוך ה App Store שלה מה שחיסל הרבה מפתחים קטנים. הטריגר הסופי לפרידה היה עוד כפתור שהתקלקל במקלדת יחד עם אחד מה USB Ports. במקום לשים את המחשב שוב בתיקון נפרדנו כידידים ועברתי ל Dell. ## היום הראשון עם Linux התקנת Ubuntu על ה XPS 13 עברה חלק ומסתבר שלינוקס עדיין מרגישה כמו בית גם אחרי תשע שנים. התוכנות המרכזיות שהספקתי כבר להתקין כוללות: 1. אימקס ו Vim (יחד עם כל קבצי ההגדרות הישנים שלי) 2. תוכנה בשם אלברט שהיא גירסת לינוקס של Alfred המקינטושאי 3. ספוטיפיי, טלגרם וווטסאפ כמובן 4. מדמה מסוף בשם Terminator 5. גיט, רובי, נוד ושאר כלי פיתוח אובונטו לא יפה כמו מק והייתי שמח אם היתה אינטגרציה יותר חזקה בין יישומים על שולחן העבודה אבל באיזון הכללי של החיים היא מנצחת בזכות יכולת ההתאמה והשליטה על המחשב. אם יש לכם טיפים או המלצות לתוכנות שאפשר לקחת מהמק ללינוקס או דברים אחרים בלינוקס שאתם אוהבים אשמח לשמוע בתגובות.

# השוק מוצף אבל אין הרבה טובים רוב הסיכויים שהגישה ״השוק מוצף אבל אין הרבה טובים״ לא תעזור לכם לגייס את האנשים הטובים שאתם צריכים. כי אם אתם לא יודעים מה אתם מחפשים הסיכוי שתמצאו אותו לא גבוה. מיהם הטובים האלה שאתם מחפשים? מה יש להם? האם אלה אנשים מנוסים? אנשים עם קליטה מהירה במיוחד? אנשים שיודעים לפתור בעיות? אנשים שיודעים להבין את הניואנסים של השפה? אנשים שירוצו מהר וישברו דברים תוך כדי, או אנשים שעובדים יסודי ויבנו מערכות יציבות אבל לאט? אנשים שקוראים את הספרים הנכונים? ששומעים את ההרצאות והפודקסטים הנכונים? שהולכים למיטאפים הנכונים? מי הם אותם מתכנתים טובים שאתם מחפשים? כי הנה שתי אמיתות- 1. כשאתם מתעקשים על אנשים "מסוג מסוים" שאתם תזהו כשתראו אותם, אתם מפספסים המון אנשים שלא עוברים את הפילטר אבל דווקא היו יכולים מאוד לתרום לחברה שלכם. 2. מתכנתים טובים באים בהרבה מאוד גוונים. הנה גישה אחת שעובדת הרבה יותר טוב: > אנחנו מחפשים מתכנת Front End שידע לקחת את המערכת שלי שנראית די רע ולהפוך אותה למשהו שנראה מדהים. המערכת כתובה ב React ולכן צריך מישהו שירגיש בנוח עם הפריימוורק, אבל אין צורך בעבודת ארכיטקטורה מורכבת. כן צריך היכרות טובה עם CSS והתאמה לכמה שיותר מכשירים. נשמח לראות תיק עבודות ולשמוע סיפורים על עבודות דומות שעשית. או נסו את זה: > אנחנו בונים מחדש את כל ה Front End של המערכת ומחפשים ארכיטקטית שתעזור לנו לבחור את הטכנולוגיה הטובה ביותר לצוות ולבנות את התשתית ממנה אנשים יוכלו להמשיך ולבנות את המסכים הספציפיים. האנשים שבונים את המסכים הם לרוב אנשי Back End ולכן התשתית צריכה להיות ידידותית ולא להכריח אותם להכיר יותר מדי מעולם התוכן של ה Front. לפני הראיון מבקשים לדבר עם מעסיקים קודמים כדי להבין איזה סוגי תשתיות בנית ולוודא שיש לך ניסיון מוכח בפרויקטים דומים לשלנו. השוק מוצף באנשים טובים - וכשתתחילו לספר מה אתם באמת צריכים הם גם ישמחו להגיע.

# קוד ריוויו לבד הנה שתי טכניקות פשוטוץ שאתם יכולים לנסות לבד בבית כדי להשתפר בנושאי עיצוב תוכנה, ארכיטקטורה והבנה של מערכות: הראשונה היא לבצע 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. נסו לחשוב - מה קורה כאן? איפה הקוד הלא הגיוני? והאם הקוד עובד? ## הסבר - מה קורה בקוד הדבר הלא הגיוני בקוד הזה הוא כמובן האלמנט label שעוטף את הטבלה. אף אחד לא עוטף טבלאות עם label ולכן זה הדבר הראשון שקופץ לעין כשקוראים את הקוד. לגבי התוצאה עם עיניים חדות אפשר לראות שכשאני לוחץ על כל אחד מהכפתורים גם הכפתור הראשון נלחץ. אבל מבחינת מה שקורה על המסך עדיין כל כפתור מציג את ה alert שלו בלבד. עד ש... ## בעיטה קטנה כדי לשבור את הכל עד שמנסים ללחוץ מסביב לכפתורים, למשל על תא שאין בו כפתור או על הטבלא עצמה. אז מגלים שלחיצות על הטבלא הופכות אוטומטית ללחיצות על הכפתור הראשון. במבט ראשון על הבאג לא לגמרי ברור שהוא קשור ל Label. התופעה המתוארת היא טבלא עם כפתורים שכל כפתור עושה את העבודה שלו, ובנוסף בצורה שנראית אקראית הכפתור הראשון נלחץ. זה יכול לקחת זמן בכלל להבין את הקשר בין מיקום הלחיצה לאירוע של לחיצה על הכפתור הראשון, ועוד יותר זמן לחבר את כל זה לאלמנט ה label שיושב שם (במיוחד אם הטבלא בנויה מכמה קבצים באיזושהי שפת Templates). ## הגירסא ההגיונית ובחזרה לפתיחה: אפשר לכתוב קוד לא הגיוני שעובד, אבל כשאתם רואים התנהגות לא הגיונית ולא מבינים מה גורם לה, כדאי להתחיל מלחפש את הקוד הלא הגיוני במערכת שלכם.

# אני מבין את התיאוריה אחד המשפטים שהכי מקלקל חווית למידה הוא ״אני מבין איך זה עובד בתיאוריה״: - אין טעם לבנות עכשיו אפליקציית React Native, כי בניתי כבר את ה Hello World שלהם ואני מבין את התיאוריה. - אין טעם לבנות פרויקט אמיתי בארדווינו, כי בניתי כבר משהו עם מנורות אז אני מבין איך זה עובד. - אין טעם לשבור את הראש על אפליקציית Full Stack גדולה, כי אני יודע את התיאוריה ואוכל לבנות אחת כשאצטרך. זה גרוע מכמה סיבות: קודם כל כי אתה לא באמת יודע איך זה עובד עד שלא בנית את זה, ודברים שאולי נראים נכון בתיאוריה הולכים להישבר לרסיסים קטנים כשיתקלו בטירוף של העולם האמיתי. בעיה שניה היא שהזדמנויות לא מגיעות לאנשים נחמדים שיודעים את התיאוריה. הזדמנויות טובות מגיעות למי שמגיע עם קבלות והקבלה הכי טובה היא פרויקט שעובד. ואולי הכי גרוע ב״אני מבין את התיאוריה״ זה שהוא מוציא את החשק לעבוד. אוקיי אני יודע את האותיות ואני יודע לחפש במילון, אז אני מבין את התיאוריה של קריאה ולכן אין טעם לקרוא ספר, זה קו מחשבה שלא יביא אתכם למיומנות גבוהה בקריאת ספרים. אני מבין שאתם מבינים את התיאוריה. עכשיו בואו נתחיל לעבוד על החלק המשעמם (וכנראה הכי חשוב בסיפור) ונשב לכתוב קוד.

# זה מוצר אחר, לאנשים אחרים. אחת השאלות שעולות לגבי מסלול הבוטקמפ היא איך זה תכל'ס עובד. השאלה הזאת באה הרבה פעמים מאנשים שרגילים למבנה מסוים של קורס: מרצה מדבר, תלמיד מקשיב. קורס הוא מקום אליו אתה בא כדי לקבל ידע, והמרצה עובד כדי שתקבל את הידע. אנחנו רוצים לשבת בשקט ולהקשיב. אחת ההערות שחוזרת על עצמה שוב ושוב במשובים היא שכשמגיעים מוכנים למפגשים אז לומדים המון, אבל אם מגיעים לא מוכנים אז קשה לעמוד בקצב. וזה נכון ומפתיע להיכנס לסביבה שבה התלמיד הוא שמוביל את התהליך, שבה הקורס הוא הזדמנות שאתה יכול להצליח בו, ולא משהו "שצריך" לעשות. וכשאנחנו שומעים שהגיע הזמן להפוך את התפקידים אנחנו מתחילים לפחד- 1. ואם לא אמצא את הזמן ללמוד? 2. ואם לא יהיו לי פרויקטים מעניינים לכתוב? 3. ואם לא תהיה לי מספיק מוטיבציה? 4. ואם אני לא הבן אדם שיודע להוביל תהליך לימודי? והפחדים הם נכונים. אף אחד לא למד ככה בגן, בבית ספר או באוניברסיטה. אנחנו לא רגילים. השתתפות בבוטקמפ דורשת סט מיומנויות שלמעטים יש. וכן, בדיוק בגלל זה אתם צריכים להצטרף. להצטרף ולבחור ללמוד. לבחור להיות הבן אדם שמבקש עוד רעיונות לפרויקט. לבחור להיות הבן אדם ששואל שאלות, שלומד נושאים שמעבר לסילבוס, שלוקח אחריות על לבנות את הפרויקט שמעניין אותו או אותה. וזה בעצם חשוב לא פחות מהידע הטכני ב Python או בכל נושא אחר שתלמדו.