יום רביעי, 2 באוקטובר 2019

378 Intuitive codebases with Omri Fima

פודקאסט מספר 378 של רברס עם פלטפורמה - אורי ורן מארחים בכרכור (קצת פחות חם?) את עמרי פימה מחברת Natural Intelligence לשיחה על Intuitive Codebases, או במילים אחרות - קוד-בייסים אינטיאיטיביים (לא ראיתם את זה בא, הא?)

ולפני כן - קצת על עמרי ועל החברה - 
  • עמרי - כיום ארכיטקט ב - Natural Intelligence, ש”עוזרת לצרכנים לקבל החלטות” - היום בעולם הצרכנות יש המון החלטות שאנחנו צריכים לקבל (ממשכנתא, ביטוח, DNA Kits ועד מזגן, מקרר, מכונות כביסה וכו’). 
    • אנחנו יודעים לעשות את המחקר באינטרנט ולעזור לאנשים להבין מה חשוב, מה לא חשוב, ואיך לבחור נכון.

וכיוון שאתם חברת תוכנה - סביר להניח שיש מאחורי זה לא מעט מדע והנדסה. איך הדברים האלה עובדים? איך אתם עוזרים ללקוחות לקבל החלטות (מעבר לאינטליגנציה טבעית כמובן . . .)?
  • יש הרבה מאוד תהליכים - מנועי המלצות, או “פשוט לסרוק את האינטרנט”, להבין ולעשות ניתוח - ובהרבה מקרים זה אנשים שעושים מחקר ומנסים להבין מה באמת חשוב בכל עולם תוכן ובכל תעשייה, על מנת לעזור לכל אחד לקבל החלטה.
    • ומן הסתם - יש גם אתגר של לנסות להפוך את כל זה לאוטומטי: רק חלק מהאתגר של לנסות לגדול מ-150 עולמות תוכן לכיון ה-3,000-4,000 ואולי הרבה יותר.

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

ובכל זאת רגע לפני - קצת על הרקע של עמרי: מה עשית לפני כן? אילו דברים אתה אוהב לעשות בעולם התוכנה? מה היה המעבד הראשון שסבל את נחת זרועך? כאלה . . .
  • מגאסון . . . יש מספר או שלא סופרים? ויש גם את האטארי של אבא, אבל זה עוד היה בשחור-לבן.
  • האהבה לעולם התוכנה התחילה עם מה שילדי שנות ה-90’ זוכרים כמשחק קליק ובניית משחקים - החל מ-Visual Basic, עתודאי בצבא (חיל אוויר), בניתי דברים שונים ומשונים.
  • בחמש השנים שלפני Natural Intelligence עבדתי ב - Sears Israel - בנינו אתרי קניות, ועשיתי שם הכל מהכל: החל מ-SRE (דאגתי שהאתר לא ייפול ב - Black Friday . . .), דרך עולמות של המלצות, ניתוח טקסט, ניתוח סנטימנטים, מה משתמשים אוהבים ומה מעניין אותם - ואפילו עד עולמות של IOT ובניית מכשירים חכמים.
  • לפני כ-9 חודשים הצטרפתי ל - Natural Intelligence בתפקיד ארכיטקט, ולמעשה כל הנושא של Intuitive Codebases מדבר הרבה מאוד על החווייה האישית שלי (עמרי) בתור תוכניתן חדש בסופו של יום, שמנסה להבין מה לעזאזל קורה פה . . .

חשוב לציין שעמרי גם מדבר לא מעט בכנסים (כולל באיזה אחד בשם Reversim Summit - 2017, 2018, 2019 …) - 
  • אוהב לדבר, אוהב לבנות - לשם כך התכנסנו היום.

אז לפני בערך 9 חודשים הצטרפת ל - Natural Intelligence, שהייתה קיימת לפני כן) - ספר על חוויות שלך כמהנדס מנוסה שמגיע ל - Codebase קיים: מה ראית? מה למדת? ואיך זה לוקח אותך לבלוג-פוסט שפרסמת על Intuitive Codebases.
  • אחד הדברים שהכי הפתיעו אותי היה שביום שבו הגעתי לחברה - הגעתי יחד עם עוד 26 אנשים… לא כולם Engineers, אבל הרבה מאוד כן, כאלו שבאו ועברו את החווייה יחד איתי, כמעיין “חווייה קבוצתית”.
  • יותר מזה - חודש אחרי הגיעה עוד כמות דומה, ובחודש שאחרי - עוד כמות גדולה.
    • בגדול - כמעט בכל חודש מתווספים משהו כמו עשרה מהנדסים לחברה. להכשיר את כולם זה קשה (ולהכשיר אותי גם היה קשה).
  • אז ניסיתי לחשוב אילו דברים היו טובים בתהליך הזה ומה אפשר לשפר - כי נראה שמהנדסים הולכים להמשיך להצטרף, ושווה לראות מה אפשר ללמוד על זה.

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

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

