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

גיקטיים פירסמו רשימה של שפות הפיתוח הכי מבוקשות. לא מפתיע למצוא שם את 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, לזהות תהליכי עבודה שאפשר לשפר ולהציע לשפר אותם. ככל שתצליחו ליצור תרבות של שיפור בתוך הצוות כך רמת המיומנות של כולם תעלה.

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

הנה הרשימה שלי (החל מהמשמעותי ביותר ובסדר חשיבות יורד):

1. לעבוד עם אנשים טובים וללמוד מהם.

2. לעבוד בסביבה עם תהליכי פיתוח טובים.

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

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

5. לפתור אתגרים מעניינים.

6. ללמוד שפת תכנות חדשה או פריימוורק חדש (כי אולי דרכם אני אקבל רעיונות לשיטות חשיבה חדשות).

7. להקשיב להרצאות מקצועיות או לקרוא ספרות מקצועית.

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

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

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

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

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

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

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

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

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

export default function App() {
  const [data, setData] = React.useState();

  function handleClick() {
    setData({ value: _.random(10) });
  }

  return (
    <div className="App">
      {data && <p>Value is: {data.value}</p>}
      <button onClick={handleClick}>Randomize</button>
    </div>
  );
}

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

export default function App() {
  const [data, setData] = React.useState();

  function handleClick() {
    setData(_.random(10));
  }

  return (
    <div className="App">
      {data && <p>Value is: {data}</p>}
      <button onClick={handleClick}>Randomize</button>
    </div>
  );
}

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

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

export default function App() {
  const [data, setData] = React.useState<Record<string, any> | undefined>();

  function handleClick() {
    setData({ value: _.random(10) });
  }

  return (
    <div className="App">
      {data && <p>Value is: {data.value}</p>}
      <button onClick={handleClick}>Randomize</button>
    </div>
  );
}

את xpath אני מכיר הרבה זמן אבל רק היום גיליתי שיש לו מקבילה וותיקה שתעזור לנו למשוך מידע בקלות מאוביקטי JSON. זה נקרא jsonptr וכבר יש עבורו מסמך איפיון של IETF שנקרא rfc6901 ומספר מימושים ב JavaScript ובשפות אחרות. בואו נראה איך זה עובד.

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

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

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

import getConfig from 'next/config'
import Image from 'next/image'

// Only holds serverRuntimeConfig and publicRuntimeConfig
const { serverRuntimeConfig, publicRuntimeConfig } = getConfig()
// Will only be available on the server-side
console.log(serverRuntimeConfig.mySecret)
// Will be available on both server-side and client-side
console.log(publicRuntimeConfig.staticFolder)

function MyImage() {
  return (
    <div>
      <Image
        src={`${publicRuntimeConfig.staticFolder}/logo.png`}
        alt="logo"
        layout="fill"
      />
    </div>
  )
}

export default MyImage

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

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

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

לאחרונה התחלתי לעבוד יותר ב knex.js בסביבת Node ובינתיים מאוד נהנה מהספריה והיכולות שלה. קנקס היא בעצם בונה שאילתות, קצת דומה ל Sequelize, רק שבמקום מבנה של ORM קנקס אימצה גישה יותר פתוחה ויותר קרובה ל SQL. הם לא מנסים להסתיר מכם את העובדה שאתם עובדים ב SQL, אלא לתת תחביר JavaScript קצת יותר גמיש במקום התחביר הטקסטואלי של SQL.

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

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