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

הרבה זמן לא הבנתי את git stash. הרי למה לזרוק את כל השינויים שלי ל stash כשאני יכול לעשות להם קומיט ל branch זמני חדש? מה אני מרוויח מלשים אותם במקום שבו רק יהיה לי יותר קשה למצוא אותם?

אז אם גם אתם לא מהמשתמשים הכבדים של גיט סטאש הנה שני מצבים שבהם כן כדאי להכיר אותו ולהשתמש בו-

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

במרץ 2016 מתכנת בשם Azer Koçulu (לא בטוח שאני יודע לתרגם את השם הזה לעברית) שבר את האינטרנט. הוא מחק מ npm כמה מודולים שפירסם בפרשה שהביאה בפעם הראשונה את מנהלי npm להחזיר מודול שמשתמש מחק. המודול במרכז הפרשה נקרא left-pad ומה שמיוחד בו הוא שאינספור חבילות npm השתמשו בו בתור דרישת קדם. ברגע שמודול זה ירד, אי אפשר היה יותר להתקין אף חבילה שתלויה בו וכך מאות אלפי מתכנתים ברחבי העולם לא הצליחו להפעיל npm install.

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

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

const animals = [
    { id: 1, name: 'cat' },
    { id: 2, name: 'dog' },
    { id: 3, name: 'mouse' },
];

type AnimalName = 'cat' | 'dog' | 'mouse'

function getAnimal(name: AnimalName) {
  return animals.find(a => a.name === name)
}

עכשיו אנחנו יכולים להפעיל:

console.log(getAnimal('dog'));

ולקבל את התוצאה בלי בעיה, אבל אם ננסה להפעיל:

console.log(getAnimal('bird'));

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

עכשיו זה מעולה אבל השורה הזאת:

type AnimalName = 'cat' | 'dog' | 'mouse'

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

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

const animals = [
    { id: 1, name: 'cat' },
    { id: 2, name: 'dog' },
    { id: 3, name: 'mouse' },
] as const;

type AnimalName = typeof animals[number]['name'];

function getAnimal(name: AnimalName) {
  return animals.find(a => a.name === name)
}

console.log(getAnimal('dog'));

רק אל תשכחו להוסיף אחרי הגדרת המערך את המילים as const אחרת TypeScript יגדיר את AnimalName להיות פשוט string ולא יזרוק שום שגיאה.

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

$ npx create-react-app yoyo
Need to install the following packages:
  create-react-app
Ok to proceed? (y)

You are running `create-react-app` 4.0.3, which is behind the latest release (5.0.0).

We no longer support global installation of Create React App.

Please remove any global installs with one of the following commands:
- npm uninstall -g create-react-app
- yarn global remove create-react-app

The latest instructions for creating a new app can be found here:
https://create-react-app.dev/docs/getting-started/

מיותר לציין שאין לי שום התקנה גלובאלית של create-react-app ולכן שתי ההצעות שלו להסרת create-react-app לא היו רלוונטיות.

מה קרה כאן? זה פשוט - גם ל npx יש cache. הוא שומר אותו בתיקיית ~/.npm/_npx. כשהוא שואל אותי אם להתקין את create-react-app ואני מאשר הוא שם לב שלא ביקשתי גירסה מסוימת, אז הולך ל cache, מוצא שם את גירסה 4 ומתקין אותה.

דרך קלה לצאת מזה היא לציין את הגירסה, וזו המשמעות של כרוכית latest - כלומר הפעלה כזו:

$ npx create-react-app@latest yoyo

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

$ rm -rf ~/.npm/_npx
$ npx create-react-app yoyo

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

1. מימוש של פונקציה

2. חתימה של פונקציה

3. רשימת פונקציות או מחלקות שמיוצאות ממודול

4. רשימת טבלאות ב DB ועמודות של כל טבלה

5. רשימת API Routes והחלטה על הפרמטרים של כל נתיב

6. פרוטוקולים לתקשורת בין מערכות (API ציבורי)

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

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

בקורס Node.JS פה באתר אני מלמד איך לשמור קבצים בתיקיה מקומית על השרת או בבסיס נתונים של Mongo. בעקבות שאלה של תלמיד חשבתי להוסיף כאן מדריך איך להעלות את הקבצים גם ל AWS S3 למי שמעדיף.

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

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

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

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

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

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

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

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

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

5. בדיקות כדי לשפר נגישות - ספריות בדיקה כמו testing-library אבל גם סלניום יעבדו טוב יותר אם האתר נגיש, כי ספריית הבדיקה, כמו קורא מסך, צריכה לתקשר עם האלמנטים שעל המסך ורגישה הרבה יותר לקוד מאשר לעיצובים וצבעים. לא פעם קרה לי שהוספתי תווית טקסט או מאפיין aria-label רק בשביל שיהיה לי יותר קל לתפוס אלמנט מסוים בספריית הבדיקה.

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

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

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

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

1. להעלות State לקומפוננטה עליונה (ולקבל אותו חזרה כ Props).

2. להוריד State לקומפוננטה פנימית (ואם צריך להעביר לה פונקציות Callback לעדכון כשהסטייט משתנה).

3. להוציא State ל Context.

4. להחזיר State מ Context לקומפוננטה עליונה, ולהעביר אותו למטה בתור Props לקומפוננטות הפנימיות.

5. להוציא חלק מקומפוננטה לקומפוננטה חיצונית חדשה, כדי לפשט קומפוננטות מסובכות.

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

7. להוציא החוצה לוגיקה + State ל Custom Hook.

8. ליצור קומפוננטה חדשה מקומפוננטה קיימת כדי לקרוא ל Hook בצורה מותנית.

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

10. להחזיר פונקציה מקובץ נפרד לקומפוננטה כשהיא צריכה גישה ל State, ל Props או למידע אחר ספציפי לקומפוננטה.

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