גם לנו (רן, AppsFlyer) יש אתגרים מאוד דומים, וגם אצלנו יש אקדמיה - וגם אני שואל שאלות דומות ויכול להזדהות עם הכאב הזה . . .
רק על מנת להדגיש את הנקודה - למה נדרש למהנדס מנוסה, שכבר עשה Deploy בחיים שלו, שבועיים וחצי עד שיתחיל להיות פרודוקטיבי ויכתוב שורת קוד שתכנס למוצר (לפחות “שייתן Commit ראשון ל-Production”)?
  • מסתבר שיש הרבה מאוד סיבות, Anti-patterns ו-Best Practices שאנחנו כמהנדסים אוהבים לבוא ולעשות.
  • קודם כל - מסיבות כאלו ואחרות, אנחנו לא אוהבים להיות קונסיסטנטיים (Consistent): לא בין ידע העבר שיש ולא מניסיון ממקומות קודמים וידע מהתעשייה לבין מה שקורה במקום חדש - יש לנו הרבה מאוד אהבה להמציא את הגלגל מחדש, להמציא טרמינולוגיה מחדש, וזו צרה אחת.
    • מפתחים, גם כשהם מנוסים - הידע שקיים אצלם לא בהכרח ניתן להפעלה (Exercise) בצורה מהירה ומיידית על Codebase חדש ועל עולם חדש.
  • מבחינת Stack טכנולוגי - היית בעולם שאתה מכיר? בגדול כן, ובגדול טכנולוגיה זה לא האספקט הקשה. אנחנו עובדים ב - Stack יחסית סטנדרטי: Slack, Node.js, Kubernetes - לא משהו שהתעשייה לא מכירה.
  • אבל - כל חברה היום לוקחת את “הטוויסט” שלה, וזה בא לידי ביטוי (איך שאני רואה את זה) בעיקר בארכיטקטורה של המוצר.
  • מה הכוונה? בסופו של דבר הצורה בה אני תופס ארכיטקטורה של מוצר אינה בהכרח סט המחלקות או המודולים, אלא סט הערכים.
  • כשאנחנו באים לבנות מוצר ובאים לבנות ארכיטקטורה, בין אם אנחנו מתכוונים לזה ובין אם לאו - הקוד מייצג את הערכים של הארגון.
  • ננסה דוגמא - בחברה הקודמת (Sears), משהו מאוד חשוב היה ורסטיליות (Versatility) של אנשים: היכולת לעבור מפרויקט לפרויקט, כך שאם יש עכשיו את הדבר הלוהט הבא אפשר לקפוץ לשם - והיו לזה משמעויות בארכיטקטורה שלנו - 
    • העדפנו מבנה של מונוליט - מצב של Codebase אחד שנמצא במקום אחד שזמין לכולם, וקל ומותר לגעת בכל דבר, וגם הכל נראה אותו הדבר לאורך כל המערכות.
  • הכוונה ל-Mono-Repo או ל - Monolith?
    • בהרבה מאוד מובנים Monolith, גם לפי הרבה עקרונות אחרים - למשל: החלטנו לוותר באופן מודע על פוליגלוטיות (Polyglot Programming), לבוא ולומר שלא משנה איך אתה “משחק את המשחק”, אתה תשחק באותה צורה; הרבה דברים יראו אותו הדבר, במידה מסויימת גם במחיר של ויתור על עקרונות של  Loosely-coupled - כי אנחנו רואים ערך בזה שהכל נוגע בהכל ותוכניתנים יכולים לגעת בהכל, ושתוכניתן יכול להבין את המשמעות של מה שהוא עושה.
