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

המדד הכי גרוע לאיכות קוד הוא "עובד/לא עובד" ואני תמיד אעדיף קוד נכון שלא עובד על פני קוד עובד ולא נכון. ועם זה הלכתי לקשקש קצת עם JavaScript היום ובפרט עם testing-library. שימו לב לבדיקה הבאה שעוברת:

it('Increases after I click the button', async () => {
  const screen = render(Counter);
  const button = screen.getByRole('button', { name: 'Click Here' });
  await userEvent.click(button);

  expect(screen.getByText(/clicked 1 times/)).toBeTruthy();
});

זה קוד בדיקה למונה לחיצות שמוודא שאחרי שלחצתי על כפתור יופיע הטקסט clicked 1 times.

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

await userEvent.click(button);

זה רעיון יפה רק ש userEvent.click לא מחזיר Promise. קוד הבדיקה הבא (שגם עובד) הוא שקול לתוכנית הראשונה:

it('Increases after I click the button', async () => {
  const screen = render(Counter);
  const button = screen.getByRole('button', { name: 'Click Here' });
  userEvent.click(button);
  await undefined;

  expect(screen.getByText(/clicked 1 times/)).toBeTruthy();
});

אה וצריך לציין - אם מוחקים את שורת ה await ונשארים רק עם זה:

it('Increases after I click the button', async () => {
  const screen = render(Counter);
  const button = screen.getByRole('button', { name: 'Click Here' });
  userEvent.click(button);

  expect(screen.getByText(/clicked 1 times/)).toBeTruthy();
});

הבדיקה נכשלת.

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

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

it('Increases after I click the button', async () => {
  const screen = render(Counter);
  const button = screen.getByRole('button', { name: 'Click Here' });
  userEvent.click(button);

  expect(screen.findByText(/clicked 1 times/)).toBeTruthy();
});

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

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

התחושה השניה זה סיפור אחר - כשאין קליק לטכנולוגיה לוקח הרבה יותר זמן בכלל למצוא את הזמן כדי ללמוד אותה, וגם הלימוד הרבה פחות אפקטיבי. קצב ההתקדמות בטכנולוגיה כזאת יכול להיות איטי פי 2 או 3, ורק בגלל איזה רושם ראשוני או State Of Mind לא נכון.

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

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

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

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

אז חשבתי.

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

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

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

בתיאוריה, תרגום פרויקט מ Docker Compose ל Kubernetes הוא הדבר הכי קל בעולם: מפעילים סקריפט אחד שמתרגם את קבצי ה docker-compose.yml לקבצי ההגדרות של k8s, מעלים את התוצאה לקלאסטר קיים ונהנים מהחיים. המציאות לקחה לי קצת יותר עבודה ודרשה מספר שינויים בקוד המערכת - אבל בצד החיובי סיימתי עם קוד טוב יותר מזה שהיה בהתחלה וגם הבנה טובה יותר של הארכיטקטורה. מהתהליך גם למדתי לחבב מספר דברים בקוברנטס, והנה השלושה המרכזיים:

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

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

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

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

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

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

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

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

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

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

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

import _ from 'lodash';

export default class MemoryGame {
  constructor(size) {
    this.cards = _.shuffle(_.range(size).flatMap(i => [i, i]).map(i => ({ value: i, visible: false })));
    this.foundPairIndexes = new Set();
    this.activeCardIndex = -1;
    this.hideTimer = null;
  }

  play = (index) => {
    const card = this.cards[index];
    if (card.visible) {
      return;
    }

    card.visible = true;
    clearTimeout(this.hideTimer);
    this.hideTimer = null;

    if (this.activeCardIndex >= 0) {
      if (this.cards[this.activeCardIndex].value === card.value) {
        // Found a match
        this.foundPairIndexes.add(this.activeCardIndex);
        this.foundPairIndexes.add(index);
        this.activeCard = null;
      } else {
        this.hideTimer = setTimeout(this.hideAllCards.bind(this), 2000);
      }
    }
    this.activeCardIndex = index;
  }

