ToCode

# עבודה אמיתית ולימוד אם הייתי מתחיל ללמוד היום פיתוח Full Stack והייתי צריך לעבור מאפליקציית Node.JS שכתבתי שעובדת אצלי על המכונה להתקנה של האפליקציה בענן, אין שום סיכוי שהייתי הולך ללמוד איך להקים שרת Linux מאפס. עזבו, אפילו היום שאני יודע להקים לעצמי שרתים, כשאני רואה את הממשקים של AWS או Azure DevOps או אפילו Heroku אני מרגיש טיפש להתעסק עם התקנות בעצמי. בלחיצת כפתור מתוך ה IDE היום אפשר להעביר את כל הקוד שלכם לשרת ברשת ולקבל עליו אינסוף מנגנוני ניטור וניהול. או בדוגמה אחרת - אם הייתי מתחיל היום ללמוד git והייתי צריך להתחבר למאגר בשביל לסנכרן עבודה עם חברים בצוות, אין שום סיכוי שהייתי מתחיל מללמוד את ממשק שורת הפקודה ולקרוא את ה Git Book. יש כלי GUI כל כך טובים שכבר מסונכרנים עם ה IDE שלי כך שבלחיצת כפתור מה IDE אני יכול לעשות את כל הפעולות שאני צריך. הבחירה ללמוד טכנולוגיה בצורה משמעותית ולעומק היא לא דרישת קדם לפני שמתחילים לעבוד בטכנולוגיה. למעשה זה לא הגיוני להשקיע כל כך הרבה זמן לימוד לפני שאתם מתחילים להיות מועילים. הבוס משלם לכם כסף כדי שתפתרו באגים ותכתבו פיצ'רים, לא בשביל שתהיו הרבה יותר מקצועיים ב Linux ממה שצריך בשביל העבודה שלכם. ומהעובדות האלה אנחנו יכולים להתקדם לשני כיוונים אפשריים: 1. אפשר לחפש ללמוד את המינימום שאני צריך בשביל להתקדם בעבודה. אם אפשר לעבוד עם ה GUI של גיט ולהגיע לתוצאות טובות אז כאן אני עוצר. אין טעם ללמוד מעבר לזה. 2. אפשר לחפש ללמוד את המקסימום שאני יכול על כלי מסוים, מתוך עניין ובשביל לגלות עליו דברים שאולי יעזרו לשפר את העבודה שלי (ואולי לא). לימוד טכנולוגי כי אפשר, וכי אני מסוג האנשים שלומד טכנולוגיות חדשות. אני חושב שהטענה שצריך לדעת הכל טוב בשביל להתקדם בעבודה לא מוכיחה את עצמה ב Scale. רוב המתכנתים שנפגוש לא מכירים את הקרביים של כל כלי שאנחנו משתמשים בו ובכל זאת אנחנו מצליחים לכתוב מוצרים לא רעים. הבחירה השניה, הבחירה ללמוד לעומק, לאתגר את עצמנו ולחפש דרכים יצירתיות לפתור בעיות לא צריכה את ההצדקה של התוצאה. היא טובה מספיק בפני עצמה.

