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

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

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

מצד שני ברגע שלמדנו מבנה מסוים אנחנו יכולים להשתמש בו בשפות חדשות ככל שנלמד את המילים בהן. לכן תוכנית שמדפיסה את לוח הכפל תיראה מאוד דומה ב C, perl, ruby, python, JavaScript או כל שפה פרוצדורלית אחרת שתיקחו. ברגע שיש בשפה תמיכה בלולאות for עם משתנה רץ, יהיה לנו קל לבנות בה את לוח הכפל. וברגע שיש בשפה פונקציות אנחנו יכולים לבנות בה את הרקורסיה, גם אם התחביר של הגדרת פונקציה וקריאה לה יהיו שונים בין שפות.

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

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

"אני יודע את זה" הוא הרגע בו אפשר להפסיק לחפש ברשת כל מיני רעיונות יצירתיים איך להתמודד עם הבעיה ופשוט להתקדם עם הדבר שאנחנו יודעים עד שנגיע לפיתרון. אם מישהו יבקש ממני מחר למרכז div ב CSS, אני מתחיל עם "אני יודע את זה" ואז ממשיך ליצור את הפלקסבוקס ולמרכז את התוכן. גם אם חסר לי סינטקס, החיפוש ברשת כבר לא יהיה חיפוש כללי של "איך לכתוב תוכן באמצע העמוד באמצעות CSS" אלא משהו יותר ספציפי כמו "Flexbox reference" או אפילו "flexbox align items example".

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

והחלק הקשה? זה יהיה לזהות מתי "אני יודע את זה" יהפוך ל "הייתי בטוח שאני יודע את זה ועכשיו אני מבין שטעיתי בגדול".

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

רובי 3 יצא השבוע ואחד הפיצ'רים המלהיבים בו הוא התמיכה ב Type Hints. אבל כשנכנסים לפרטים מזהים ש:

1. התמיכה ב Type Hints היא בסך הכל שילוב כברירת מחדל של ספריה שכבר קיימת תקופה ארוכה שנקראת rbs.

2. התחביר של Type Hints מוכר כבר לכל מי שהיה בשיחה הזאת - והוא פשוט תחביר rbs.

3. ה Type Checker (נקרא steep) לא נכלל כחלק מרובי, אבל גם הוא כבר נמצא בפיתוח תקופה ארוכה ומתמודד מול Type Checker בתחביר אחר שנקרא Sorbet.

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

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

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

"אני לא רוצה לכתוב את זה ככה, כי פעם כתבתי משהו דומה לזה וזה נגמר רע"

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

"אולי עדיף לבנות Stored Procedure במקום לכתוב את השאילתה בקוד, כי במקרה דומה בו כתבתי את השאילתה בקוד הביצועים היו ממש גרועים"

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

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

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

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

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

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

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

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

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

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

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

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

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

הבעיה שלפעמים על הסיפור היפה הזה מתלבש החבר הפחות-יפה שלו, הסיפור על הפשרות הכואבות שצריך לעשות בדרך להצלחה:

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

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

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

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

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

"איך יכול להיות שלוקח לאנשים המוכשרים שלי כל כך הרבה זמן לפתור את זה? כל הקורס הם ככה?"

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

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

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

שתי מסקנות קלות לקחת מהסיפור:

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

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

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

function padded(num) {
  return num > 10 ? String(num) : '0' + num;
}

נו, מביך והכל אבל פה בבלוג מותר לדבר על הכל, אפילו על טעויות Off By One. קודם כל הבאג למי שלא ראה מיד קשור לסימן ה"גדול מ-" שהיה צריך להיות "גדול-שווה" או גדול מ-9. עשר הוא גם מספר דו-ספרתי.

אבל יותר מעניין - איך מונעים שטויות כאלה בעתיד? הנה שלושה רעיונות:

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

2. כיוון שני יהיה להשתמש בספריה חיצונית. במקרה של padded הספריה החיצונית אפילו די מפורסמת ונקראת left-pad. הקוד היה נראה כך:

impor leftPad from 'left-pad';

function padded(num) {
    return leftPad(String(num), 2, '0');
}

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

1. כיוון שלישי ספציפי למקרה הזה הוא להיזכר שאחרי הפארסה של left-pad כבר הוסיפו ל JavaScript את הפונקציונאליות והיום היה אפשר לכתוב את הקוד הזה:

function padded(num) {
    return String(num).padStart(2, '0');
}

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

function padded(num) {
    return ('0' + num).slice(-2);
}

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