סתם מתוך סקרנות - מונוליט גם ברמת הפרישה (Deploy): פורשים Binary אחד וזה ה - Binary היחיד של החברה, או שברמה הזו זה כבר משהו אחר, יותר מעודן?
  • אוקיי, אז לא היה מונוליט אחד - היו ארבעה . .  וכן - בסופו של יום היה בזה ערך, כי ה - codebase היה משותף וכולם הכירו את הקוד של כולם ולא משנה באיזה צוות היית.
  • במידה מסויימת היינו מספיק קטנים על מנת להצליח להחזיק את הערכים האלה.
  • לעומת זאת - עכשיו ב - Natural Intelligence יש ערכים חדשים - וה - Codebase צריך לייצג את זה.
  • “פתאום” אנחנו הרבה יותר גדולים - אז צריך לדבר על אחריות, ואיזורי אחריות, ו - Business Domains, וצריך לדבר על זה שאנחנו לא רק גדולים אלא גם גדלים מאוד מהר, אז צריך לדבר על המשמעות של הכנסת המהנדס הבא - איך אנחנו גורמים לזה שהרבה מאוד מההחלטות ההנדסיות שקיבלנו מאוד ברורות ואינטואיטיביות (Intuitive Codebases) ולא צריך לשאול וכל הזמן ללוות את המהנדס הבא “ולהחזיק לו את היד בדרך לפרודוקטיביות”.

קצת רפלקציה למה שעברנו (אורי) ב- Outbrain - אני חושב שעברנו את הצמיחה שאתה מתאר וגם ממשיכים לצמוח, אבל זה כבר לא חדש לנו. 
  • כמה דברים שעשינו בדרך היו מעבר מאוד חד ל - micro services, מה שמייצר אחריות ו-Decoupling מאוד טוב בין ה - Services.
  • זה בא כמובן לאורך הדרך עם חסרונות, אבל מאפשר הרבה מאוד דברים, שאחד מהם הוא שיהיה Infrastructure אחיד לכל ה - Services, גם ברמת תשתיות התוכנה שמאפשרות את זה.
  • כשמפתח מגיע הוא מקבל לינק ל - Boot-Camp, שהוא משימתי - כמו קורס Online שהוא צריך לעבור ובעצם לראות ו”להכיר בידיים” איך בונים Service, איך עושים לו Deployment וכו’ - כשבסופו של דבר הוא יוצא עם סט כלים ומכיר את ה - Infrastructure הזה, ובאותו הזמן הוא (המהנדס החדש) מכיר כמו כל עובד חדש את הסביבה עסקית - כי עכשיו הוא צריך לעבוד על פתרונות עסקיים.
  • כשמפתח בא ויכול לעשות Commit ל - Production, זה נחמד וזה “אחלה גימיק” - אבל זה לא אומר שהוא פרודוקטיבי . . . בשביל זה הוא צריך לכל הפחות הבנה מינימלית של ה - Business ולהבין מה הוא עושה, אחרת גם ככה אתה צריך להחזיק לו את היד.
  • וזה לוקח זמן, במיוחד בחברה גדולה. אתה (עמרי ב - Natural Intelligence) לא רחוק מזה, אבל אתה מבין שיש עולם מושגים שלם שאתה צריך להכיר ולהבין על מנת להיות “יעיל עסקית”.

אני (רן) חושב שכדי להיות פרודוקטיבי אתה לא צריך להבין הכל.
  • נכון, זה טוב להבין את ה - Business, אבל מה שאני נתקל בו לפעמים היום זה מצב שבו חברות נמצאות תחת הרושם שצריך לתת למהנדס את כל הכלים ואז הוא “יכול לרוץ” - ואז תקופת ה - On-boarding מאוד ארוכה, וכשאתה חושב שהוא יכול לרוץ - הוא לא באמת יכול לרוץ, כי כמה באמת אפשר ללמוד בשבועיים /חודש / חודשיים - יש גבול לכמה שאפשר לספוג בזמן מוגבל.
  • אני חושב שהחוכמה היא לתת במידה את מה שצריך על מנת שהעובד החדש יהיה פרודוקטיבי “בקטנה” (לשפר Performance של משהו או פיצ’ר קטן), בלי בהכרח להבין את כל המוצר.

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

  • (עמרי) נכון - ובמידה רבה כשבאתי וניסיתי לבחון את זה, זה הוביל אותי לנקודה שהיא מאוד משמעותית בחוויה שלי, שהיום אני יודע לתת לה שם
  • ניחוש אחד  - Intuitive Codebases!
  • כן, זה ה - Tagline הגדול, אבל כשאני מנסה לבוא ולפרק את זה - בסופו של דבר היה לי את הבסיס הטכנולוגי וגם קיבלתי את ההכשרה, אבל עכשיו אני צריך לצלול לתוך הקוד, כשאני עושה את זה, יש כמות מוגבלת של Infrastructure אבל יחד עם זה יש 70-80 micro services עסקיים - איך אני מוצא את הידיים ואת הרגליים בתוך כל זה? האם אני צריך להכיר את כולם? וכשאני רוצה לשנות משהו - בכמה אני צריך לגעת: 1? 2? 10?
  • אני חושב שהדבר הכי משמעותי ומה שאנחנו עובדים עליו היום זה ליצור טקסונומיה ל - micro services שלנו וטקסונומיה לעולם העסקי שלנו.
  • הרבה מאוד פעמים במערכת שעוברת הרבה אבולוציה ו - Refactoring - הטקסונומיה מתבלבלת, וכדי לעצור ולהבין: מהם עולמות התוכן שלי? מהם עולמות התוכן של מישהו שעכשיו הגיע, חדש, לקבוצת ההמלצות וצריך לדעת - האם הוא גם צריך להכיר Reviews, או רק את ה - API החיצוני של זה? האם זה נמצא היום בתוך מנגנון ההמלצות או לא? איך שוברים ומפרקים את זה?

