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

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

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 שמתאים לעץ קבצים ותיקיות בפורמט מסוים.

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

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

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

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

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

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

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

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

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