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

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

כמתכנתי Full Stack, חודש עבודה על באג נשמע לנו נצח. התרבות וכלי העבודה מעודדים את קצב הפיתוח הכי מהיר שאפשר ולפעמים יותר מהיר. הפיתרון הנפוץ לבעיות הוא חיפוש הודעת השגיאה ב Stack Overflow. הפיתרון הנפוץ לבניית רכיב ממשק חדש הוא חיפוש אחר החבילה החופשית שכבר מספקת את הרכיב הזה, ואפילו כשכבר כן יושבים לכתוב לבד קוד כלי הפיתוח שלנו הופכים את החוויה למיידית: שנו CSS ותראו את התוצאה מיד בדפדפן; עדכנו קוד JS ותראו את התוצאה ב HMR אפילו בלי לטעון מחדש את העמוד.

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

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

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

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

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

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

כשרק התחיל כל ה ES6 ולמדתי על לולאת for..of החדשה כתבתי הרבה פעמים קוד שנראה כך:

const data = [10, 20, 30];

for (const x of data) {
    console.log(x);
}

שימו לב לשימוש ב const בעת הגדרת משתנה הלולאה.

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

אז אם גם אתם מעדיפים תמיד const על פני let תשמחו לגלות עוד מקום בו const עובד.

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

כי הקוד כבר כתוב.

כי אין תשתית והקוד לא מתאים לבדיקות.

כי יש משימות יותר דחופות.

כי מי בכלל יודע איך להריץ בדיקות או להקים CI.

כי אני לא יודע מאיפה להתחיל.

השבוע אני וגאבור נדבר על בדיקות בסידרת Code Maven שלו במטרה לעזור לכם להתגבר בדיוק על המכשולים האלה. אנחנו ניקח פרויקט קוד פתוח בשם kutt שזה פרויקט React/TypeScript/Node.JS שמקצר כתובות רשת (נו כמו tinyurl), ואין בו אף בדיקת Front End. בוובינר אני אראה לגאבור ולכם מאיפה להתחיל לכתוב בדיקות Front End, איך לכתוב את הבדיקה הראשונה ואיך להתחיל לבדוק דברים יותר מעניינים.

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

זה הקישור לפרויקט אחרי שהתקנתי עליו את כל הספריות איתן נעבוד: https://github.com/ynonp/kutt

וזה דף הרישום למי שרוצה להצטרף אלינו ביום חמישי ב 14:00 בצהריים: https://www.meetup.com/Code-Mavens/events/276792452/

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

ועכשיו הגיוני לשאול: לאן ממשיכים? מה הצעד הבא?

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

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

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

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

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

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

נתונה הפונקציה ב TypeScript:

export const generateId = async (domain_id = null) => {
  const address = generate(
    "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890",
    env.LINK_LENGTH
  );
  const link = await query.link.find({ address, domain_id });
  if (!link) return address;
  return generateId(domain_id);
};

1. מה הפונקציה עושה?

2. האם יש בעיה בקוד?

3. האם הבעיה צפויה לגרום לנזק בעולם האמיתי?

4. מה הייתם עושים אחרת?

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

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

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

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

def fib(n):
    if n <= 1:
        return 1

    return fib(n-1) + fib(n-2)

"אין בזה שום הגיון" הם יגידו. הרי המימוש האיטרטיבי משמעותית יותר יעיל:

def fib(n):
    x, y = 1, 1
    for i in range(n):
        x, y = y, x + y

    return x

אותה תוצאה, אותו אורך של קוד והרבה פחות חישובים.

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

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

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

גיקטיים פירסמו רשימה של שפות הפיתוח הכי מבוקשות. לא מפתיע למצוא שם את JavaScript, פייתון, Java, Node.JS ואפילו C++.

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

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

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

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

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

עכשיו בואו נדבר על המעבר בין המשרות:

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

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

3. אפשר לעשות את השינוי מבפנים, אבל זה די קשה - כשמופעל עליכם לחץ לבנות יותר פיצ'רים ממה שבכלל אפשרי להספיק ביום, כשהכלים פועלים נגדכם וכשכל דבר שאתם עושים נמדד, זה די קשה להתחיל להכניס פרקטיקות של בדיקות אוטומטיות, Code Reviews, Pair Programming, הרצאות העשרה, תרבות של Refactoring וכלי ניהול גירסאות טובים יותר. בטווח הרחוק כלים אלה ישפרו את הפרודוקטיביות ויחסכו לכם זמן זה נכון, אבל כרגע יש יותר מדי שריפות מכל הכיוונים.

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

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

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

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

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

1. כמה הערות כותבים בקוד (וכמה מידע נשמר בהודעת קומיט בגיט)

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

3. בכמה מקרי קצה צריך לטפל? ובאיזה?

4. לאיזה שינויים עתידיים צריך להיערך? ולאיזה לא?

5. מה הדרישה מבחינת ביצועים של הפיצ'ר שאני עכשיו כותב?

6. איך אני מצפה שיראה האיפיון שאני מקבל לפני שאני יכול להתחיל לעבוד?

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

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

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

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

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

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