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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ספליטגייט פירסמו התנצלות לפני מספר ימים בחשבון הטוויטר שלהם בזו הלשון (תרגום שלי):

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

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

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

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

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

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

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

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

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

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

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

הכי מפתה לבוא ללקוח ולדרוש שיבחר: שחור או לבן, ביצועים או אבטחה, כיסוי קוד או התקדמות מהירה בפיתוח. מפתה אבל לא יעיל. הנדסה טובה היא מה שקורה באמצע, היא הפשרה הכואבת, היא הטוקן שפג תוקף אחרי 5 דקות (או 2, או 8), וה Refresh Token איתו מבקשים טוקן חדש בצורה אוטומטית, וההחלפה האוטומטית של Refresh Token אחרי כל שימוש כדי שלא ייגנב.

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

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

1. לא מוחקים מידע מבסיס הנתונים, ועדיף גם לא לשנות. רק להוסיף (insert ו select חברים, delete ו update מרושעים).

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

3. בודקים הרשאות בצורה מפורשת בכניסה לכל נתיב בצד השרת.

4. לא מבטלים את ה Firewall. גם אם הוא מפריע לך בבדיקות.

5. לא בולעים שגיאות.

6. יש לקשר כל הודעת קומיט לכרטיס במערכת הניהול שמתאר את הבעיה.

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

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

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

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

const express = require('express')
const app = express()
const port = 3000

const foods = [
    'Humus',
    'Fried Tofu',
    'Eggplant Frittata',
];

app.get('/:id', (req, res) => {
  const index = req.params.id;
  const data = foods[index];
  res.send(data);
})

app.listen(port, () => {
  console.log(`Example app listening at http://localhost:${port}`)
})

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

const express = require('express')
const app = express()
const port = 3000

const foods = [
    { id: 9412, likes: 'Humus' },
    { id: 9121, likes: 'Fried Tofu' },
    { id: 8123, likes: 'Eggplant Frittata' },
];

app.get('/:id', (req, res) => {
  const data = foods.find(item => item.id === req.params.id);
  res.send(data);
})

app.listen(port, () => {
  console.log(`Example app listening at http://localhost:${port}`)
})

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

מבלי להריץ את הקוד נסו לזהות מה נשבר ואיך הייתם מתקנים?