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

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

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

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

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

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

והחיפוש לא דורש שתהיה תשובה בסוף.

איך לא טיפלנו בזה כשזה רק התחיל? נו זה ברור-

• בהתחלה זה לא נראה כזה ביג דיל

• היה נדמה שתמיד אפשר לשנות בעתיד

• רצינו לעלות לאוויר

• רצינו להתקדם בפיצ'רים יותר חשובים

• זה לא היה שווה את המאמץ

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

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

לא, זו לא שגיאת כתיב בכותרת - אכן יש מערכת ענן חינמית לגמרי בשם deta שכוללת גם בסיס נתונים וגם אפשרות לכתוב קוד ווב ב Python או Node.JS. הלכתי לשחק עם ה API שלהם כדי לראות מה אפשר לקבל בלי לשלם.

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

import { render } from '@testing-library/react';
import App from './App';

test('renders learn react link', () => {
  const screen = render(<App />);
  const linkElement = screen.getByText(/learn react/i);
  expect(linkElement).not.toBeInTheDocument();
});

על פני:

import { screen, render } from '@testing-library/react';
import App from './App';

test('renders learn react link', () => {
  render(<App />);
  const linkElement = screen.getByText(/learn react/i);
  expect(linkElement).not.toBeInTheDocument();
});

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

בתקופה האחרונה העדפה זו נהייתה קשה יותר לביצוע בגלל ש create-react-app כולל הגדרות eslint שממליצות בדיוק על ההיפך, כלומר על הגישה השניה. ההסבר שלהם כאן: https://github.com/testing-library/eslint-plugin-testing-library/blob/main/docs/rules/prefer-screen-queries.md

מה עושים? מתקנים את ה eslint כמובן. בתוך הקובץ package.json של פרויקט create-react-app חדש נוכל למצוא את הבלוק הבא:

  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },

כל מה שצריך לעשות זה לזהות את שם הכלל מתוך הודעת השגיאה או דף ההסבר על הכלל, במקרה שלנו הכללים הבעייתיים הם testing-library/prefer-screen-queries ו testing-library/render-result-naming-convention ואז מוסיפים בלוק rules ל package.json שמנטרל את שניהם:

  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ],
    "rules": {
      "testing-library/prefer-screen-queries": "off",
      "testing-library/render-result-naming-convention": "off"
    }
  },

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

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

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

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

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

ואותו דבר לגבי הבחירה בין Redux ל MobX, בין ריאקט ל Vue, בין GraphQL ל REST. ובכל זאת נדמה שהאושר הכי גדול שלנו הוא להיתקע על אותן פינות לא חשובות הרבה יותר מדי זמן בתור צורה של הסחת דעת. כאילו הלב רוצה לעשות הכל חוץ מלהתקדם.

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

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

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

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

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

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

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

אבל זו אשליה.

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

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

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

import { useRef } from "react";

export default function App() {
  const inputRef = useRef(null);
  const hasText = inputRef?.current?.value !== "";

  return (
    <div className="App">
      <h1>Write some text to enable the button</h1>
      <input type="text" ref={inputRef} />
      <button 
          disabled={!hasText}
      >Go</button>
      <p>hasText = {hasText}</p>
    </div>
  );
}

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