ToCode

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

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

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

# אילוצים לא טכנולוגיים בתור מתכנתים כשאנחנו מחפשים מה תהיה הטכנולוגיה שהכי תתאים לפרויקט מסוים אנחנו אוהבים להסתכל על מאפייני הטכנולוגיה: איך הביצועים של הפריימוורק? כמה קל להרחיב אותה? איך היא מתמודדת עם עומסים? איך היא תסכן אותי מבחינת אבטחת מידע? לפני כמה שנים יצא לי לעבוד על רצף של פרויקטים שכל תכליתם היתה תרגום מערכות: תרגום מ perl ל python; תרגום מ Silverlight ל JavaScript, מ jQuery ל React ואפילו תרגום מ Rails ל Node.JS. בכל המקרים האילוצים שהביאו את הלקוחות לתרגום לא היו אילוצים טכנולוגיים. בפרויקט perl הם לא הצליחו לגייס מתכנתים, כי אף אחד לא רצה לעבוד עם הטכנולוגיה (מועמדים פחדו להמשך הקריירה שלהם וברחו ממילים לא פופולריות בקורות חיים). בפרויקט ה Silverlight החברה שמפתחת את המוצר (היוש מייקרוסופט) החליטה להוריד את המסך, וכל המשתמשים היו צריכים לבנות מוצרים בטכנולוגיות חדשות. ומה יש לכעוס על מייקרוסופט כשאותו דבר קרה גם בפלאש? בפרויקט Rails בגלל ניהול גרוע לא היה זמן לשדרג גירסה לאורך שנים, עד שבסוף השדרוג לריילס חדש היה יותר יקר מכתיבה מחדש של כל הקוד. מאחר ואופנות באות והולכות, את השיקולים הלא טכנולוגיים הרבה יותר קשה לצפות. אני יכול להסתכל על פריימוורק ולדעת אם הוא היום מספיק טוב בשבילי, אבל אי אפשר לדעת איזה טכנולוגיה חדשה תגיע שתשתנה את כללי המשחק. אם אפשר, כתיבת קוד מודולארי שקל לשכתב אותו בחלקים היא מטרה יותר חשובה מאשר בחירת הפריימוורק הטוב ביותר האפשרי.

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

# כשהתיעוד משקר לא מזמן חבר הראה לי את הטריק הבא מסטאק אוברפלו כדי לייצר Directive ב Vue שמדמה את v-if ועושה אותו קצת יותר מתוחכם: https://stackoverflow.com/questions/43003976/a-custom-directive-similar-to-v-if-in-vuejs זה הקוד המעניין מתוך השאלה שם:

Vue.directive('permission', (el, binding, vnode) => {
  if (!isUserGranted(binding.value)) {
    // replace HTMLElement with comment node
    const comment = document.createComment(' ');
    Object.defineProperty(comment, 'setAttribute', {
      value: () => undefined,
    });
    vnode.elm = comment;
    vnode.text = ' ';
    vnode.isComment = true;
    vnode.context = undefined;
    vnode.tag = undefined;
    vnode.data.directives = undefined;

    if (vnode.componentInstance) {
      vnode.componentInstance.$el = comment;
    }

    if (el.parentNode) {
      el.parentNode.replaceChild(comment, el);
    }
  }
});

הייתי צריך לקרוא את זה כמה פעמים בשביל להאמין, לא ידעתי שזה אפשרי. לא ידעתי שמותר לשנות את ה vnode מתוך Directive. נו אז הלכתי לתיעוד של Vue לראות מי צודק ומצאתי את המשפט שזכרתי ממנו: > Apart from el, you should treat these arguments as read-only and never modify them. If you need to share information across hooks, it is recommended to do so through element’s dataset. עכשיו - מי צודק? התיעוד או Stack Overflow? ואם מישהו נתקל בתשובה בסטאק אוברפלו בלי שהכיר קודם את התיעוד? אז האמת שזאת דוגמה נחמדה וממש לא היחידה בה תיעוד של ספריה מספר משהו אחד ובפועל אפשר לעשות דברים אחרים ואפילו את ההיפך. זה לא אומר שהתיעוד טועה או מרמה אתכם. התיעוד מסביר איך כותבי הספריה התכוונו שנשתמש בפיצ'ר מסוים, ודרך הבנת הכוונות שלהם איך כדאי לנו לכתוב קוד כדי שהוא יעבוד בביצועים טובים וימשיך לעבוד גם בגירסאות טובות של הספריה. בעולם הקוד הפתוח המשפט הנכון הוא לא "שברת, שילמת" אלא "שברת - אתה זוכה לשמור את החלקים", כלומר אם תבחר שלא להקשיב לתיעוד יכול להיות שהקוד שלך יעבוד אבל גם יכול להיות שהוא יפסיק לעבוד מתישהו (או רק במקרים מסוימים) בלי הודעה מוקדמת ובלי שיהיה לך את מי לשאול. במקרה של הקוד שלנו החבר רצה להפעיל טריק דומה על Vue 3, אבל כצפוי העתקה פשוטה של הקוד לא ממש עבדה ובסופו של דבר נדרש קצת Refactoring כדי לפתור את הבעיה באמצעים אחרים. אגב אם יש מומחי Vue בין הקוראים שיודעים איך לתרגם את הקטע הזה ל Vue3 אני יודע לפחות על חבר אחד שמאוד ישמח לשמוע. תרגישו חופשי להציע רעיונות בתגובות.