כשדיברנו על זה בשיחה המקדימה אמרת שזה גם כולל סיפור מעניין על דיסנילנד . . .
  • אני (עמרי) חובב דיסני מושבע, והרבה מהאנלוגיות שאני מנסה לספר מגיעות מעולם שנקרא Imagineering - ה - Engineers של דיסני, שמסבירים איך לבוא ולייצר חוויות.
    • כשאתה מגיע היום לדיסנילנד, זו חווייה שמאוד דומה לחווייה של תוכניתן חדש . . . יש לכם משהו כמו 10 שעות לעבור כמה שיותר מתקנים, ולמקסם כמה שיותר את החווייה. עבור רוב האנשים זה הביקור הראשון שלהם שם, וזה כולל המון לחץ.
    • הרבה טכניקה מאוד אפקטיבית שדיסני עושים על מנת להפוך את החווייה הזו ליותר קלה היא בזה שהם חילקו את הפארק שלהם (בניגוד ללונה-פארק תל אביב למשל) ל”עולמות” - לכל מקום וכל אטרקציה יש את העולם שלהם, וזה “העולם ההגיוני היחיד שיכול להיות”.
      • למשל - המתקן של אינדיאנה ג’ונס שייך ל Adventures Land - זה המקום היחיד ההגיוני לחפש אותו. 
      • זה גורם לכך שכל מי שמבקר בדיסנילנד (ובהקבלה לתוכניתנים), לא צריך לחפש איפה אינדיאנה ג’ונס (או קוד שאחראי לפונקציונליות מסויימת) נמצא - יש רק מקום אחד הגיוני שבו הוא יהיה.
      • אם אנחנו מצליחים לייצר דבר כזה - והטקסונומיה מספיק אינטואיטיבית - מאוד קל לעשות את הדברים האלה.
אתה מדבר על משהו שבתוכנה קוראים לו מודולוריזציה? . . . הגדרת תת-תחומים והגדרת אחריות שלהם?
  •  הנקודה שבה אנחנו הרבה פעמים מתבלבלים כשעושים מודולוריזציה זה כשחושבים על זה באספקטים טכניים - איך דברים קורים ופחות על מה שהם עושים.
אתה מדבר יותר על Classification לעולמות עסקיים?
  • בדיוק

נרוץ Fast-forward בבגרות של החברה - כל כמה זמן אתה מציע לעשות זה? ברור שזו פעולה לא פשוטה
  • (רן) פשוט - לפי מדד ה-WTF?! 
זה גם נכון, כי גם בדיסני, דברנו קצת על עולם המים ועל Adventures Land, אבל איפה שמים את עשרים אלף מיל מתחת למים”?
  • כנראה שמתחת למים . . .
איך אתה אומר למנכ”ל של Natural Intelligence - “אתה לא יכול ללכת לכיוון העסקי הזה כי זה לא מתאים לטקסונומיה”, או ש”אני לא יודע איפה לשים את זה”?
כנראה שההתפתחות העסקית תיהיה כזו שפעם בכמה זמן צריך לעשות Re-shuffle.
  • נכון מאוד - וזה חלק מהעולם.
  • הנקודה היא  שבסופו של דבר צריך לשמור את האצבע על הדופק, והרבה פעמים מה שקורה זה שאנחנו לא שומרים את האצבע על הדופק, וקצת מנחשים, מוותרים, ממשיכים עם הכיוון . . .

