טיפים קצרים וחדשות למתכנתים
כבר מתחילת הדרך ריאקט סיפקה מנגנון לגישה ישירה ל DOM, למשל כדי לשלב קוד ריאקט עם קוד ישן שצריך גישה זו או כדי לטפל במצבים שריאקט לא הצליחה לטפל בהם באמצעות הכתיב הדקלרטיבי, המרכזי שבהם הוא ניהול פוקוס.
בואו נדבר קצת על ref ועל השינויים במנגנון שקרו בשנים האחרונות.
"עשית כבר שיעורי בית?" "מה עם העבודה שצריך להגיש למחר?" "את זוכרת שיש לך מבחן בשבוע הבא?" "מי לא הכין עדיין שיעורי בית?" "אין טלויזיה עד שלא תסיימי את כל השיעורים" "אם לא תסיים את השיעורים עד ארבע לא תלך לחוג"
משפטים אלה ורבים נוספים נאמרים כל יום בבתים רבים לילדים שיש להם המון חלומות, ושיעורי הבית אינם חלק מהחלומות האלה. אבל לא באתי לפה לספר לכם על החלומות של הילדים שלכם אלא על האחריות או יותר נכון חוסר האחריות שלהם.
כשאנחנו מזכירים בעדינות לגוזלים להכין את שיעורי הבית, אנחנו לא מאפשרים להם לקחת אחריות על הלמידה שלהם. אנחנו לא מאפשרים להם לטעות. אנחנו לא מאפשרים להם לנסות. הם יגיעו לכיתה עם שיעורי בית מוכנים אבל אם ישבתם להם על הווריד כמו שצריך אתם יודעים טוב שזה לא הגיע מהם. רוב הילדים מסיימים את בית הספר בלי שהיתה להם הזדמנות לקחת אחריות על הלמידה שלהם. בלי שהיתה להם הזדמנות לבחור ללמוד משהו, למצוא את הדרך, להתמיד בה, אולי להיכשל ולהתבלבל ואז לקום ולהמשיך עד שיודעים. המוטיבציה להמשיך תמיד הגיעה מבחוץ.
וכשאותם ילדים גדלים וצריכים ללמוד משהו חדש האינסטינקט הטבעי שלנו הוא לחפש את המסגרת. למצוא מישהו חיצוני שיסביר, שאני אוכל לשאול אותו שאלות, שיתעניין בי ובהתקדמות שלי ושישב לי על הווריד עד שאני אצליח. אנחנו מוכנים לשלם הרבה בשביל להעביר הלאה את האחריות על הלמידה שלנו.
גם כאן בטוקוד קל לראות את זה. יש את מי שרק רואה את סרטי הוידאו, אחרים גם מגישים תרגילים בפורום ומקשיבים להערות ומעטים ממש גם מגיבים על עבודות של אחרים ומנסים לעזור ולשפר. הבחירה לראות את סרטי הוידאו אחרי שקנית קורס אונליין היא קלה, זה יהיה טפשי לא לראות אותם. הבחירה גם לשבת ולפתור את התרגילים כשאף אחד לא יושב לך על הווריד היא כבר יותר קשה. והבחירה לעזור לאחרים מתוך הבנה שיש פה עוד הזדמנות ללמוד, בלי שאפילו ביקשו ממך, היא הקשה ביותר.
אז כן זה ברור למה אנחנו פוחדים מקורס אונליין. ביצוע תהליך לימודי במסגרת זמן קבועה עם לו"ז ידוע ומדריך שדואג שכולם יתקדמו לפי התוכנית דורש הרבה פחות אחריות. אם סיימתי קורס בג'ון ברייס ולא מצאתי עבודה אני יודע למי לבוא בטענות. המכללות השונות מעודדות את זה כשהרבה פעמים הן מבטיחות עבודה למסיימי הקורסים.
בקורס אונליין לעומת זאת אין תהליך. אתה יכול לראות את הוידאו, או לא. אתה יכול לפתור את התרגילים, או לא. אתה יכול ללמוד יותר מהר או יותר לאט, לעזור לאחרים או לבחור להסתתר. הקורס אונליין נותן לך הזדמנות - וזו האחריות שלך לנצל אותה כדי לעשות את המסע שיתאים לך.
שתי מסקנות מהסיפור הזה:
כדאי ללמוד לקחת אחריות על הלמידה שלכם. לא רק בגלל שזה יחסוך לכם כסף, אלא בעיקר בגלל שזה יותר יעיל. אתם יכולים לבחור ללמוד בדיוק את מה שאתם צריכים וליישם מיד על העולם שלכם, במקום להתאים את עצמכם לקצב שמישהו אחר קובע.
כדאי לזכור שהפחד הוא מוצדק, שבפעמים הראשונות שתיקחו קורס אונליין זה כנראה לא יצליח טוב כמו שתרצו ולהיות מודעים לסיבה לפער. אף אחד לא מוריד את גלגלי העזר מהאופניים ויש מתחיל לנסוע מהר. אבל מי שמוריד את גלגלי העזר ומוכן ליפול כמה פעמים ירוויח ובגדול.
נ.ב. להורים שיושבים על הילדים כדי שיכינו שיעורי בית ומחפשים דרך טובה יותר, זיכרו שאין דרכים קלות ואין פיתרון אחד שעובד לכולם. כן כדאי לשאוף ליצור בבית אווירה של הכנת שיעורי בית: לשאול את הילדים מתוך התעניינות אמיתית מה הם למדו, להראות להם את החומר מזוויות נוספות ואולי לשריין זמן לימוד משפחתי בו אתם לומדים והם מכינים את השיעורים. כדאי גם לתחום את הדברים בזמן כך שהילדים יתרגלו ששעה ביום מכינים שיעורים (או כמה שמתאים לכם ולהם). אבל הכי חשוב לזכור שזו אחריות שלהם והעברת אחריות זה משהו שלוקח זמן. בהינתן שתצליחו ליצור סביבה בה ברורים ה Benefits של הכנת שיעורי בית ובה הילדים מרגישים שהם מסוגלים להכין את השיעורים אתם יכולים לסמן וי כי עשיתם את שלכם. לא יודע אם הם ידעו חשבון בסוף אבל הם בטוח ידעו לקחת אחריות על הלמידה שלהם.
יש רק מטריקה אחת חשובה לאיכות הקוד שלכם- האם לאורך זמן, ככל שהמערכת גדלה ומסתבכת, נהיה לכם יותר קל או יותר קשה להוסיף פיצ'רים חדשים?
וכל השאר נגזר מזה.
לדוגמא אנחנו אוהבים למדוד כמה אחוז מהקוד מכוסה על ידי בדיקות אוטומטיות. כשרוב התרחישים נבדקים באופן אוטומטי יהיה לנו יותר קשה לשבור את מה שעובד בזמן שאנחנו כותבים מנגנונים חדשים, כי מהר מאוד נזהה מה נשבר ולמה. ככל שנכתוב יותר בדיקות כך פיתוח של פיצ'רים חדשים יהיה יותר מהיר.
והתובנה הבאמת מעניינת לקחת מכאן היא שזה עובד גם הפוך: אם אתם כותבים עוד ועוד בדיקות אוטומטיות (או מתאמצים להשיג כל מטריקה אחרת) וככל שאתם עובדים יותר כך המשך הפיתוח רק הופך לקשה יותר, אז המסקנה שאתם משפרים את המטריקה הלא נכונה.
כשאתם מגיעים להתראיין במקום חדש כדאי לזכור שבתרבות העבודה הנוכחית שלנו זה כנראה לא יהיה מקום העבודה האחרון שלכם. ואז השאלה הבאה שחייבים לשאול היא איך המקום שאני עכשיו מתראיין אליו ישפיע על הפעם הבאה בה אחפש עבודה.
יש מקומות שאחרי שנתיים בהם אתם תהפכו למוצר הכי מבוקש בשוק וכל החברות ירדפו אחריכם. ויש מקומות אחרים שאחרי שנתיים שם אף אחד לא ירצה להסתכל לכיוון שלכם לא כל שכן לגייס אתכם לעבודה. במילים אחרות כשאתם עובדים שנתיים במקום מסוים אתם סופגים חלק מהתרבות של המקום אליכם. ואחרי זה כשאתם ממשיכים הלאה הדברים שספגתם עשויים לעזור לכם לרוץ קדימה או להכביד עליכם עם כל צעד.
לכן נרצה לקבל מדד כלשהו לאיכות העבודה אליה אנחנו מתראיינים מתוך הבנה שעדיף להתפשר במשכורת ולהרוויח מקום איכותי מאשר לקבל משכורת קצת יותר גבוהה עכשיו אבל להיתקע עם הרגלים שאחרי זה קשה להיפטר מהם ומפריעים לכם להתקדם.
אז כמו שהבנתם מהכותרת הנה רשימה של 8 שאלות שאני הייתי שואל את המעסיק הפוטנציאלי:
האם כותבים טסטים? האם משתמשים במערכת CI/CD כלשהי?
האם משתמשים בכלי ניהול גירסאות (רצוי git) ?
האם יש תרבות של Code Reviews ? מי מבצע Code Reviews? ולמי? ובאיזו תדירות?
מה מדיניות החברה בנוגע להשתלמויות מקצועיות? האם יקנו עבורך קורס אונליין?
כמה זמן במהלך שבוע ממוצע מתכנתים בחברה משקיעים בלימוד? האם יש זמן מוקצב בלו״ז לדברים כאלה?
מה היחס לנושא נגישות?
מה היחס לאבטחת מידע? יש מי שבודק את הקוד לחולשות? איך התקשורת בין המתכנתים לאותם Pen Testers ? איך נושא אבטחת מידע משתלב בתהליך הפיתוח?
מה היחס שלהם לגבי זמן טעינת האתר? מה הגודל הכולל של האתר היום? האם יש ״תקציב״ ביצועים ויש מי שאחראי לאכוף אותו?
אף חברה לא תתן לכם את התשובות שהכי רציתם לשמוע על כל 8 השאלות, וזה בסדר. איספו את התשובות של 2-3 מקומות שאתם מתלבטים לגביהם ותקבלו עוד פרספקטיבה לגבי כמה מקום עבודה מסוים יתרום לקריירה שלכם.
ספריית Rails מגיעה עם מנגנון לבניה אוטומטית של טפסים חכמים. שני המנגנונים המרכזיים שטפסים אלה מייצרים הם הגנה מפני CSRF ויצירת שמות לשדות באופן אוטומטי. בניה של מנגנון דומה ב React תעזור לנו להבין את ה Context API של ריאקט וגם לקבל קוד נקי יותר.
אז אתם יודעים לכתוב תוכניות Express בנוד ואולי גם ראיתם איך נראה קוד של Middleware. אבל... מה אפשר לעשות עם זה? ולמה שתרצו לכתוב אחד לתוכנית שלכם? הנה כמה רעיונות.
אחד הפיצ'רים החדשים בריאקט 16 היה מנגנון טיפול בשגיאות חדש. בואו נראה למה היה צריך את השינוי ומה הרווחנו ממנו.
כשהקטנה שלי אומרת שסיימה לאכול אני תמיד מנסה עוד משהו - אולי תנסי עוד ביס מזה? אולי עוד עגבניה בזמן שאני מקריא סיפור? בטוחה שלא בא לך גם מלפפון?
אבל אם היא זורקת את האוכל על הריצפה מיד אני קופץ להסביר לה שאסור לזרוק אוכל על הריצפה ופעם הבאה אני אוריד אותה מהשולחן. לא עוברת שניה והיא כבר זורקת עוד ביס והנה הארוחה הסתיימה.
עבור בת שנתיים אצלנו במשפחה, לזרוק אוכל על הריצפה זה הדרך שלה לסמן שהיא שבעה. וזו דרך שעובדת. הרבה יותר טוב מאשר להגיד שהיא שבעה.
וגם אצלכם בצוות המתכנתים שאתכם והמנהלים שלכם יעדיפו להשתמש בסימנים שעבדו עבורם בעבר במקום להגיד את הדברים כמו שהם. אנחנו יכולים לראות מתכנת שהיה אחד המובילים והמרכזיים בפרויקט פתאום מתחיל לעבוד לאט וברישול. הוא לא יגיד שהוא שחוק חלילה, ובהחלט יכול להאשים את הסביבה או לתת הסברים מאוד משכנעים. הכל בשביל "שנרד" ממנו. ואם זה פרויקט קוד פתוח תראו אנשים שפשוט "נעלמים".
או מתכנתת שמרגישה שהעבודה קטנה עליה אז לאט לאט היא תתחיל להשקיע יותר בפרויקטי-צד, תלך ליותר מיטאפים ותחפש את הקידום המקצועי במקום אחר. זו התנהגות שבנסיבות מסוימות מנהלים תופסים כחיובית אבל המרחק בינה לבין עזיבה ומציאת מקום עבודה חדש הוא מאוד קצר.
אנשים לא אומרים את מה שהם מרגישים כי זה לא עובד, בדיוק כמו שאצלנו במשפחה לזרוק אוכל על הריצפה עובד הרבה יותר טוב מאשר להגיד "אני שבעה". כשאכפת לכם מהאנשים שאתם עובדים איתם אין ברירה אלא להתאמץ כדי להבין את הסימנים ולעזור להם להתמודד.
בעולם אידאלי אנשים היו יוצאים מבית ספר עם ידע, הרגלים ויכולת שיעזרו להם ללמוד דברים חדשים בכוחות עצמם. עד שזה יקרה ואם גם אתם בוגרים של מערכת החינוך כדאי לזכור שכל מה שלמדתם בבית ספר על למידה לא רלוונטי לחיים כמתכנתים שצריכים כל הזמן ללמוד טכנולוגיות חדשות.
שתי הבעיות המרכזיות שלא התמודדתם איתן בבית הספר היו בניית תוכנית הלימודים לעצמכם ויצירת הרגל של התמדה בלימוד גם כשקשה וגם כשלא מבינים.
השיטה שלי ללמוד טכנולוגיה חדשה מורכבת מ-4 מרכיבים. היא עובדת לכל טכנולוגיה וכוללת גם הערכות זמנים:
לוקח ספר או קורס אונליין כדי לקבל סילבוס ראשוני.
מתחיל לאפיין ולבנות פרויקט-צד בטכנולוגיה החדשה.
נכנס להרצאות מכנסים (ביוטיוב) ומקשיב לפודקסטים על הכלי או הטכנולוגיה.
מחפש אנשים שעובדים בטכנולוגיה כדי לראות את הבעיות שלהם ומנסה לפתור ולעזור.
לראשון אני מקציב חצי שעה ביום ועוד חצי שעה לשני. סך הכל שעה ביום זה המקסימום שאני מסוגל להשקיע בתחילת הדרך כשדברים מתסכלים ולא עובדים. לאט לאט ככל שאני מתקדם בלימוד אני מצליח להוסיף זמן לימוד.
החשיבות של הרצאות ביוטיוב היא שזה עוזר לכם להרגיש את הטכנולוגיה מנקודת מבט של אנשים שעובדים בה, ולראות את הבעיות הנוכחיות איתן אנשים מתמודדים (שכנראה שונות מאוד ממה שתקראו בספר או ממה שתמצאו בפיתוח פרויקט-צד קטן שלכם). לא צריך זמן לזה ואפשר לשלב כחלק מנסיעה לעבודה או בחדר כושר.
והחשיבות של לעזור לאנשים היא שזה עוזר לכם להיכנס לקבוצה של אנשים שמתעסקים בטכנולוגיה שאתם לומדים וחושף אתכם לעוד היבטים של העבודה איתה. בסעיף זה אני שם הליכה למיטאפים (והתנדבות להעביר הרצאה במיטאפ), מענה על שאלות בפורומים ואפילו כתיבת פוסטים על מה שלמדתם בבלוג. בחודש הראשון יהיה לכם קשה לעזור לאנשים אבל אחרי זה כדאי להקציב לזה לפחות שעתיים בשבוע.
דוגמא? דוגמא. שנה שעברה למדתי אליקסיר. התחלתי עם הטוטוריאל שכאן:
כדי לקבל ספר לימוד שאפשר להתקדם איתו חצי שעה ביום ולגבש רשימה של דברים שצריך לדעת.
בתור פרויקט לקחתי את Advent Of Code 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 שעשינו הצלחתי לבנות את הפיצ'ר החדש הזה כמעט בלי לשנות קוד קיים ובלי לשבור מנגנונים ישנים במערכת".
הפנס ביד שלכם. לכו להאיר על הדברים הנכונים.