# חמישה פיצ'רים שעדיף ליישם לפני שהמערכת שלכם הופכת פופולרית יום אחד המערכת שאתם בונים תהפוך לפופולרית ויהיו לכם המון משתמשים משלמים שגם ימליצו לחברים שלהם על המערכת הנפלאה שכתבתם. כשזה יקרה האני העתידי שלכם מאוד יודה לכם אם יחד עם אותם משתמשים גם תבנו את התשתית המתאימה לעזור להם ובפרט את חמשת הפיצ'רים החשובים הבאים: ## מערכת ניהול המאפשרת "התחברות" למשתמש פעיל יחד עם המשתמשים יגיעו גם באגים והמשתמשים יצלצלו אליכם לשאול למה דברים מסוימים שהם רוצים לא עובדים. במקום שתסתכלו על המסך באימה, מערכת ניהול טובה שתאפשר לכם להתחבר "בתור" משתמש קיים ולראות את כל מה שהוא רואה, או להתחבר ל Session קיים ולראות מה קורה בו בזמן אמת יכולה לחסוך לכם הרבה כאב ראש. הזמן הכי גרוע להתחיל לפתח כזאת מערכת ניהול משתמשים הוא כשהתקלות מתחילות, ולכן עדיף להגיע מוכנים עם התשתיות במקום. ## מערכת מעקב אחרי אירועים ונתונים היסטוריים הדבר השני שיקרה למשתמשים זה שהם ימחקו לעצמם מידע, ואז הם שוב יצלצלו אליכם כדי שתחזירו את המידע שלהם. זה יהיה זמן ממש גרוע לספר להם שהכל אבוד והמערכת שלכם באמת מחקה את המידע החשוב שהם כתבו. תשתית טובה של שמירת מידע ושחזור מידע של משתמשים הכרחית כבר מהיום הראשון, ועדיף אפילו להנגיש אותה למשתמשים עצמם כדי לחסוך לכם את כאב הראש. ## סט בדיקות מערכת מקיף הזמן הכי גרוע לכתוב סט בדיקות מערכת הוא אחרי שהמערכת כבר באוויר, בגלל שאז יש יותר מדי פיצ'רים. אם אנחנו רוצים להיות מסוגלים להתקדם מהר ולהעלות תיקונים ופיצ'רים חדשים, בלי לשבור דברים קיימים למשתמשים אנחנו חייבים סט טוב של בדיקות אוטומטיות. כתבו בדיקות תוך כדי תנועה לכל פיצ'ר שאתם בונים וכשהמשתמשים יגיעו וידרשו פיצ'ר חדש או תיקון באג תוכלו להיות רגועים שלא שברתם שום דבר. ## תרגום ככל שמערכת גדלה ואנחנו מתקדמים בפיתוח כך יהיו בה יותר טקסטים. עדיף לשמור את הטקסטים האלה מראש במקום בו יהיה קל לתרגם אותם, ולבנות את כל הגישה לטקסטים מתוך הקוד בצורה שפשוט תעבוד אוטומטית אם נוסיף תרגום לשפה חדשה. הקפדה על משמעת טקסטים בזמן פיתוח תחזיר את עצמה בגדול כשיגיע היום שתצטרכו לתרגם את המערכת לשפה חדשה. ## פריסה עולמית והקמה מהירה של שרתים היום עם Docker קל מאוד לבנות את המערכת בצורה מודולרית כך שיהיה קל להוסיף עוד שרתים. הבעיה שאנחנו המתכנתים לפעמים מכניסים לקוד מנגנונים שמונעים ממנו להיות מודולרי - לדוגמה אם אני כותב מידע לקובץ אז הקובץ הזה קיים רק על השרת הנוכחי, ובשביל להוסיף שרת אני צריך לשנות את הקוד ולכתוב את הקובץ למקום משותף. אם נקפיד מתחילת הפיתוח ולכל אורכו לבדוק את הקוד שלנו לפחות על שני שרתי אפליקציה ו Load Balancer נוכל להיות בטוחים שכשיגיע היום ובאמת נצטרך להעלות סקייל יהיה לנו קל להוסיף גם שרת שלישי, רביעי ועשירי והכל ימשיך לעבוד.