התחל במצב לא מקוון עם האפליקציה Player FM !
378 Intuitive codebases with Omri Fima
סדרה בארכיון ("עדכון לא פעיל" status)
When? This feed was archived on December 02, 2020 11:09 (). Last successful fetch was on October 23, 2020 02:18 ()
Why? עדכון לא פעיל status. השרתים שלנו לא הצליחו לאחזר פודקאסט חוקי לזמן ממושך.
What now? You might be able to find a more up-to-date version using the search function. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.
Manage episode 243608252 series 2523706
- עמרי - כיום ארכיטקט ב - Natural Intelligence, ש”עוזרת לצרכנים לקבל החלטות” - היום בעולם הצרכנות יש המון החלטות שאנחנו צריכים לקבל (ממשכנתא, ביטוח, DNA Kits ועד מזגן, מקרר, מכונות כביסה וכו’).
- אנחנו יודעים לעשות את המחקר באינטרנט ולעזור לאנשים להבין מה חשוב, מה לא חשוב, ואיך לבחור נכון.
- יש הרבה מאוד תהליכים - מנועי המלצות, או “פשוט לסרוק את האינטרנט”, להבין ולעשות ניתוח - ובהרבה מקרים זה אנשים שעושים מחקר ומנסים להבין מה באמת חשוב בכל עולם תוכן ובכל תעשייה, על מנת לעזור לכל אחד לקבל החלטה.
- ומן הסתם - יש גם אתגר של לנסות להפוך את כל זה לאוטומטי: רק חלק מהאתגר של לנסות לגדול מ-150 עולמות תוכן לכיון ה-3,000-4,000 ואולי הרבה יותר.
- מגאסון . . . יש מספר או שלא סופרים? ויש גם את האטארי של אבא, אבל זה עוד היה בשחור-לבן.
- האהבה לעולם התוכנה התחילה עם מה שילדי שנות ה-90’ זוכרים כמשחק קליק ובניית משחקים - החל מ-Visual Basic, עתודאי בצבא (חיל אוויר), בניתי דברים שונים ומשונים.
- בחמש השנים שלפני Natural Intelligence עבדתי ב - Sears Israel - בנינו אתרי קניות, ועשיתי שם הכל מהכל: החל מ-SRE (דאגתי שהאתר לא ייפול ב - Black Friday . . .), דרך עולמות של המלצות, ניתוח טקסט, ניתוח סנטימנטים, מה משתמשים אוהבים ומה מעניין אותם - ואפילו עד עולמות של IOT ובניית מכשירים חכמים.
- לפני כ-9 חודשים הצטרפתי ל - Natural Intelligence בתפקיד ארכיטקט, ולמעשה כל הנושא של Intuitive Codebases מדבר הרבה מאוד על החווייה האישית שלי (עמרי) בתור תוכניתן חדש בסופו של יום, שמנסה להבין מה לעזאזל קורה פה . . .
- אוהב לדבר, אוהב לבנות - לשם כך התכנסנו היום.
- אחד הדברים שהכי הפתיעו אותי היה שביום שבו הגעתי לחברה - הגעתי יחד עם עוד 26 אנשים… לא כולם Engineers, אבל הרבה מאוד כן, כאלו שבאו ועברו את החווייה יחד איתי, כמעיין “חווייה קבוצתית”.
- יותר מזה - חודש אחרי הגיעה עוד כמות דומה, ובחודש שאחרי - עוד כמות גדולה.
- בגדול - כמעט בכל חודש מתווספים משהו כמו עשרה מהנדסים לחברה. להכשיר את כולם זה קשה (ולהכשיר אותי גם היה קשה).
- אז ניסיתי לחשוב אילו דברים היו טובים בתהליך הזה ומה אפשר לשפר - כי נראה שמהנדסים הולכים להמשיך להצטרף, ושווה לראות מה אפשר ללמוד על זה.
- מצד אחד יש הרבה Codebase, ומצד שני - זו חברה שעדיין עוברת תהליך גידול אקספוננציאלי.
- יש הרבה Codebase Legacy, אבל גם משכתבים את המערכות לטכנולוגיות מודרניות - וגם אנחנו “נאלצים” להתמודד עם כמויות של אנשים וצוותים שהחברה לא הכירה בעבר.
- לפחות דבר אחד היה טוב בתוך התהליך הזה - עברנו מעיין “אקדמיה”: סט של הרצאות שמטרתן הייתה להכניס אותנו לאט ובזהירות.
- הרצאות - וגם מעיין התנסות: לנסות וליצור איזשהו פיצ’ר מסויים מקצה לקצה.
- התהליך של האקדמיה לקח משהו כמו שבועיים וחצי - ואני שואל את עצמי למה זה אמור לקחת שבועיים וחצי? איך אפשר להגיע למצב שבו זה ייקח פחות?
- מסתבר שיש הרבה מאוד סיבות, Anti-patterns ו-Best Practices שאנחנו כמהנדסים אוהבים לבוא ולעשות.
- קודם כל - מסיבות כאלו ואחרות, אנחנו לא אוהבים להיות קונסיסטנטיים (Consistent): לא בין ידע העבר שיש ולא מניסיון ממקומות קודמים וידע מהתעשייה לבין מה שקורה במקום חדש - יש לנו הרבה מאוד אהבה להמציא את הגלגל מחדש, להמציא טרמינולוגיה מחדש, וזו צרה אחת.
- מפתחים, גם כשהם מנוסים - הידע שקיים אצלם לא בהכרח ניתן להפעלה (Exercise) בצורה מהירה ומיידית על Codebase חדש ועל עולם חדש.
- מבחינת Stack טכנולוגי - היית בעולם שאתה מכיר? בגדול כן, ובגדול טכנולוגיה זה לא האספקט הקשה. אנחנו עובדים ב - Stack יחסית סטנדרטי: Slack, Node.js, Kubernetes - לא משהו שהתעשייה לא מכירה.
- אבל - כל חברה היום לוקחת את “הטוויסט” שלה, וזה בא לידי ביטוי (איך שאני רואה את זה) בעיקר בארכיטקטורה של המוצר.
- מה הכוונה? בסופו של דבר הצורה בה אני תופס ארכיטקטורה של מוצר אינה בהכרח סט המחלקות או המודולים, אלא סט הערכים.
- כשאנחנו באים לבנות מוצר ובאים לבנות ארכיטקטורה, בין אם אנחנו מתכוונים לזה ובין אם לאו - הקוד מייצג את הערכים של הארגון.
- ננסה דוגמא - בחברה הקודמת (Sears), משהו מאוד חשוב היה ורסטיליות (Versatility) של אנשים: היכולת לעבור מפרויקט לפרויקט, כך שאם יש עכשיו את הדבר הלוהט הבא אפשר לקפוץ לשם - והיו לזה משמעויות בארכיטקטורה שלנו -
- העדפנו מבנה של מונוליט - מצב של Codebase אחד שנמצא במקום אחד שזמין לכולם, וקל ומותר לגעת בכל דבר, וגם הכל נראה אותו הדבר לאורך כל המערכות.
- הכוונה ל-Mono-Repo או ל - Monolith?
- בהרבה מאוד מובנים Monolith, גם לפי הרבה עקרונות אחרים - למשל: החלטנו לוותר באופן מודע על פוליגלוטיות (Polyglot Programming), לבוא ולומר שלא משנה איך אתה “משחק את המשחק”, אתה תשחק באותה צורה; הרבה דברים יראו אותו הדבר, במידה מסויימת גם במחיר של ויתור על עקרונות של Loosely-coupled - כי אנחנו רואים ערך בזה שהכל נוגע בהכל ותוכניתנים יכולים לגעת בהכל, ושתוכניתן יכול להבין את המשמעות של מה שהוא עושה.
- אוקיי, אז לא היה מונוליט אחד - היו ארבעה . . וכן - בסופו של יום היה בזה ערך, כי ה - codebase היה משותף וכולם הכירו את הקוד של כולם ולא משנה באיזה צוות היית.
- במידה מסויימת היינו מספיק קטנים על מנת להצליח להחזיק את הערכים האלה.
- לעומת זאת - עכשיו ב - Natural Intelligence יש ערכים חדשים - וה - Codebase צריך לייצג את זה.
- “פתאום” אנחנו הרבה יותר גדולים - אז צריך לדבר על אחריות, ואיזורי אחריות, ו - Business Domains, וצריך לדבר על זה שאנחנו לא רק גדולים אלא גם גדלים מאוד מהר, אז צריך לדבר על המשמעות של הכנסת המהנדס הבא - איך אנחנו גורמים לזה שהרבה מאוד מההחלטות ההנדסיות שקיבלנו מאוד ברורות ואינטואיטיביות (Intuitive Codebases) ולא צריך לשאול וכל הזמן ללוות את המהנדס הבא “ולהחזיק לו את היד בדרך לפרודוקטיביות”.
- כמה דברים שעשינו בדרך היו מעבר מאוד חד ל - 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 - זה המקום היחיד ההגיוני לחפש אותו.
- זה גורם לכך שכל מי שמבקר בדיסנילנד (ובהקבלה לתוכניתנים), לא צריך לחפש איפה אינדיאנה ג’ונס (או קוד שאחראי לפונקציונליות מסויימת) נמצא - יש רק מקום אחד הגיוני שבו הוא יהיה.
- אם אנחנו מצליחים לייצר דבר כזה - והטקסונומיה מספיק אינטואיטיבית - מאוד קל לעשות את הדברים האלה.
- הנקודה שבה אנחנו הרבה פעמים מתבלבלים כשעושים מודולוריזציה זה כשחושבים על זה באספקטים טכניים - איך דברים קורים ופחות על מה שהם עושים.
- בדיוק
- (רן) פשוט - לפי מדד ה-WTF?!
- כנראה שמתחת למים . . .
- נכון מאוד - וזה חלק מהעולם.
- הנקודה היא שבסופו של דבר צריך לשמור את האצבע על הדופק, והרבה פעמים מה שקורה זה שאנחנו לא שומרים את האצבע על הדופק, וקצת מנחשים, מוותרים, ממשיכים עם הכיוון . . .
- בהרבה מקרים זה “פשוט” לבוא ולמדוד - אנשים חדשים תמיד מגיעים, וצריך לשאול אותם איפה הם נתקעים, איפה הם צריכים עזרה.
- דבר שהראה לנו באופן מאוד ברור שהטקסונומיה שלנו לא ברורה הוא מה שאנחנו מכנים “מדד ה - Tracer Bullet” - אם עבור פיצ’ר אחד אני צריך לגעת ב 4-5 microServices, כנראה שאני לא בונה את הטקסונומיה שלי כמו שצריך, וחלוקת ה - microServices לא ממש נכונה ואולי יש מידול לא נכון של ה - microServices לעולם העסקי.
- כן
- יותר מזה - התחלנו למדוד לאחרונה גם משהו שאולי ישמע קצת מוזר: מצד אחד יש לנו תלויות ב - Codebase מסויים (ככל שיש יותר תלויות כך הוא יותר תשתיתי, וצריך להשתנות כמה שפחות). מצד שני - אם כולם נוגעים בו וכולם תלויים בו, זה אומר שכנראה גם שם אולי מתחבא איזשהו microService אחד או יותר שצריך לפצל - מטריקות של יציבות ביחס לתלות (Tracer Bullet) - וזו ההתחלה.
- אחד האתגרים הוא באמת שעבור ארגונים בגדילה - המשיכה הזו משתנה כל כמה חודשים: האיזור שבמוקד או הצוות-הגדול-מדי-וצריך-להתפצל . . . Conway Law אולי טוב כשיש יציבות (כן?), אבל יותר מבלבל במצבי כאוס.
- כן - אבל אם כיוון הכוח משתנה כל חודשיים אז אולי צריך, לפחות במידה מסויימת, להתנגד אליו, או - עם כל הכבוד לחוק - לפעמים לעזור למבנה הארגוני להתאים לארכיטקטורה, או להיפך. זה עניין דו-כיווני.
- אם אני רוצה לעשות איזשהו שינוי, אני לא אלך ואבקש ממישהו לשנות אצלו - אני אשנה אצלי, גם אם זה עקום קצת. יותר קל - Path of least resistance. גם אם זה קצת עקום אז שיהיה - זה עדיין יותר קל (דברים זולים עולים פחות).
- בסופו של דבר - המוצר יוצא “עקום”, כי המבנה הניהולי היה עקום מלכתחילה.
- מה שאנחנו בעצם אומרים זה שגם בחברות צריך להיות עם אצבע על הדופק - במיוחד בחברות בהן המוצר משתנה או שכח האדם הולך וגדל, צריך גם לשנות את המבנה הארגוני - לא הגיוני שבמשך שנתיים ישאר אותו המבנה שרק “יתפח”, כנראה שצריך לשנות משהו במבנה - בין אם זה חלוקה לצוותים יותר קטנים או לפי צרכים עסקיים: לסגור צוות, לפתוח אחד חדש וכו’.
- (אורי) לפעמים החוק כל כך משתלט עלינו עד שאנחנו אומרים “רגע - למה עכשיו להתחיל להזיז צוותים או Business Domains . . .המערכת כבר בנויה ככה”. מפה לשם - זה הופך למעיין משקולת על הגמישות, על ה - Velocity . . .
- (עמרי) נכון - הנה דוגמא קטנה על דילמה כזו שנוצרה אצלנו: תמיד יש את המתח במקרה של microServices קטנים מאוד, שעבורם זה פשוט להעביר את ה microService בשלמותו בין צוותים (כשצוות למשל מסיים את עבודתו, או כאשר צוות אחר צריך לבוא ולקחת אחריות), ומצד שני - אנחנו רוצים לייצר microServices יותר גדולים, שיותר נוח לשמור עבורם את ה - context ולקחת עליהם אחריות בתור צוות.
- היום זו מעיין מטוטלת, ואם בתקופה מסויימת היינו עם microServices יחסית גדולים (“מיני-מונוליטים”) ולאט-לאט הלכנו לכיוון של microService לכל Entity, היום המטוטלת חוזרת קצת.
- “כולם מדברים עם כולם” זה נורא מסובך - אולי נתחיל לאחד למונוליטים קטנים?
- הנקודה שבא אני צריך לדבר עם עצמי דרך 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 חדש ואיכותי, גם מבלי לעשות את כל המחקר. זו טכניקה אחת שהיא מאוד אפקטיבית.
- ושוב - פשוט מקשיבים, ואם צריך מתכון חדש, אז יוצרים גם אותו.
- כמה זמן? זה לא נמדד בזמן אלא משהו אישי - קצת כמו קורס אינטרנטי: אתה עובר משימות שמכניסות אותך ממש לתוך העולם של הפיתוח.
- המשימה הלפני-אחרונה היא “לנקות את הסביבה שלך” - כל סביבת הניסיונות שעשית עד עכשיו.
- המשימה האחרונה היא לכתוב לנו פידבק - כדי שנוכל להשתפר לפעמים הבאות.
- מי שמחזיק את ה-Boot-camp הזה ומאפשר אותו ועובד עליו, וגם יושב ב-1:1 ומקבל פידבק מהמפתחים, זה הצוות Developer Experience (פרק 367 למיטיבי שמע), שבונה ומשפר כל הזמן - וגם נמצא בקשר רציף עם המפתחים.
- עדיין לא - עדיין לא גדלנו לדבר כזה, אבל נאמר זאת ככה, לפחות בערכים שלי - אני חושב שזה צריך להיות חלק מהאחריות של כל אחד מהמפתחים.
- אני לא בטוח שזה סוג ה - Ownership שהייתי רוצה לתת לצוות שזה תפקידו, ואלו המטרות (Goals) שלו.
- איך אומרים - בכל פעם שאנחנו מתקרבים, המטרה זזה . . . זו המציאות, אבל אני חושב שאם יש משהו שהוא לפחות משמעותי ב”לשים את אצבע על הדופק”, זה שלפחות אנחנו מנסים לשמור על מצב שהוא לא יתדרדר - ואנחנו יודעים למדוד את עצמנו, ואנחנו יודעים לבוא ולאמר מתי אנחנו מצליחים ומתי אנחנו לא מצליחים.
- וזו עבודה של כנראה יותר מחצי שנה ויותר מהתקופה שבא אני נמצא - וכנראה שלשנה הקרובה תמיד יהיו את קפיצות המדרגה הללו . . .
- כן - כנראה. ועם הגדילה זה כנראה יהיה יותר כואב - ובסוף יהיה גם יותר טוב.
- דבר אחד אחרון - כאב אחד מאוד משמעותי שאני (עמרי) חווה אותו כשאני עובר מחברה לחברה, או אפילו ממוצר למוצר באותה החברה: עניין הטרמינולוגיה . . .
- אנחנו כתוכניתנים, איך אומרים - “Naming things זה הדבר הכי קשה אחרי Caching?” אני טוען שזה הדבר הראשון, ואנחנו כנראה לא נותנים לזה מספיק כבוד.
- יש לנו נטייה לבוא ולעשות כל מיני דברים שבדיעבד הם לא מאוד חכמים - דבר אחד שאנחנו מאוד אוהבים זה להמציא טרמינולוגיה משלנו, ובעיקר Pan names: אני מניח שלכל אחד יש איפשהו במערכת איזשהו מודול עם שם “סקסי” שמבוסס על דמות מ - Star Wars (זה לא רק אני?!), מיתולוגיה הודית וכאלה . . .
- מחרתיים יגיע מישהו חדש, שאולי המיתולוגיה ההודית היא לא His cup of Chai . . .
- אבל אולי המיתולוגיה השוודית כן? בכל מקרה - עכשיו הוא מבולבל
- למדתי להעריך את “השמות המשעממים”, ולהגביל עד כמה שאני יכול את השמות ה”קוליים” ואת ה-Pan names.
- הדבר השני הוא טרמינולגיה שהיא “טעונה” - יש לנו הרבה מאוד פעמים נטייה לבוא ולהשתמש בטרמינולגיה שכבר השתמשו בה במקרים אחרים ועבור עולמות אחרים.
- לא יאמן כמה פעמים שמעתי את המושג Segment מתייחס לכל מיני דברים אחרים, את מושג Recommendation מתייחס לכל מיני דברים אחרים, וכנ”ל עבור Review ו - User ומה לא . . . גם Context - זה היה כנראה היה הפושע מספר 1 ברשימות שלי.
- משהו מאוד משמעותי שאנחנו צריכים לבוא ולחשוב עליו זה איך אנחנו נותנים שמות שהם כאלה שעוזרים לנו להבין את ה - Context של ה - Context.
- יש הבדל בין Segment לבין User Segment לבין Marketing Segment ועוד דברים כאלה - חשוב לחשוב פעמיים ולנסות לייצר מצב שבו אין עמימות (Ambiguity) בשמות שאנחנו נותנים . . .
- הדרך הכי פשוטה - Code Reviews, או Design Reviews
- אני בתור תוכניתן שמנסה לבוא ולשפוט את עצמי, שנייה לפני שאני “נותן שיתפסו אותי” ב - Code Review, זה לעשות חיפוש באינטרנט ולהבין מהי הטרמינולוגיה, ולעשות חיפוש ב -Codebase כדי לראות האם אולי בתוך ה - Codebase יש טרמינולגיה דומה אבל אולי לא עקבית (Consistent).
- אלא שני דברים מאוד קלים שאני יכול לעשות תוך עניין של דקות, ופשוט לשפר את ה - Naming ואת הטרמינולגיה שלי בצורה מאוד משמעותית.
25 פרקים
סדרה בארכיון ("עדכון לא פעיל" status)
When? This feed was archived on December 02, 2020 11:09 (). Last successful fetch was on October 23, 2020 02:18 ()
Why? עדכון לא פעיל status. השרתים שלנו לא הצליחו לאחזר פודקאסט חוקי לזמן ממושך.
What now? You might be able to find a more up-to-date version using the search function. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.
Manage episode 243608252 series 2523706
- עמרי - כיום ארכיטקט ב - Natural Intelligence, ש”עוזרת לצרכנים לקבל החלטות” - היום בעולם הצרכנות יש המון החלטות שאנחנו צריכים לקבל (ממשכנתא, ביטוח, DNA Kits ועד מזגן, מקרר, מכונות כביסה וכו’).
- אנחנו יודעים לעשות את המחקר באינטרנט ולעזור לאנשים להבין מה חשוב, מה לא חשוב, ואיך לבחור נכון.
- יש הרבה מאוד תהליכים - מנועי המלצות, או “פשוט לסרוק את האינטרנט”, להבין ולעשות ניתוח - ובהרבה מקרים זה אנשים שעושים מחקר ומנסים להבין מה באמת חשוב בכל עולם תוכן ובכל תעשייה, על מנת לעזור לכל אחד לקבל החלטה.
- ומן הסתם - יש גם אתגר של לנסות להפוך את כל זה לאוטומטי: רק חלק מהאתגר של לנסות לגדול מ-150 עולמות תוכן לכיון ה-3,000-4,000 ואולי הרבה יותר.
- מגאסון . . . יש מספר או שלא סופרים? ויש גם את האטארי של אבא, אבל זה עוד היה בשחור-לבן.
- האהבה לעולם התוכנה התחילה עם מה שילדי שנות ה-90’ זוכרים כמשחק קליק ובניית משחקים - החל מ-Visual Basic, עתודאי בצבא (חיל אוויר), בניתי דברים שונים ומשונים.
- בחמש השנים שלפני Natural Intelligence עבדתי ב - Sears Israel - בנינו אתרי קניות, ועשיתי שם הכל מהכל: החל מ-SRE (דאגתי שהאתר לא ייפול ב - Black Friday . . .), דרך עולמות של המלצות, ניתוח טקסט, ניתוח סנטימנטים, מה משתמשים אוהבים ומה מעניין אותם - ואפילו עד עולמות של IOT ובניית מכשירים חכמים.
- לפני כ-9 חודשים הצטרפתי ל - Natural Intelligence בתפקיד ארכיטקט, ולמעשה כל הנושא של Intuitive Codebases מדבר הרבה מאוד על החווייה האישית שלי (עמרי) בתור תוכניתן חדש בסופו של יום, שמנסה להבין מה לעזאזל קורה פה . . .
- אוהב לדבר, אוהב לבנות - לשם כך התכנסנו היום.
- אחד הדברים שהכי הפתיעו אותי היה שביום שבו הגעתי לחברה - הגעתי יחד עם עוד 26 אנשים… לא כולם Engineers, אבל הרבה מאוד כן, כאלו שבאו ועברו את החווייה יחד איתי, כמעיין “חווייה קבוצתית”.
- יותר מזה - חודש אחרי הגיעה עוד כמות דומה, ובחודש שאחרי - עוד כמות גדולה.
- בגדול - כמעט בכל חודש מתווספים משהו כמו עשרה מהנדסים לחברה. להכשיר את כולם זה קשה (ולהכשיר אותי גם היה קשה).
- אז ניסיתי לחשוב אילו דברים היו טובים בתהליך הזה ומה אפשר לשפר - כי נראה שמהנדסים הולכים להמשיך להצטרף, ושווה לראות מה אפשר ללמוד על זה.
- מצד אחד יש הרבה Codebase, ומצד שני - זו חברה שעדיין עוברת תהליך גידול אקספוננציאלי.
- יש הרבה Codebase Legacy, אבל גם משכתבים את המערכות לטכנולוגיות מודרניות - וגם אנחנו “נאלצים” להתמודד עם כמויות של אנשים וצוותים שהחברה לא הכירה בעבר.
- לפחות דבר אחד היה טוב בתוך התהליך הזה - עברנו מעיין “אקדמיה”: סט של הרצאות שמטרתן הייתה להכניס אותנו לאט ובזהירות.
- הרצאות - וגם מעיין התנסות: לנסות וליצור איזשהו פיצ’ר מסויים מקצה לקצה.
- התהליך של האקדמיה לקח משהו כמו שבועיים וחצי - ואני שואל את עצמי למה זה אמור לקחת שבועיים וחצי? איך אפשר להגיע למצב שבו זה ייקח פחות?
- מסתבר שיש הרבה מאוד סיבות, Anti-patterns ו-Best Practices שאנחנו כמהנדסים אוהבים לבוא ולעשות.
- קודם כל - מסיבות כאלו ואחרות, אנחנו לא אוהבים להיות קונסיסטנטיים (Consistent): לא בין ידע העבר שיש ולא מניסיון ממקומות קודמים וידע מהתעשייה לבין מה שקורה במקום חדש - יש לנו הרבה מאוד אהבה להמציא את הגלגל מחדש, להמציא טרמינולוגיה מחדש, וזו צרה אחת.
- מפתחים, גם כשהם מנוסים - הידע שקיים אצלם לא בהכרח ניתן להפעלה (Exercise) בצורה מהירה ומיידית על Codebase חדש ועל עולם חדש.
- מבחינת Stack טכנולוגי - היית בעולם שאתה מכיר? בגדול כן, ובגדול טכנולוגיה זה לא האספקט הקשה. אנחנו עובדים ב - Stack יחסית סטנדרטי: Slack, Node.js, Kubernetes - לא משהו שהתעשייה לא מכירה.
- אבל - כל חברה היום לוקחת את “הטוויסט” שלה, וזה בא לידי ביטוי (איך שאני רואה את זה) בעיקר בארכיטקטורה של המוצר.
- מה הכוונה? בסופו של דבר הצורה בה אני תופס ארכיטקטורה של מוצר אינה בהכרח סט המחלקות או המודולים, אלא סט הערכים.
- כשאנחנו באים לבנות מוצר ובאים לבנות ארכיטקטורה, בין אם אנחנו מתכוונים לזה ובין אם לאו - הקוד מייצג את הערכים של הארגון.
- ננסה דוגמא - בחברה הקודמת (Sears), משהו מאוד חשוב היה ורסטיליות (Versatility) של אנשים: היכולת לעבור מפרויקט לפרויקט, כך שאם יש עכשיו את הדבר הלוהט הבא אפשר לקפוץ לשם - והיו לזה משמעויות בארכיטקטורה שלנו -
- העדפנו מבנה של מונוליט - מצב של Codebase אחד שנמצא במקום אחד שזמין לכולם, וקל ומותר לגעת בכל דבר, וגם הכל נראה אותו הדבר לאורך כל המערכות.
- הכוונה ל-Mono-Repo או ל - Monolith?
- בהרבה מאוד מובנים Monolith, גם לפי הרבה עקרונות אחרים - למשל: החלטנו לוותר באופן מודע על פוליגלוטיות (Polyglot Programming), לבוא ולומר שלא משנה איך אתה “משחק את המשחק”, אתה תשחק באותה צורה; הרבה דברים יראו אותו הדבר, במידה מסויימת גם במחיר של ויתור על עקרונות של Loosely-coupled - כי אנחנו רואים ערך בזה שהכל נוגע בהכל ותוכניתנים יכולים לגעת בהכל, ושתוכניתן יכול להבין את המשמעות של מה שהוא עושה.
- אוקיי, אז לא היה מונוליט אחד - היו ארבעה . . וכן - בסופו של יום היה בזה ערך, כי ה - codebase היה משותף וכולם הכירו את הקוד של כולם ולא משנה באיזה צוות היית.
- במידה מסויימת היינו מספיק קטנים על מנת להצליח להחזיק את הערכים האלה.
- לעומת זאת - עכשיו ב - Natural Intelligence יש ערכים חדשים - וה - Codebase צריך לייצג את זה.
- “פתאום” אנחנו הרבה יותר גדולים - אז צריך לדבר על אחריות, ואיזורי אחריות, ו - Business Domains, וצריך לדבר על זה שאנחנו לא רק גדולים אלא גם גדלים מאוד מהר, אז צריך לדבר על המשמעות של הכנסת המהנדס הבא - איך אנחנו גורמים לזה שהרבה מאוד מההחלטות ההנדסיות שקיבלנו מאוד ברורות ואינטואיטיביות (Intuitive Codebases) ולא צריך לשאול וכל הזמן ללוות את המהנדס הבא “ולהחזיק לו את היד בדרך לפרודוקטיביות”.
- כמה דברים שעשינו בדרך היו מעבר מאוד חד ל - 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 - זה המקום היחיד ההגיוני לחפש אותו.
- זה גורם לכך שכל מי שמבקר בדיסנילנד (ובהקבלה לתוכניתנים), לא צריך לחפש איפה אינדיאנה ג’ונס (או קוד שאחראי לפונקציונליות מסויימת) נמצא - יש רק מקום אחד הגיוני שבו הוא יהיה.
- אם אנחנו מצליחים לייצר דבר כזה - והטקסונומיה מספיק אינטואיטיבית - מאוד קל לעשות את הדברים האלה.
- הנקודה שבה אנחנו הרבה פעמים מתבלבלים כשעושים מודולוריזציה זה כשחושבים על זה באספקטים טכניים - איך דברים קורים ופחות על מה שהם עושים.
- בדיוק
- (רן) פשוט - לפי מדד ה-WTF?!
- כנראה שמתחת למים . . .
- נכון מאוד - וזה חלק מהעולם.
- הנקודה היא שבסופו של דבר צריך לשמור את האצבע על הדופק, והרבה פעמים מה שקורה זה שאנחנו לא שומרים את האצבע על הדופק, וקצת מנחשים, מוותרים, ממשיכים עם הכיוון . . .
- בהרבה מקרים זה “פשוט” לבוא ולמדוד - אנשים חדשים תמיד מגיעים, וצריך לשאול אותם איפה הם נתקעים, איפה הם צריכים עזרה.
- דבר שהראה לנו באופן מאוד ברור שהטקסונומיה שלנו לא ברורה הוא מה שאנחנו מכנים “מדד ה - Tracer Bullet” - אם עבור פיצ’ר אחד אני צריך לגעת ב 4-5 microServices, כנראה שאני לא בונה את הטקסונומיה שלי כמו שצריך, וחלוקת ה - microServices לא ממש נכונה ואולי יש מידול לא נכון של ה - microServices לעולם העסקי.
- כן
- יותר מזה - התחלנו למדוד לאחרונה גם משהו שאולי ישמע קצת מוזר: מצד אחד יש לנו תלויות ב - Codebase מסויים (ככל שיש יותר תלויות כך הוא יותר תשתיתי, וצריך להשתנות כמה שפחות). מצד שני - אם כולם נוגעים בו וכולם תלויים בו, זה אומר שכנראה גם שם אולי מתחבא איזשהו microService אחד או יותר שצריך לפצל - מטריקות של יציבות ביחס לתלות (Tracer Bullet) - וזו ההתחלה.
- אחד האתגרים הוא באמת שעבור ארגונים בגדילה - המשיכה הזו משתנה כל כמה חודשים: האיזור שבמוקד או הצוות-הגדול-מדי-וצריך-להתפצל . . . Conway Law אולי טוב כשיש יציבות (כן?), אבל יותר מבלבל במצבי כאוס.
- כן - אבל אם כיוון הכוח משתנה כל חודשיים אז אולי צריך, לפחות במידה מסויימת, להתנגד אליו, או - עם כל הכבוד לחוק - לפעמים לעזור למבנה הארגוני להתאים לארכיטקטורה, או להיפך. זה עניין דו-כיווני.
- אם אני רוצה לעשות איזשהו שינוי, אני לא אלך ואבקש ממישהו לשנות אצלו - אני אשנה אצלי, גם אם זה עקום קצת. יותר קל - Path of least resistance. גם אם זה קצת עקום אז שיהיה - זה עדיין יותר קל (דברים זולים עולים פחות).
- בסופו של דבר - המוצר יוצא “עקום”, כי המבנה הניהולי היה עקום מלכתחילה.
- מה שאנחנו בעצם אומרים זה שגם בחברות צריך להיות עם אצבע על הדופק - במיוחד בחברות בהן המוצר משתנה או שכח האדם הולך וגדל, צריך גם לשנות את המבנה הארגוני - לא הגיוני שבמשך שנתיים ישאר אותו המבנה שרק “יתפח”, כנראה שצריך לשנות משהו במבנה - בין אם זה חלוקה לצוותים יותר קטנים או לפי צרכים עסקיים: לסגור צוות, לפתוח אחד חדש וכו’.
- (אורי) לפעמים החוק כל כך משתלט עלינו עד שאנחנו אומרים “רגע - למה עכשיו להתחיל להזיז צוותים או Business Domains . . .המערכת כבר בנויה ככה”. מפה לשם - זה הופך למעיין משקולת על הגמישות, על ה - Velocity . . .
- (עמרי) נכון - הנה דוגמא קטנה על דילמה כזו שנוצרה אצלנו: תמיד יש את המתח במקרה של microServices קטנים מאוד, שעבורם זה פשוט להעביר את ה microService בשלמותו בין צוותים (כשצוות למשל מסיים את עבודתו, או כאשר צוות אחר צריך לבוא ולקחת אחריות), ומצד שני - אנחנו רוצים לייצר microServices יותר גדולים, שיותר נוח לשמור עבורם את ה - context ולקחת עליהם אחריות בתור צוות.
- היום זו מעיין מטוטלת, ואם בתקופה מסויימת היינו עם microServices יחסית גדולים (“מיני-מונוליטים”) ולאט-לאט הלכנו לכיוון של microService לכל Entity, היום המטוטלת חוזרת קצת.
- “כולם מדברים עם כולם” זה נורא מסובך - אולי נתחיל לאחד למונוליטים קטנים?
- הנקודה שבא אני צריך לדבר עם עצמי דרך 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 חדש ואיכותי, גם מבלי לעשות את כל המחקר. זו טכניקה אחת שהיא מאוד אפקטיבית.
- ושוב - פשוט מקשיבים, ואם צריך מתכון חדש, אז יוצרים גם אותו.
- כמה זמן? זה לא נמדד בזמן אלא משהו אישי - קצת כמו קורס אינטרנטי: אתה עובר משימות שמכניסות אותך ממש לתוך העולם של הפיתוח.
- המשימה הלפני-אחרונה היא “לנקות את הסביבה שלך” - כל סביבת הניסיונות שעשית עד עכשיו.
- המשימה האחרונה היא לכתוב לנו פידבק - כדי שנוכל להשתפר לפעמים הבאות.
- מי שמחזיק את ה-Boot-camp הזה ומאפשר אותו ועובד עליו, וגם יושב ב-1:1 ומקבל פידבק מהמפתחים, זה הצוות Developer Experience (פרק 367 למיטיבי שמע), שבונה ומשפר כל הזמן - וגם נמצא בקשר רציף עם המפתחים.
- עדיין לא - עדיין לא גדלנו לדבר כזה, אבל נאמר זאת ככה, לפחות בערכים שלי - אני חושב שזה צריך להיות חלק מהאחריות של כל אחד מהמפתחים.
- אני לא בטוח שזה סוג ה - Ownership שהייתי רוצה לתת לצוות שזה תפקידו, ואלו המטרות (Goals) שלו.
- איך אומרים - בכל פעם שאנחנו מתקרבים, המטרה זזה . . . זו המציאות, אבל אני חושב שאם יש משהו שהוא לפחות משמעותי ב”לשים את אצבע על הדופק”, זה שלפחות אנחנו מנסים לשמור על מצב שהוא לא יתדרדר - ואנחנו יודעים למדוד את עצמנו, ואנחנו יודעים לבוא ולאמר מתי אנחנו מצליחים ומתי אנחנו לא מצליחים.
- וזו עבודה של כנראה יותר מחצי שנה ויותר מהתקופה שבא אני נמצא - וכנראה שלשנה הקרובה תמיד יהיו את קפיצות המדרגה הללו . . .
- כן - כנראה. ועם הגדילה זה כנראה יהיה יותר כואב - ובסוף יהיה גם יותר טוב.
- דבר אחד אחרון - כאב אחד מאוד משמעותי שאני (עמרי) חווה אותו כשאני עובר מחברה לחברה, או אפילו ממוצר למוצר באותה החברה: עניין הטרמינולוגיה . . .
- אנחנו כתוכניתנים, איך אומרים - “Naming things זה הדבר הכי קשה אחרי Caching?” אני טוען שזה הדבר הראשון, ואנחנו כנראה לא נותנים לזה מספיק כבוד.
- יש לנו נטייה לבוא ולעשות כל מיני דברים שבדיעבד הם לא מאוד חכמים - דבר אחד שאנחנו מאוד אוהבים זה להמציא טרמינולוגיה משלנו, ובעיקר Pan names: אני מניח שלכל אחד יש איפשהו במערכת איזשהו מודול עם שם “סקסי” שמבוסס על דמות מ - Star Wars (זה לא רק אני?!), מיתולוגיה הודית וכאלה . . .
- מחרתיים יגיע מישהו חדש, שאולי המיתולוגיה ההודית היא לא His cup of Chai . . .
- אבל אולי המיתולוגיה השוודית כן? בכל מקרה - עכשיו הוא מבולבל
- למדתי להעריך את “השמות המשעממים”, ולהגביל עד כמה שאני יכול את השמות ה”קוליים” ואת ה-Pan names.
- הדבר השני הוא טרמינולגיה שהיא “טעונה” - יש לנו הרבה מאוד פעמים נטייה לבוא ולהשתמש בטרמינולגיה שכבר השתמשו בה במקרים אחרים ועבור עולמות אחרים.
- לא יאמן כמה פעמים שמעתי את המושג Segment מתייחס לכל מיני דברים אחרים, את מושג Recommendation מתייחס לכל מיני דברים אחרים, וכנ”ל עבור Review ו - User ומה לא . . . גם Context - זה היה כנראה היה הפושע מספר 1 ברשימות שלי.
- משהו מאוד משמעותי שאנחנו צריכים לבוא ולחשוב עליו זה איך אנחנו נותנים שמות שהם כאלה שעוזרים לנו להבין את ה - Context של ה - Context.
- יש הבדל בין Segment לבין User Segment לבין Marketing Segment ועוד דברים כאלה - חשוב לחשוב פעמיים ולנסות לייצר מצב שבו אין עמימות (Ambiguity) בשמות שאנחנו נותנים . . .
- הדרך הכי פשוטה - Code Reviews, או Design Reviews
- אני בתור תוכניתן שמנסה לבוא ולשפוט את עצמי, שנייה לפני שאני “נותן שיתפסו אותי” ב - Code Review, זה לעשות חיפוש באינטרנט ולהבין מהי הטרמינולוגיה, ולעשות חיפוש ב -Codebase כדי לראות האם אולי בתוך ה - Codebase יש טרמינולגיה דומה אבל אולי לא עקבית (Consistent).
- אלא שני דברים מאוד קלים שאני יכול לעשות תוך עניין של דקות, ופשוט לשפר את ה - Naming ואת הטרמינולגיה שלי בצורה מאוד משמעותית.
25 פרקים
כל הפרקים
×ברוכים הבאים אל Player FM!
Player FM סורק את האינטרנט עבור פודקאסטים באיכות גבוהה בשבילכם כדי שתהנו מהם כרגע. זה יישום הפודקאסט הטוב ביותר והוא עובד על אנדרואיד, iPhone ואינטרנט. הירשמו לסנכרון מנויים במכשירים שונים.