# משימות לימוד מעניינות בניסיון ללמוד טכנולוגיה חדשה ואחרי שקוראים את ה Tutorial חוזרת כמעט תמיד אותה השאלה: "מה לבנות עכשיו?". מצד אחד אם אתם רוצים ללמוד איך לבנות פרויקט Full Stack גדול ב Node.JS ו React ברור שדרך טובה תהיה לבחור נושא ולבנות עבורו פרויקט. אבל מצד שני פיתוח פרויקט שלם לוקח נצח ויש הרבה מאוד חלקים בפיתוח הפרויקט שלא קשורים ללימוד הטכנולוגיות שרציתם ללמוד. דרך אחת להתמקד בתהליך הלימוד היא ליצור משימות לימוד מעניינות על הטכנולוגיה, כאשר כל משימה קשורה ללימוד היבט מסוים של הנושא ומוגבלת בזמן. נניח בשביל הדוגמה שאנחנו רוצים ללמוד React ועברנו את ה Tutorial הבסיסי. עכשיו אני יכול להמשיך לדבר על Data Flow ב React ולהתחיל ליצור משימות לימוד יותר ממוקדות: 1. אני רוצה ללמוד איך קומפוננטה שומרת State מספרי פשוט אז אבנה קומפוננטה של מונה לחיצות עם State. 2. אני רוצה ללמוד איך קומפוננטה שומרת State יותר מורכב אז אלך לממש את Game Of Life בתור קומפוננטה יחידה. 3. אני רוצה ללמוד איך לטפל באירועים אז אלך לכתוב משחקון בו צריך ללחוץ על כדור שזז על המסך. 4. אני רוצה ללמוד איך כמה קומפוננטות מתקשרות ביניהן אז אלך לבנות דף עם מספר מוני לחיצות וקומפוננטה שמציגה את סכום הערכים בכל המונים. הרבה אנשים מסתכלים על רשימת משימות כזאת ומרגישים שמשהו חסר, שגם אם אצליח לפתור המון המון משימות קטנות זה לא יהפוך אותי למתכנת Full Stack שיודע לכתוב מערכות גדולות או למתכנת React שמעסיקים רוצים לגייס. עדיין יישאר פער בין משהו שיודע לפתור בעיה ספציפית ב React לבין משהו שיודע לבנות מערכת גדולה. והתחושה הזאת היא מעולה כי הרגע היא פתחה לי את הדלת לאוסף חדש של משימות לימוד, הפעם כאלה שלא בהכרח קשורות לריאקט: 1. אני רוצה ללמוד איך נראית מערכת Web המשלבת קוד צד-שרת עם קוד צד-לקוח ומעבירה מידע באמצעות REST API; אז אלך לבנות מערכת של דף בודד שממחישה את החיבור הזה בכל מיני טכנולוגיות צד-לקוח וכל מיני טכנולוגיות צד שרת. 2. אני רוצה ללמוד איך להשתמש ב Client Side Router אז אלך לבנות מערכת המורכבת מ-5 דפים שמעבירים מידע ביניהם, ואבנה אותה 4 פעמים כל פעם בטכנולוגיה אחרת. התאמה טובה בין הדבר שאני רוצה ללמוד לכלי שאני בוחר ללמוד באמצעותו, ודיוק בהגדרת משימת הלימוד, הם דברים שיכולים להפוך את הלימוד שלנו להרבה יותר ממוקד ולהרבה יותר יעיל.

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