זה גם יכול להיות סוג של “עיוורון” של מי שכבר נמצא שם בפנים, והכל בא לא כל כך טבעי ו”סופר-אינטואיטיבי” - מה לא הגיוני בזה שאינדיאנה ג’ונס נמצא בעולם המים? כי הוא מדי פעם נרטב?
יש יתרון לחדשים (בסגנון “אורח לרגע רואה כל פגע”) - ולך יש את היתרון הזה פעם אחת.
האתגר שאורי ניסה להציג הוא איך לשמור על ה - Freshness הזה? איך אתה מוודא שאתה לא נקלע לאותו פרדוקס של מי שכבר נמצא שם והכל אינטואיטיבי עבורו?
  • בהרבה מקרים זה “פשוט” לבוא ולמדוד - אנשים חדשים תמיד מגיעים, וצריך לשאול אותם איפה הם נתקעים, איפה הם צריכים עזרה.
  • דבר שהראה לנו באופן מאוד ברור שהטקסונומיה שלנו לא ברורה הוא מה שאנחנו מכנים “מדד ה - Tracer Bullet” - אם עבור פיצ’ר אחד אני צריך לגעת ב 4-5 microServices, כנראה שאני לא בונה את הטקסונומיה שלי כמו שצריך, וחלוקת ה - microServices לא ממש נכונה ואולי יש מידול לא נכון של ה - microServices לעולם העסקי.
אתם באמת מודדים את זה? אומרים שהיו שלושה Commits ל - microService שונים עבור הפיצ’ר הזה וכו’?
  • כן
  • יותר מזה - התחלנו למדוד לאחרונה גם משהו שאולי ישמע קצת מוזר: מצד אחד יש לנו תלויות ב - Codebase מסויים (ככל שיש יותר תלויות כך הוא יותר תשתיתי, וצריך להשתנות כמה שפחות). מצד שני - אם כולם נוגעים בו וכולם תלויים בו, זה אומר שכנראה גם שם אולי מתחבא איזשהו microService אחד או יותר שצריך לפצל - מטריקות של יציבות ביחס לתלות (Tracer Bullet) - וזו ההתחלה.

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

רק על מנת לשקף למאזינים / קוראים - חוק קונוואי (Conway Law) אומר בגדול שמבנה התוכנה או המוצר משקף את המבנה הניהולי / ארגוני של החברה - אם יש רכיב אחד אז יש צוות אחד, ואם יש Service אחר אז הוא יהיה באחריות צוות אחר, גם אם זה לא בהכרח הגיוני עסקית. הטענה היא שזה קורה כיוון שזה פשוט הטבע האנושי, שכנראה אוהב Ownership והגדרת אחריות על יחידות עסקיות או קוד או מה שזה לא יהיה. 
  • אם אני רוצה לעשות איזשהו שינוי, אני לא אלך ואבקש ממישהו לשנות אצלו - אני אשנה אצלי, גם אם זה עקום קצת. יותר קל - Path of least resistance. גם אם זה קצת עקום אז שיהיה - זה עדיין יותר קל (דברים זולים עולים פחות).
  • בסופו של דבר - המוצר יוצא “עקום”, כי המבנה הניהולי היה עקום מלכתחילה.
  • מה שאנחנו בעצם אומרים זה שגם בחברות צריך להיות עם אצבע על הדופק - במיוחד בחברות בהן המוצר משתנה או שכח האדם הולך וגדל, צריך גם לשנות את המבנה הארגוני - לא הגיוני שבמשך שנתיים ישאר אותו המבנה שרק “יתפח”, כנראה שצריך לשנות משהו במבנה - בין אם זה חלוקה לצוותים יותר קטנים או לפי צרכים עסקיים: לסגור צוות, לפתוח אחד חדש וכו’.
  • (אורי) לפעמים החוק כל כך משתלט עלינו עד שאנחנו אומרים “רגע  - למה עכשיו להתחיל להזיז צוותים או Business Domains . . .המערכת כבר בנויה ככה”. מפה לשם - זה הופך למעיין משקולת על הגמישות, על ה - Velocity . . .
  • (עמרי) נכון - הנה דוגמא קטנה על דילמה כזו שנוצרה אצלנו: תמיד יש את המתח במקרה של microServices קטנים מאוד, שעבורם זה פשוט להעביר את ה microService בשלמותו בין צוותים (כשצוות למשל מסיים את עבודתו, או כאשר צוות אחר צריך לבוא ולקחת אחריות), ומצד שני - אנחנו רוצים לייצר microServices יותר גדולים, שיותר נוח לשמור עבורם את ה - context ולקחת עליהם אחריות בתור צוות.
    • היום זו מעיין מטוטלת, ואם בתקופה מסויימת היינו עם  microServices יחסית גדולים (“מיני-מונוליטים”) ולאט-לאט הלכנו לכיוון של microService לכל Entity, היום המטוטלת חוזרת קצת.
