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

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

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

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

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

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

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

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

1. קודם כל Best Practices. האנשים שקוראים את הקוד שלכם מצפים לסטנדרט מסוים אבל בגלל שזו משימת בית אין לכם מושג מהו, לכן כדאי לקרוא את מסמכי ה Best Practices המקובלים בעולם שלכם (לדוגמא PEP8 בפייתון) ולפעול כמה שיותר במדויק על פיהם.

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

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

4. כדאי להיזהר מ Over Engineering. לכתוב עשרות קלאסים וירושות בשביל משימה קטנה כנראה ישאיר רושם שאתם אנשים שאוהבים לסבך דברים.

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

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

בהצלחה!

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

כמה זמן צריך בשביל לבנות תיק עבודות טוב?

כמה זמן לוקח לבנות אפליקציית מובייל שתקבל חשיפה טובה ותפתח לכם דלתות?

כמה זמן לוקח ללמוד משהו מספיק לעומק כדי לעבור ראיון עבודה?

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

כמה זמן לוקח עד שמישהו ימליץ עליך לחבר?

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

כמה זמן לוקח עד שהפרויקט הקטן שלך יתחיל להכניס כסף?

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

כמה זמן לוקח לבנות קורס אונליין טוב?

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

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

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

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

You can turn Fraudulent Website Warning off (in Settings > Safari) as long as you're willing to accept less vigilance against sketchy pages. The issue is really that Apple activates the feature by default without alerting users, and that it doesn't specify just where Tencent operates

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

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

נ.ב. לינק לאחד המקורות בנושא (מאמר של מאת'יו גרין): https://blog.cryptographyengineering.com/2019/10/13/dear-apple-safe-browsing-might-not-be-that-safe/.

״שנה שלמה למדתי בשביל העבודה הזאת. היה ממש קשה אבל אני שמחה שהתמדתי - יש לי היום עבודה טובה ששווה את המאמץ״.

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

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

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

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

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

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

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

לשאלות המעניינות שנרצה לשאול את האינטרנט התשובה ממילא מורכבת ואנחנו לא רוצים המלצה כמו "תמיד תבחרו X" או "תמיד תבחרו Y". המטרה בחיפוש היא לקבל כיווני מחשבה וקריטריונים להשוואה כדי שתוכלו לבדוק בעצמכם בצורה יסודית ולבחור את הדבר שמתאים למערכת ול Use Case שלכם.

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

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

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

What is a closure, and how/why would you use one?

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

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

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

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

1. כן - אני מכיר את הטכנולוגיה, בניתי בזה מספר פרויקטים והנה לינקים או צילומי מסך מפרויקטים אלה.

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

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

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

אנשים פעם מאוד אהבו להכניס קבועים בכל מיני בסיסי ספירה לקוד התוכניות שלהם ולכן מתכנני שפות תכנות הכניסו תמיכה בכל מיני כתיבים שהיום עשויים להיראות קצת מוזרים. הבסיסים הפופולריים היו בסיס בינארי (בסיס 2), בסיס אוקטלי (בסיס 8) ובסיס הקסדצימלי (בסיס 16), וכמובן הבסיס הדצימלי הרגיל (בסיס 10).

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

x = 0b10
print(x) # prints 2

x = 011
print(x) # prints 9

x = 0x10
print(x) # prints 16

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

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

if (( $(date +%"H") < 20 ))

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

-bash: ((: 08: value too great for base (error token is "08")

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

if (( $(date +%"_H") < 20 ))

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