# אתגרים בפיתוח מערכת מבוססת Micro Services כל הסימנים מראים שמיקרו סרביסים יישארו איתנו גם ב 2021: האפשרות להקים אותם במהירות בענן, האפשרות להשתמש במגוון שפות תכנות, האפשרות לחלוקת עבודה טובה יותר בין צוותים בארגון, כל אלה הופכים את ארכיטקטורת Micro Services למשהו שאנחנו רוצים לשלב במערכות שלנו. שווה לשים לב שעם כל הטוב של Micro Services יש גם לא מעט אתגרים ייחודיים לארכיטקטורה זו. הנה רשימה חלקית שלהם: ## ניהול זהות האתגר הראשון שניתקל בו כשנעבור ממערכת מונוליט למערכת Micro Services יהיה ניהול זהות של המשתמש. במונוליט משתמש מזוהה בדרך כלל באמצעות Cookie או Token אותו הוא שולח לשרת עם כל בקשה. השרת המונוליט מחובר גם למערכת ניהול הזהויות וגם יודע לעשות את הדבר שהמשתמש רצה לעשות, לכן קוד מונוליט יכול קודם לבדוק שלמשתמש הנוכחי יש הרשאה לבצע את הפעולה שהוא רצה לעשות ואחר כך גם לבצע את אותה פעולה. ב Micro Services החיים קצת יותר מורכבים: מערכת ניהול הזהויות תנוהל לרוב בתור Service נפרד, ולכן לפני כל פעולה ה Service שרוצה לבצע אותה צריך לפנות ל Service ניהול הזהויות כדי לוודא שמותר למשתמש לבצע את הפעולה שהוא רוצה לבצע. סרביס הזהויות יהיה אחד העמוסים במערכת ונפילה אפילו זמנית שלו עלולה לשתק את המערכת כולה. ## ניטור התמודדות עם תקלות במערכת מונוליט כשיש תקלה כולם יודעים עליה ומהר מאוד זה יגיע לבן אדם שיכנס לאתחל את השרת או לתקן את הבעיה. במערכת מבוססת על Micro Services תקלה בסרביס מסוים יכולה בקלות לעבור לנו מתחת לרדאר, או להשפיע על סרביסים אחרים. בעבודה עם מיקרו סרביסים חובה להחזיק Dashboard מסודר שמראה מה מצב החיים של כל סרביס ומתריע כשאחד הסרביסים לא מתפקד. בנוסף צריך דרך טובה להסתכל בצינורות בין הסרביסים כדי לוודא שהודעות לא נתקעות באחד הצינורות. היבט נוסף של ניטור הוא ניהול ביצועים: במערכת מונוליט קל לראות מתי כל בקשה התקבלה ומתי הטיפול הסתיים. במערכת Micro Services חשוב להיות מסוגלים גם כן לעקוב אחר מסלול של "פעולה מלאה" ולראות את הזמן שכל Service משקיע בטיפול בה כדי לוודא שאף Service לא מאט לנו את כל המערכת. ## ניהול Logs המעבר ל Micro Services יכריח אותנו להתמודד עם מספר לוגים במקביל ולהיות מסוגלים לאחד ביניהם כדי לעקוב אחר Request מסוים מהרגע שהוא נכנס למערכת, דרך כל ה Services שטיפלו בו ועד שהתשובה חוזרת ללקוח. כמעט תמיד במערכת גדולה נשתמש במערכת ניהול לוגים מסודרת שתראה לנו בלוח בקרה אחד את הלוגים של כל הסרביסים. ## קושי בתחזוקה כשהצוות מתחלף יחד עם האתגרים התפעוליים יהיו לנו גם אתגרים בצד הפיתוח והתחזוקה של הקוד. טכנולוגיה שנראתה מאוד טרנדית ברגע מסוים יכולה אחרי שנתיים להיראות מיושנת. מאחר ו Micro Services נכתבים בדרך כלל בכל מיני שפות תכנות לפי העדפות המפתחים שכותבים את הסרביס, קל למצוא את עצמנו שנתיים אחרי עם סרביסים ב erlang שאף אחד לא יודע איך לתחזק. ההמלצה במקרה כזה היא לשכתב את ה Service כולו, אבל לא תמיד קל למצוא לזה זמן. ## ניהול גירסאות אתגר אחרון לרשימה זו הוא הגירסאות. בהנחה שאתם לא מתכוונים להיתקע עם סרביסים מיושנים לאורך שנים, כנראה שמישהו יצטרך לתחזק את הסרביסים שאתם כותבים, לתקן באגים ולהוציא גירסאות חדשות. שינוי בסרביס יכול ליצור אפקט דומינו ולחייב שינוי מקביל בסרביסים נוספים שתלויים בו ולכן דורש סינכרון של כמה צוותים. שיטה טובה כאן היא לנסות לא לשנות API של סרביס אלא רק את המימוש הפנימי, ואם כבר משנים API לנסות לשמור על תאימות אחורה. לסיכום פיתוח מערכת מבוססת Micro Services דורש שיטת מחשבה וגישה אחרת לקוד: קודם כל מבחינת כלי עבודה וניהול של כל הסרביסים, ודבר שני מבחינת גישה לפיתוח ומוכנות לשכתב סרביסים ישנים ולבנות חדשים במקומם באופן שוטף. בפרויקטים קטנים פיתוח מבוסס סרביסים יהיה איטי יותר מאשר פיתוח מונוליט, בעיקר בגלל ההשקעה בהקמת ותחזוקת התשתית. לעומת זאת עבור ארגונים גדולים או פרויקטים ענקיים עבודה ב Micro Services בהחלט יכולה לפתוח כיוונים חדשים של גדילה.

