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

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

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

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

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

1. האם כותבים טסטים? האם משתמשים במערכת CI/CD כלשהי?

2. האם משתמשים בכלי ניהול גירסאות (רצוי git) ?

3. האם יש תרבות של Code Reviews ? מי מבצע Code Reviews? ולמי? ובאיזו תדירות?

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

5. כמה זמן במהלך שבוע ממוצע מתכנתים בחברה משקיעים בלימוד? האם יש זמן מוקצב בלו״ז לדברים כאלה?

6. מה היחס לנושא נגישות?

7. מה היחס לאבטחת מידע? יש מי שבודק את הקוד לחולשות? איך התקשורת בין המתכנתים לאותם Pen Testers ? איך נושא אבטחת מידע משתלב בתהליך הפיתוח?

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

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

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

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

אחד הפיצ'רים החדשים בריאקט 16 היה מנגנון טיפול בשגיאות חדש. בואו נראה למה היה צריך את השינוי ומה הרווחנו ממנו.

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

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

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

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

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

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

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

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

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

1. לוקח ספר או קורס אונליין כדי לקבל סילבוס ראשוני.

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

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

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

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

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

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

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

https://elixirschool.com/

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

בתור פרויקט לקחתי את Advent Of Code 2017:

https://adventofcode.com/2017

ופתרתי את כל 24 המשימות משם בשפת Elixir.

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

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

https://www.tocode.co.il/blog/2018-02-elixir-tictactoe

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

https://github.com/ynonp/tocode_bot

עכשיו כל מה שנשאר זה להחליף את Elixir ב Go, Ruby, Python או כל שפה אחרת.

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

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

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

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

הפנס ביד שלכם. לכו להאיר על הדברים הנכונים.

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

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

<input type='text' required="required" />

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

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

https://caniuse.com/#feat=constraint-validation

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

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

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

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

בואו נראה מתי זה טוב ואיך בונים את זה בפייתון.

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

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

לא. שתי הגישות שגויות

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

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