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

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

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

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

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

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

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

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

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

1. להכין רשימת מטלות שתמיד תהיה זמינה ושיהיה ברור מה המשימה הבאה שצריך לעשות (לרוץ חצי שעה מחר בבוקר; לכתוב פוסט על ES2021).

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

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

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

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

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

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

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

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

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

describe("my test", () => {
    it("just works", () => {
        expect(1).toEqual(1);
    });
});

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

הבדיקה הראשונה במערכת היא המדרגה הראשונה. עכשיו אפשר לעשות Copy/Paste ולהמשיך לכתוב את הבדיקה השניה, השלישית וה-500. ובכל צעד להמשיך לגלות טכניקות בדיקה חדשות.

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

1. אם אנחנו במצב צפיה הערך של isEditing יהיה false ונציג אלמנט p עם הערך.

2. אם אנחנו במצב עריכה הערך של isEditing יהיה true ונציג את הערך בתוך input.

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

function EditableText(props) {
    const { value, setValue } = props;
    const [ isEditing, setIsEditing ] = useState(false);
    const inputRef = useRef(null);

    function startEdit() {
        setIsEditing(true);
    }

    function doneEdit() {
        setValue(inputRef.current.value);
        setIsEditing(false);
    }

    if (isEditing) {
        return (
            <>
                <input type="text" ref={inputRef} defaultValue={value} />
                <button onClick={doneEdit}>Save</button>
            </>
        );
    } else {
        return (
            <>
                <p>{value}</p>
                <button onClick={startEdit}>Edit</button>
            </>
        );
    }
}

ההרפתקנים שביניכם יכולים למצוא את הקוד עובד בקודסנדבוקס בקישור https://codesandbox.io/s/objective-cloud-x4zm7?file=/src/App.js.

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

  const [isEditing, setIsEditing] = useState(!value);

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

ישבתי לא מזמן עם חבר מתכנת 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/