# כל מה שתרצה איזה נפלא היה העולם אם היינו יכולים פשוט לעשות את מה שאנחנו רוצים: אתה רוצה לכתוב פוסט לבלוג אז אתה יושב וכותב; אתה רוצה ללמוד טכנולוגיה חדשה אז אתה יושב על הקורס ולומד; אתה רוצה להתחיל להתעמל אז אתה שם שעון, קם בבוקר ויוצא לריצה. שמעתי אפילו שיש אנשים שהחיים שלהם עובדים ככה. אם אתם מאלה אתם יכולים להפסיק לקרוא כאן. רובנו די טובים בלחלום חלומות, יודעים מה צריך בשביל להגשים את החלומות האלה ועוצרים לפני השלב של העשיה או איפשהו בשבועות הראשונים. לחץ חיובי הוא הדרך שלנו לעבוד על עצמנו כדי לעשות דברים שאנחנו רוצים. הנה כמה טריקים שלפעמים עובדים: 1. להכין רשימת מטלות שתמיד תהיה זמינה ושיהיה ברור מה המשימה הבאה שצריך לעשות (לרוץ חצי שעה מחר בבוקר; לכתוב פוסט על ES2021). 2. לארגן חברים שיבואו איתכם (כי לא נעים להבריז לקבוצת ריצה אחרי שכולם קמו מוקדם בגללכם). 3. לרשום ביומן זמן ספציפי לעבוד על הפרויקט הזה שאתם רוצים לקדם. 4. לספר לחבר מה אתם מתכננים לעשות ומתי, ולבקש ממנו שיסמס לכם חצי שעה לפני להזכיר שאתם צריכים לעשות את הדבר הזה (וגם חצי שעה אחרי לשאול איך הלך). 5. והכי קשה - להשתיק את המחשבות המציקות שמשכנעות אתכם לוותר: כמו המחשבה המציקה שתוקפת מיד אחרי שקמתם לרוץ בבוקר שאומרת שאולי בעצם ספורט זה לא כזה חשוב וזה בטוח הרבה פחות חשוב מעוד שעה שינה, ומי צריך את זה עכשיו. או המחשבה שמטרידה שמופיעה איך שהתחלתם ללמוד נושא חדש שאומרת שממילא אף פעם לא תהיו טובים בזה כי יש המון מה ללמוד וחבל על הזמן. החלטה על משימות שחשובות לנו וביצוען בהתמדה שלב אחרי שלב זו מיומנות. זו מיומנות שאפשר לעבוד עליה, ואולי המיומנות שהכי חשוב לעבוד עליה.

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

function sleep(ms) {
  return new Promise((resolve, reject) => {
    if (ms <= 0) {
      reject("Invalid Sleep Time");
    } else {
      setTimeout(() => (resolve(ms)), ms);
    }
  });
}


Promise.any([sleep(10), sleep(20), sleep(-5)]).then((ms) => console.log(`Done: ${ms}`));

הקוד כבר עובד בדפדפנים הקרובים אליכם ומדפיס על המסך את ההודעה: Done: 10. ## איך בונים את זה מנגנון Promises ב JavaScript קנה לעצמו שם של מנגנון די מסובך אבל לדעתי לא בצדק. הבטחה היא בסך הכל אוביקט שיכול להתממש או להיכשל מתישהו בעתיד, ואנחנו יכולים להוסיף לאותה הבטחה הוראות שיגידו לה מה לעשות אם הפעולה הצליחה או נכשלה. ה Promise היא בסך הכל דרך לייצג חישוב אסינכרוני. במקרה של Promise.any אנחנו רוצים להוסיף לכל אחת מההבטחות שקיבלנו שני קטעי קוד: 1. אם ההבטחה מצליחה אני יכול להחזיר את הערך שלה לקוד שיצר אותי. 2. אם ההבטחה נכשלה אני מוסיף את הכישלון לרשימת הכשלונות ובודק אם יש עדיין חישובים פעילים ברקע. אם אין אני מסיים ומחזיר את רשימת הכישלונות בתור כישלון שלי. קוד? ברור:

Promise.any = function(promises) {
  return new Promise((resolve, reject) => {
    const errors = [];
    let activePromisesCount = promises.length;

    function successHandler(...value) {
      activePromisesCount--;
      resolve(...value);
    }

    function errorHandler(err) {
      activePromisesCount--;
      errors.push(err);
      
      if (activePromisesCount === 0) {
        reject(errors);
      }
    }

    for (const p of promises) {
      p.then(successHandler).catch(errorHandler);
    }
  });
}

הגירסה שלי יותר פשוטה מה Spec ולא מטפלת בכל המקרים (לדוגמה פונקציית Promise.any האמיתית תיכשל אם מערך ה Promises שקיבלה הוא ריק), אבל היא כן עוזרת לנו להבין איך לשחק עם אוביקטי Promise: 1. כשיש לי אוביקט Promise ביד אני יכול להוסיף לו קוד הצלחה עם then וקוד טיפול בשגיאות עם catch. 2. אם אני מוסיף קודים כאלה למספר Promises, אני יכול לסנכרן ביניהן באמצעות משתנים משותפים. המשתנה errors מייצג את כל השגיאות בחישובים וכך מאפשר לי בסוף להחזיר את השגיאות של כולם במכה אחת; המשתנה activePromisesCount מייצג את מספר החישובים הפעילים, ובאמצעות הורדה שלו ב-1 כל פעם שחישוב מסתיים אני יכול לדעת מתי הסתיימו כל החישובים. למידע נוסף על הפונקציה מומלץ לקרוא בדף התיעוד בקישור https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/any. ## למה זה טוב עכשיו אנחנו מגיעים ל Money Time של Promise.any ואני חייב להודות שהתשובה לא מאוד פשוטה. ה Use Case היחיד שהצלחתי לגרד לפונקציה זו יהיה בבניית סוג של Load Balancer הפוך בצד הלקוח, כלומר קוד שצריך למשוך מידע משרת ויודע שהמידע הזה זמין על מספר שרתים אז הוא יפנה לכולם וימשיך ברגע שאחד עונה לו. במילים אחרות משהו בסגנון הזה:

const userData = await Promise.any([
      axios.get('https://server1.app.com/user/10'),
      axios.get('https://server2.app.com/user/10'),
      axios.get('https://server3.app.com/user/10'),
    ]);
    
console.log(userData);

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

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

const p = 'The quick brown fox jumps over the lazy dog. If the dog reacted, was it really lazy?';

console.log(p.replace('dog', 'monkey'));
// expected output: "The quick brown fox jumps over the lazy monkey. If the dog reacted, was it really lazy?"


const regex = /Dog/i;
console.log(p.replace(regex, 'ferret'));
// expected output: "The quick brown fox jumps over the lazy ferret. If the dog reacted, was it really lazy?"

הרבה אנשים כשהיו צריכים להחליף מספר מופעים של מילה במילה אחרת השתמשו ביכולת של replace לקבל ביטוי רגולארי והוסיפו את הדגל g לסוף הביטוי:

console.log(p.replace(/dog/g, 'monkey'));
// expected output: "The quick brown fox jumps over the lazy monkey. If the monkey reacted, was it really lazy?"

עכשיו ב ES2021 קיבלנו את הפונקציה replaceAll ואנחנו יכולים כבר לכתוב:

console.log(p.replaceAll('dog', 'monkey'));
// expected output: "The quick brown fox jumps over the lazy monkey. If the monkey reacted, was it really lazy?"

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

const t1 = '*** hello ***';
const t2 = '*';

console.log(t1.replace(/t2/g, '-'));

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

const t1 = '*** hello ***';
const t2 = '*';
console.log(t1.replaceAll(t2, '-'));

// --- hello ---

למידע נוסף על הפונקציה שווה להעיף מבט בדף התיעוד בקישור: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replaceAll.

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

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

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

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