זה קורה בכל השוק . . . גם כמגמה וגם בחברות - בסופו של דבר אולי נמצא מתישהו איזשהו איזון, אבל בינתיים השוק הלך “בטרפת” לכיוון של microServices, ובאיזשהו שלב הבנו שזה אולי קצת יותר מדי.
  • “כולם מדברים עם כולם” זה נורא מסובך - אולי נתחיל לאחד למונוליטים קטנים?
  • הנקודה שבא אני צריך לדבר עם עצמי דרך microService היא הנקודה בא צריך כנראה לשאול שאלה . . .

איפה אתם היום? האם בתשעת החודשים הללו אתה כבר רואה איזשהו הבדל? המגוייסים החדשים כבר מחייכים?
  • יש כמה הבדלים שהתחלנו לבנות לאורך הדרך
  • דבר אחד שהתחיל לפני והתעצם לאורך התהליך זה NI - Intelligence Starts Here - בסופו של דבר יש לנו היום Read-Me, גם טקסטואלי וגם בקוד (סקריפטים), כך שהיום יש לי סביבה מאוד גדולה וכשאני רוצה להריץ אותה - ורוצה להבין את כל ה - Best Practices ואיך להריץ אותה לוקאלית - אני יכול לעשות את זה “ברמה של קליק”.
  • דבר נוסף - הרבה מאוד פעמים ובהרבה מאוד מה - microServices שלנו, שיש מאחוריהם הרבה מאוד החלטות ארכיטקטוניות וערכים, Design Principles . . .
  • רגע חזרה לאייטם הקודם - אתה בעצם אומר שעכשיו למפתח חדש שמגיע יש מעיין “Natural Intelligence in a Box”? הוא מריץ סקריפט, ויש לו את כל סביבת ה-Production (או לפחות את מה שהגיוני מתוכה) אצלו על הלפטופ - והוא יכול “להתחיל לשחק”? לשנות פה או שם, לראות מה זה כל ה - Services האלה . . .
  • נכון - ויותר מזה: יש לו כבר Guidance, טרי וברמה גבוהה (לנו כמהנדסים זה יותר קשה מאשר לכתוב את הסקריפטים…) - תיעוד שמסביר: אם אני רוצה לבוא ולעשות פעולות בסיסיות - מה המשמעות של זה? איפה אני צריך לדעת? איפה לחפש? ממה אני צריך להיזהר? כל האספקטים האלה בסופו של דבר - כל מה שלמדנו בדרך הקשה - אנחנו כותבים אותם.
  • יותר מזה - האופן שבו אנחנו כותבים אותם זה בצורה של Flows או Jobs to be Done - דברים שצריך לעשות: אם אני רוצה להוסיף יכולת מסויימת - מה אני צריך? על מה אני צריך לחשוב? איפה אני צריך לעשות את זה?
אתה בעצם נותן מעיין “מתכונים” למפתחים החדשים . . . וזה עובד? אתם משתמשים בזה? אתה מצליח לחשוב על הכל מראש? אני לדמיין שאולי חשבת על עשרה מתכונים מסויימים ועדיין - המפתח צריך דווקא מתכון ספציפי אחר. יש לך איזושהי דרך למדוד את האפקטיביות של זה?
  • בסופו של דבר זה נמדד ב - High Level Designs: יוצאים מה- HLD ורואים כמה מהם הם פשוט More of the same.
    • עד כמה באמת הצלחנו להשתמש במתכונים האלה על מנת לעזור לתוכניתן חדש לבוא, להיכנס - ולייצר HLD חדש ואיכותי, גם מבלי לעשות את כל המחקר. זו טכניקה אחת שהיא מאוד אפקטיבית.
  • ושוב - פשוט מקשיבים, ואם צריך מתכון חדש, אז יוצרים גם אותו.

