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

למה כתבת את השורה הזאת?

• כי זאת הדרך שתמיד כתבתי כזה קוד

• כי מצאתי את זה בגוגל

• כי מצאתי את זה ב Stack Overflow

• כי ראיתי את זה בסרט ביוטיוב

• כי ראיתי מנגנון דומה במקום אחר במערכת

• כי זה מה שהציע המתכנת הבכיר

• כי זה מה שהציע החבר לידי

• כי זה עבד

עכשיו מה יקרה אם תמחק אותה?

ואיך היה אפשר לכתוב את זה אחרת?

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

כדי לראות את הקושי במימוש מנגנון ריאקטיבי ב JavaScript נתבונן בקטע הקוד הבא:

const input = document.querySelector('input');
const output = document.querySelector('output');

output.value = input.value;

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

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

const input = document.querySelector('input');
const output = document.querySelector('output');

input.addEventListener('input', () => {
    output.value = input.value;
});

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

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

התיאוריה של פריימוורק ריאקטיבי פשוטה: אם אני כול להחליף את document.querySelector ולייצר אוביקט שלי שעוטף את ה DOM Element, אני אוכל לזהות מתי מישהו מנסה לקרוא מידע משדה value שלי, ולייצר אירוע שיפעיל את הקוד הזה מחדש כל פעם שערך השדה מתעדכן. בפועל הפריימוורקים שבנו מנגנון כזה מסתבכים כל אחד במקרי קצה אחרים. הנה שתי דוגמאות פשוטות מ Vue ו MobX ואחריהן סיכום עם המלצה.

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

1. חלק 1 - קומפוננטה ראשונה

2. חלק 2 - העברת מידע בין קומפוננטות

3. חלק 3 - תבניות דינמיות

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

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

1. את תראי גם איך להעלות את הסקין לאקסבוקס?

2. איך מפעילים מיינקרפט?

3. איך משחקים מיינקרפט?

4. את תראי איך למצוא סקינים באינטרנט?

5. זה עובד על Windows 10?

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

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

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

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

אם יש לכם Engagement ו Context, כל מפגש שתעבירו, בזום או בחיים האמיתיים, יהיה זמן שהושקע כמו שצריך.

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

1. בדיקות End To End בסביבת Micro Services הן הרבה יותר יקרות מאשר בסביבת מונולית (ולא שבמונולית הן היו זולות). עיקר העלות הוא הקושי להעלות מערכת מלאה ויציבה התואמת למה שיש בגירסת הפרודקשן.

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

3. בעיות חדשות של E2E Tests לסביבת Micro Services: אין מי שיתחזק אותן, כי כישלון בבדיקה הוא תמיד חוצה צוותים; ושינויים מהירים במערכת מביאים לזה שהבדיקות מאוד לא יציבות. לכן בדיקות E2E יוצרות תלות בין צוותי, וזה בדיוק מה שרצינו לברוח ממנו כשהלכנו לכתוב Micro Services.

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

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

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

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

די בטוח שהיא לא האחרונה, וכנראה שהיא גם לא היתה הזדמנות.

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

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

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

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

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

1. חלק 1 - קומפוננטה ראשונה ב Vue

2. חלק 2 - תקשורת בין קומפוננטות

שתי התכונות הבאות מאפיינות הרבה מהמתכנתים הטובים שפגשתי:

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

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

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

אפשר ושווה להתאמן על זה.

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

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

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

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

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

שתי דוגמאות קלות ומסקנה -

1. מתכנת שלמד 3 שנים ואחרי זה התאמץ ומצא עבודה, אבל אחרי שנתיים של עבודה מרגיש שהחיים בתור מתכנת לא מתאימים לו ובעצם היה רוצה לעשות משהו אחר לגמרי.

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

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

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

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