  isVisible(index) {
    if (this.foundPairIndexes.has(index)) {
      return true;
    }

    return this.cards[index].visible;
  }

  hideAllCards() {
    this.cards.forEach(c => { c.visible = false; });
  }
}

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

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

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

  afterEach(function() {
    jest.useRealTimers();
  });

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

אחרי שיש לנו Fake Timers אנחנו יכולים להשתמש בפונקציה advanceTimersByTime של jest כדי לרוץ קדימה בזמן. הנה הבדיקה שמוודאת ששתי שניות אחרי שהפכנו שני קלפים לא תואמים הם יתהפכו חזרה:

it('Turns back the cards when pair is not found', () => {
  jest.useFakeTimers();
  const g = new MemoryGame(5);
  const i1 = 0;
  const i2 = g.cards.findIndex(c => c.value !== g.cards[0].value);

  g.play(i1);
  g.play(i2);
  expect(g.isVisible(0)).toBeTruthy();
  expect(g.isVisible(i2)).toBeTruthy();

  jest.advanceTimersByTime(2500);

  expect(g.isVisible(0)).toBeFalsy();
  expect(g.isVisible(i2)).toBeFalsy();
});

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

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

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

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

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

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

#!/bin/bash -e

for json_file in /data/*
do
  echo "Importing JSON file $json_file"
  python import_json.py "$json_file"
  echo "-- Done"
done

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

FileNotFoundError: [Errno 2] No such file or directory: '/data/*'

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

# this will print all the files in /etc
$ echo /etc/*

# but this will just print "/data/*"
$ echo /data/*

הפקודה הראשונה באמת תדפיס את כל הקבצים והתיקיות מתוך /etc, והשניה תדפיס פשוט /data/*. כמובן שהמחרוזת שהודפסה מהפקודה השניה אינה באמת שם קובץ ולכן אי אפשר לפתוח אותה.

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

$ shopt -s nullglob
$ echo /data/*

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

#!/bin/bash -e

shopt -s nullglob

for json_file in /data/*
do
  echo "Importing JSON file $json_file"
  python import_json.py "$json_file"
  echo "-- Done"
done

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

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

תקופה ארוכה PHP היה נגיש כי מספיק היה לשים קובץ PHP על השרת כדי לקבל אתר דינמי (בניגוד ל setup המסורבל של CGI Scripts שהיו לפניו). jQuery היה נגיש כי היה מאוד קל למתכנתים להבין איך להשתמש בו ולבנות קוד שעובד. ריילס ב 2005 היה מאוד נגיש כי הוא דיבר לאותם מאוכזבי PHP שחיפשו יותר סדר בקוד שלהם, אבל לא הרגישו בנוח לעבור ל Java או .NET, אנגולר1 היה יותר נגיש מ Backbone ו Ember למתכנתי Backend כי הוא איפשר להם "לדלג" על לימוד עולם ה Front End ולכתוב דברים סבירים בלי להבין את המכניקה שמתחת, והיום Vue יותר נגיש מ React או Angular מסיבות דומות.

האבסורד הוא שכמעט לכל טכנולוגיה נגישה מגיע בסוף רגע "ההתפכחות", שבו אנחנו מבינים שרק בגלל שהיה קל להתחיל לעבוד בטכנולוגיה מסוימת לא בהכרח הופך אותה לטובה. ב Angular1 זה היה עם הפופולריות של ג'ון פאפא וה Style Guide המפורסם שלו. ריילס הפכה למסורבלת באזור 2010 ככל שעלתה הפופולריות של Node.JS ומיקרו פריימוורקס בצד שרת ו jQuery הפסיקה להיות אטרקציה כשמתכנתים "רציניים" התחילו להביא לעולם ה Front End רעיונות של תכנות מונחה עצמים ואנקפסולציה שהם הכירו מסביבות אחרות, במיוחד החל מ 2008 עם הספר JavaScript The Good Parts.

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