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

כשאנחנו מקשיבים למה שקורה בתעשיה או מסתכלים ברשת על כל מיני Best Practices אנחנו עלולים לטעות ולחשוב ש-

1. כולם כותבים Micro Services, מונוליט זה מיושן.

2. אצל כולם יש בדיקות (יחידה + קצה לקצה).

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

4. לכולם יש גיבויים מתוקתקים ופעם בחודש הם עושים תרגיל שחזור מגיבוי.

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

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

7. כולם מחזיקים תיעוד עדכני של המערכת כך שמתכנתים חדשים יכולים בקלות להיכנס לקוד.

8. כולם מוחקים קוד שלא משתמשים בו.

9. כולם שולטים בטכנולוגיות בהן הם עובדים.

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

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

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

1. חלומות - החלום על איך החיים יראו אחרי שאדע את הדבר הזה שאני לומד (חלום על העבודה שתהיה לי, על הטיול שאוכל לעשות)

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

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

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

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

6. כי אנשים כמוני עושים דברים כאלה - כשאני מצפה מעצמי להתנהגות מסוימת שמתאימה לדימוי העצמי שלי.

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

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

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

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

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