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

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

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

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

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

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

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

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

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

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

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

1. אתה שוכח מה עשית ולמה זה שבר את הבדיקה.

2. בדיקות נוספות נשברות בגלל שינויים חדשים.

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

בעבודה עם גיט קל לייצר תהליך עבודה אוטומטי שמריץ את הבדיקות לפני הקומיט. בהנחה שאתם בפרויקט node ומריצים את הבדיקות עם npm test כל מה שצריך לעשות זה ליצור סקריפט חדש בתיקיית .git/hooks ולקרוא לו בשם pre-commit, בתוכו לכתוב את התוכן:

#!/bin/sh

echo "*****Running unit tests******"

git stash -q --keep-index

npm test

status=$?

git stash pop -q

exit $status

ולתת לו הרשאות הרצה:

$ chmod +x .git/hooks/pre-commit

בפעם הבאה שתנסו לעשות commit לקוד גיט קודם כל יריץ את הבדיקות ויצעק עליכם אם משהו נכשל.

נ.ב. בפרויקט שנוצר עם create-react-app צריך להפעיל את שורת הרצת הבדיקות ובמקום לכתוב npm test נכתוב שם npm test -- --watchAll=false כדי להריץ את הבדיקות פעם אחת ולא לעקוב אחרי שינויים בקבצים.

ספריית react-testing-library מספקת כלים מצוינים לבדיקת קומפוננטות - אבל מה עושים עם Custom Hooks? האם עלינו להשאיר אותם לגורלם להישבר ללא בדיקות?

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

• "אין מצב, אצלי זה עובד"

• "ככה זה כשלא משאירים זמן לבדיקות"

• "ככה זה כשאין תהליכי עבודה מסודרים"

• "איך לא מצאו את זה ב QA??"

• "זה לא באג זה פיצ'ר"

• "הי הי אף אחד באיפיון לא דיבר על ה Use Case הזה"

• "לא הצלחתי לשחזר נמשיך לעקוב"

• "מעניין! אפשר לראות?"

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

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

בין כל הבאגים שאפשר לפגוש אלה שקשורים לדברים טפשיים מחוץ לקוד הם המרגיזים ביותר-

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

כשאתה מגלה שאתה מדבג את הדבר הלא נכון, כי שכחת ללחוץ Save.

כשאתה מגלה שהמערכת לא עובדת כי השתמשת ב ^ ב package.json והותקנה גירסה חדשה מדי של אחת התלויות.

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

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

כשדברים מוזרים קורים, קודם כל לסגור ולפתוח את webpack לפני שממשיכים.

כשדברים מוזרים קורים, קודם כל לעשות Save.

כשדברים מוזרים קורים, קודם כל להשוות גירסאות שהותקנו עם npm ls

כשדברים מוזרים קורים, קודם כל להסתכל על איזה שרת אני עובד.

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

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

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

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

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

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

הסיפור הוא פשוט - אם אתם כותבים חבילת Node.JS אז אתם יכולים לציין 3 רשימות של תלויות ב package.json שלכם:

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

2. רשימת peerDependencies מגדירה רשימה של ספריות שאתם דורשים ש"יהיו שם" כשלקוח מתקין את הספריה שלכם, כלומר ספריות שגם אתם משתמשים בהן וגם קוד הלקוח משתמש בהן.

3. רשימת devDependencies מגדירה רשימה של תלויות שרק אתם מתקינים במצב פיתוח.

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

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