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

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

1. מה בדיוק לא עובד להם?

2. החל מאיזו גירסה של הקוד הדבר שהם מנסים לא עבד?

3. האם יש הודעת שגיאה באחד הלוגים?

4. האם משהו (חוץ מהקוד) השתנה על השרת?

5. מה הלקוח רואה אצלו על המכונה?

6. האם יש הודעות שגיאה ב Browser Console אצל הלקוח?

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

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

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

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

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

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

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

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

1. לשים לב שיש בעיה.

2. למצוא מלא פיתרונות שלא עובדים.

3. למצוא פיתרון שעובד.

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

5. להסביר את מה שגיליתם לאדם אחר (או לכתוב לעצמכם).

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

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

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

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

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

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

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

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

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

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

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

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

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

מהפיכה היא גם מה שקרה (בקנה מידה קטן בהרבה) כש Swift ו Kotlin החליפו את Objective C ו Java בתור שפות התכנות המרכזיות למכשירי אייפון ואנדרואיד. השפות החדשות פתחו את הדלת למפתחים חדשים להיכנס, והניסיון של המפתחים הוותיקים נראה פתאום פחות מרשים.

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

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

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

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

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

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

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

חבר שלח לי לינק לספריית Server Side Rendering חדשה בשם iSSR. בתוך הדוגמה בתיעוד אנחנו מוצאים את השורה הבאה:

const { html, state } = await serverRender(() => <App />);

אבל בשום מקום באותו דף תיעוד לא מופיעה המילה cache. זה אומר שאם אני לא יודע כלום על Server Side Rendering ורק קורא את התיעוד של הספריה, יש סיכוי טוב שאצליח לבנות קוד SSR בעזרתה אבל כשהקוד הזה יגיע למשתמשים אמיתיים השרת ייפול מהעומס.

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

1. מה עולם התוכן הרלוונטי של הספריה הזו?

2. איזה ספריות אחרות אני מכיר שפותרות את אותה בעיה?

3. מה הבעיות הכי נפוצות בשימוש בספריות מהסוג הזה?

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

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

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

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

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

עכשיו בואו נדבר על כסף.

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

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