אני (אורי) יכול להגיד שלמפתח חדש ב- Outbrain יש Boot-camp
  • כמה זמן? זה לא נמדד בזמן אלא משהו אישי - קצת כמו קורס אינטרנטי: אתה עובר משימות שמכניסות אותך ממש לתוך העולם של הפיתוח.
  • המשימה הלפני-אחרונה היא לנקות את הסביבה שלך” - כל סביבת הניסיונות שעשית עד עכשיו.
  • המשימה האחרונה היא לכתוב לנו פידבק - כדי שנוכל להשתפר לפעמים הבאות.
  • מי שמחזיק את ה-Boot-camp הזה ומאפשר אותו ועובד עליו, וגם יושב ב-1:1 ומקבל פידבק מהמפתחים, זה הצוות Developer Experience (פרק 367 למיטיבי שמע), שבונה ומשפר כל הזמן - וגם נמצא בקשר רציף עם המפתחים.

אצלכם (עמרי) יש צוות כזה, של Developer Experience? או מישהו עם כובע כזה?
  • עדיין לא - עדיין לא גדלנו לדבר כזה, אבל נאמר זאת ככה, לפחות בערכים שלי - אני חושב שזה צריך להיות חלק מהאחריות של כל אחד מהמפתחים.
  • אני לא בטוח שזה סוג ה - Ownership שהייתי רוצה לתת לצוות שזה תפקידו, ואלו המטרות (Goals) שלו.
במקרה הזה (של Outbrain) הצוות הוא כזה שתפקידו לייצר Tools שכל הזמן יעשו את החיים של המפתחים ליותר ויותר טובים.

(רן) דרך אגב - דיברנו קודם לכן על מדד שנקרא Time to First Commit: כמה זמן עבר “מאז שהתגייסתי ועד שעשיתי את ה - Commit הראשון”, ודיברנו על זה במונחים של פרודוקטיביות של מפתח, משמע - מהפן “הכלכלי”.
יש גם צד נוסף - הצד המוראלי: מפתח חדש שמגיע לחברה רוצה להרגיש בעל ערך, רוצה להרגיש שהוא (קודם כל) On top of things ומצליח, וחוץ מזה - שיש לו ערך: המשכורת שמשלמים לו היא לא “סתם”, אלא שהוא באמת מצליח להיות פרודוקטיבי. ההרגשה הזו - ככל שהיא תגיע יותר מוקדם, כך ייטב למפתח ולחברה, וזה משהו שחשוב לזכור. זה באמת לא רק עניין כלכלי (ישירות) אלא גם עניין מוראלי.
(אורי) זה גם עניין של בטחון עצמי - “איבדת את בתולי ה - Production שלך” (לא בטוח שהביטוי הזה היה בשימוש אי-פעם איפשהו . . .). עכשיו הצטרפת לחברה, “עברת את הזובור הראשון” (זה כנראה כן היה בשימוש בעבר), אתה עכשיו “חלק מהחבר’ה”.
זכור לי (רן) חברה שהייתה עושה את זה בזמן ראיון עבודה - נותנת למועמד תרגיל, משהו כמו לתקן Bug יחסית פשוט, ותוך כדי הראיון היו עושים Deploy to Production. מועמדים היו יוצאים מהראיונות בתחושה של “וואו - הם עושים דברים מדהימים”  -בונה תדמית שלא רק שהמערכת שלהם חסינה, וגם אם עשיתי שטות היא תתפוס אותי, אלא גם שהם מאוד מעריכים את הפרודוקטיביות שלי, ואני כנראה ארגיש טוב בחברה הזו ברגע שאגיע לשם - אם כבר בראיון עבודה הצלחתי לעשות Commit to Production, ביום הראשון אני כבר הולך לבנות שם מוצר מדהים.
כמובן שלא תמיד הדברים הם ככה, אבל בתיאוריה זה נותן למועמד תחושה מאוד טובה בראיון - וזה גם משהו שצריך לשים אליו לב: זה באמת לא רק עניין של פרודוקטיביות אלא גם עניין מוראלי, ואנשים רוצים שהמפתחים ירגישו טוב כמה שיותר מהר.

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

יש עוד נושאים שרצית להזכיר לפני שאנחנו מסיימים?
  • דבר אחד אחרון - כאב אחד מאוד משמעותי שאני (עמרי) חווה אותו כשאני עובר מחברה לחברה, או אפילו ממוצר למוצר באותה החברה: עניין הטרמינולוגיה . . .
  • אנחנו כתוכניתנים, איך אומרים - “Naming things זה הדבר הכי קשה אחרי Caching?” אני טוען שזה הדבר הראשון, ואנחנו כנראה לא נותנים לזה מספיק כבוד.
בדיוק היום כתבתי (רן) מסמך על Naming ותפסתי את הראש עם “למה התנדבתי לעשות את הדבר הזה?” . . . 
  • יש לנו נטייה לבוא ולעשות כל מיני דברים שבדיעבד הם לא מאוד חכמים - דבר אחד שאנחנו מאוד אוהבים זה להמציא טרמינולוגיה משלנו, ובעיקר Pan names: אני מניח שלכל אחד יש איפשהו במערכת איזשהו מודול עם שם “סקסי” שמבוסס על דמות מ - Star Wars (זה לא רק אני?!), מיתולוגיה הודית וכאלה . . . 
    • מחרתיים יגיע מישהו חדש, שאולי המיתולוגיה ההודית היא לא His cup of Chai . . .
    • אבל אולי המיתולוגיה השוודית כן? בכל מקרה - עכשיו הוא מבולבל
    • למדתי להעריך את “השמות המשעממים”, ולהגביל עד כמה שאני יכול את השמות ה”קוליים” ואת ה-Pan names.
  • הדבר השני הוא טרמינולגיה שהיא “טעונה” - יש לנו הרבה מאוד פעמים נטייה לבוא ולהשתמש בטרמינולגיה שכבר השתמשו בה במקרים אחרים ועבור עולמות אחרים.
    • לא יאמן כמה פעמים שמעתי את המושג Segment מתייחס לכל מיני דברים אחרים, את מושג Recommendation מתייחס לכל מיני דברים אחרים, וכנ”ל עבור Review ו - User ומה לא . . . גם Context - זה היה כנראה היה הפושע מספר 1 ברשימות שלי.
    • משהו מאוד משמעותי שאנחנו צריכים לבוא ולחשוב עליו זה איך אנחנו נותנים שמות שהם כאלה שעוזרים לנו להבין את ה - Context של ה - Context.
    • יש הבדל בין Segment לבין User Segment לבין Marketing Segment ועוד דברים כאלה - חשוב לחשוב פעמיים ולנסות לייצר מצב שבו אין עמימות (Ambiguity) בשמות שאנחנו נותנים . . . 
קודם כל אני (רן) מזדהה עם הנימה, אבל עדיין - אני שואל את עצמי: איך אנחנו עושים שזה יקרה, זאת אומרת - האם אתה הולך ומטיף מראש הגבעה “חבר’ה, די! תעשו Naming כמו שצריך?” איך זה עובד? איך אתה משפר את ה - Naming אצלך, בסביבה הקרובה?
  • הדרך הכי פשוטה - Code Reviews, או Design Reviews
    • אני בתור תוכניתן שמנסה לבוא ולשפוט את עצמי, שנייה לפני שאני “נותן שיתפסו אותי” ב - Code Review, זה לעשות חיפוש באינטרנט ולהבין מהי הטרמינולוגיה, ולעשות חיפוש ב  -Codebase כדי לראות האם אולי בתוך ה - Codebase יש טרמינולגיה דומה אבל אולי לא עקבית (Consistent).
    • אלא שני דברים מאוד קלים שאני יכול לעשות תוך עניין של דקות, ופשוט לשפר את ה - Naming ואת הטרמינולגיה שלי בצורה מאוד משמעותית.
זו אחת מעשרת הדברות, לא? “לא תישא את שם ה - Service שלך לשווא”? או משהו כזה . . .
אני (אורי) יכול להגיד שבתור CTO, יש כבר מספיק Codebase שאני בטח לא מכיר, ומשהו כמו 300 Services שונים . . . אם זורקים לי שם של Service אין לי מושג מה הוא עושה, ואני צריך שתסביר לה מה בדיוק - וזה מתפתח להסבר של כל הארכיטקטורה . . .
מעניין, דרך אגב, לחשוב האם גם פה אפשר למצוא איזשהו מדד - עד כמה  Context (וסליחה לעמרי על השימוש במילה בהקשר דומה) נדרש לך על מנת להבין מה ה - service עושה? יש כאן איזשהו עניין של Cohesion לעומת המושג השני ש Kent Beck טבע - Coupling - כלומר: Cohesion לעומת Coupling - ככל שה - Cohesion יותר גדול זה אומר שה- Coupling כנראה חזק מדי, וצריך עשות איזשהו Refactoring.

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


הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול