מצגת: העקרונות האוניברסליים של הנדסת תוכנה

נתבקשתי ע״י אפרת וולפנר-תורג'מן (ידידה ותיקה) ודור מצפי, שמקימים בימים אלה את גילדת התוכנה בחברת סמסונג – לבוא ולדבר קצת על תכנון תוכנה (Software Design).

האתגר שלהם: מגוון רחב מאוד של אנשי תוכנה: FE, BE – קל להבין, אבל בגילדה שלהם יש גם אנשי Data Science / ML, Data Engineers, Embedded, ו Firmware. כולם כותבים קוד, אבל באמת צורות העבודה של המקצועות הללו היא שונה דייה, כך שלא קל למצוא ברמת הקוד דוגמאות הרלוונטיות לכולם.

האם דזיין הוא שונה? האם אפשר באמת להגדיר כללים זהים שיתאימו גם למפתחי FrontEnd, גם לאנשי Machine Learning, וגם לאנשי Firmware.

לקחתי על עצמי את האתגר – והאמת שהוא לא היה קשה.

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

כמה כללים פשוטים (איך לאחוז במחבט, באיזו זווית לתת את המכה ״כוון כאילו אתה נותן מכה לפנים של היריב״) – יכולים להקפיץ משמעותית את הביצועים של שחקן לא מיומן.

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

כמה נקודות במצגת ששוות להתייחסות נוספת

למה אפשר לצפות מדזיין טוב?

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

איך נראה דזיין טוב?

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

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

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

דזיין הוא תהליך – ולא מסמך

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

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

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

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

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

מקווה שתמצאו פוסט זה שימוש!

Design By Example III: Abstractions – חלק ב'

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

בכל אחת מהחלופות, ננסה לבחון את ההיבטים הבאים:

  • פתרון הבעיה העסקית – רמה #0 ע"פ מודל בגרות התכנון (אני מניח שאת רמה #1 ~בערך~ כיסינו בפוסט הקודם).
  • הכוונה / הצהרת כוונות – רמה #2 ע"פ מודל בגרות התכנון.
  • גמישות עתידית – רמה #3 ע"פ מודל בגרות התכנון.
  • עקרונות תוכנה – האם אנו מפירים איזו עקרון מקובל? זה סימן למשהו שחשוב לבדוק.

כמה הערות לגבי גמישות עתידית של המודל (Predicted Variations):

  • Predicted Variations הוא עקרון שעשוי לתרום, אבל להזיק – יש כאן בבירור Tradeoff:
    • אפשור היום לגמישות עתידית – הוא הימור. אם לעולם לא נגיע לידי שימוש בגמישות הזו – הרי שבזבזנו זמן, וסיבכנו את המערכת. השקעה / סיבוך היום, שלא יגיע לידי שימוש בעתיד – הוא בזבוז ברור. יש שיטענו ש Predicted Variations הוא דרך מבטיחה ל Overengineering.
    • גם השקעה היום, שניתן לבצע באותו עלות בעתיד (נאמר: שבוע עבודה היום, מול שבוע עבודה עוד שנה) – היא בזבוז.
    • השקעה משתלמת היום תהיה כזו ש:
      • חוסכת משמעותית עלות בעתיד. למשל: שבוע היום, מול חודש עוד שנה.
      • לחלופין: עוזרת להכווין את הדרך / לשמר אופציה עתידית חשובה. אולי תמיכה באנדרואיד (subsystem) ב Windows 11 היה קל לפתח בהתחלה ובסוף באותה המידה, אבל הצבת היסודות בשלב מוקדם מחדדת לכולם את המסר שזה כיוון אסטרטגי – ועוזרת לבדוק שפיתוחים אחרים אינם "חוסמים" את היכולת הזו.
    • כבני-אדם, בוודאי שאנו נוטים להערכת יתר של אפשרויות עתידיות. בדקו את ההיסטוריה של ההחלטות שלכם: אם אחוז ניכר של "ההכנות למזגן" (כינוי לא-מוצלח לגמישויות עתידיות) שיצרתם – לא הצדיקו את עצמן בבירור, זה סימן חזק שכדאי לכם להיות שמרנים יותר בהערכות העתיד שלכם. כל פיתוח שניתן לדחות לעתיד – עדיף. פיתוח שניתן לדחות – ולא יהיה בו צורך, על אחת כמה וכמה.

חלופה 1

  • פתרון הבעיה
    • חסר הטיפול במקרה-הקצה של שאלה המופיעה ב Entity Hub.
      • אולי זה מקרה מספיק פשוט לפתור בהמשך הדרך, שלא סביר בכלל שישנה לנו את התכנון בצורה מהותית – ואולי זה בדיוק הדבר שעלול לסבך אותנו בעתיד. אני הייתי מעדיף לסגור את הנושא הזה לא בסבב הראשון של התכנון – אבל בהחלט לפני הגעה למימוש.
  • הכוונה
    • יש חולשה בייצוג של EntityHub המכיל רשימה של דפים. אנחנו לא אומרים כלום על הקשר בין הדפים הללו (מלבד שיש להם סדר) או על הדמיון הבלתי-נמנע בין השאלון כולו (Questionnaire) לסט הדפים הללו (שקל לדמיין אותם כ "sub-questionnaire" מאיזשהו סוג. בעצם אי אמירה על הקשר – אנחנו אולי אפילו רומזים שאין קשר בין השניים, ומובילים את הבאים אחרינו ליצור שני מנגנונים שונים.
      • ההחלטה ששאלון ו"שאלון ל Entity" צריכים להיות שונים – היא הכוונה. למשל המבנה הבא מספק אמירה: (אם היא רצויה – אדרבא)
    • המונח Step ("שלב") היא הפשטה גבוהה. כלומר: מתירה הרבה מקום לדמיון: האם popup בנוסח "לא ענית על כל השאלות, האם תרצה להמשיך בכל זאת? כן/לא" הוא שלב? האם ייתכנו שלבים ללא ייצוג ויזואלי? (למשל: שמירת נתונים, בדיקת אימות בצד השרת)? האם לחזור לדף קודם הוא שלב? אולי זה מתאים, ואולי לא – חשוב לשים את הדעת על הבחירה הזו, בהפשטה גבוהה.
      • נדבר שוב על ההפשטה הזו בחלופה 2.
    • גם Element היא הפשטה גבוהה. בעצם – ברמה הגבוהה ביותר. "אלמנט" הוא אפילו יותר מופשט מ"אובייקט" (שבעולם מתייחס בדרך כלל לדבר פיסי, ולא לרעיון). נראה בחלופה 3 לאן זה לקח אותנו.
  • גמישות עתידית
    • הייצוג של תת-השאלון ל Entity כרשימה של דפים – מגבילה בראייה של גמישות עתידית. אולי יש צורך כזה, ואולי לא.
      • שווה לראות את הגישה של חלופה 4 לעניין.
  • עקרונות תוכנה – אני לא מזהה חריגה.

הפשטות גבוהות מול הפשטות נמוכות

בשנות ה 80 ו ה 90 העליזות, של C, Cobol ו Pascal – מתכנתים כמעט ולא השתמשו בהפשטות, ופספסו הזדמנויות מידול בקוד שלהם. תנועות ה Object-Oriented וה Patterns שינו את המצב מקצה לקצה – והיום יש רבים שעבורם "גנרי", "הפשטה", ו"גמישות" – הם בהכרח דבר טוב. חלון נפתח (מטאפורה לגמישות) בבית שלנו – היא גמישות חשובה, אבל חלון נפתח שבתוכו חלון נפתח ובו עוד חלון נפתח – הוא כנראה מתכון לגמישות מיותרת שבעיקר תעשה בעיות. חשוב למצוא את מידת הגמישות הנכונה לבעיה.

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

זה כמובן תלוי. Visual היא הפשטה מאוד גבוהה. היא תגרום למפתחים באזור לדמיין ולגשת לאפשרויות אחרות שההפשטות האחרות, הנמוכות יחסית, לא יאפשרו. מצד שני – היא יכולה "להכשיר" עיוותים בלתי רצויים בעליל. למשל: Visual נועד לציין תוכן (content) על המסך, אבל ההפשטה הגבוהה מתאימה גם ל control (רכיבי שליטה) כגון כפתורים בתוכנה, מסגרת, tooltip – וכו', וכך הדברים מתערבבים. שימו לב כמה הכוונה יש בכל רמה של הפשטה, ואיזה כלי משמעותי זה להכווין את הבאים אחרינו – להיכן אנו רוצים שהדברים יתפתחו.

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

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

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

חלופה 2

לחלופה הזו יש הרבה חפיפה עם חלופה 1. נתמקד בשני ההבדלים המהותיים:

  • פתרון הבעיה העסקית – פותרת.
  • הכוונה
    • כל Step מכיל Elements. זו בעצם הגבלה – ההיפך מהפשטה.
      • ניתן להתפשר ולהחזיק רשימות ריקות / null כאשר לא נדרש – אבל המשמעות היא קוד מסורבל יותר, ומסר הרבה פחות ברור לגבי הכוונה.
      • עצם כך שרוב ה Entity Hubs (ע"פ ה narrative מהפוסט הקודם) לא יכללו אלמנטים – ואנחנו פה קובעים שכל Step מכיל Elements – בעצם יצרנו כלל שרוב הפעמים אינו נכון. זו הכוונה הפוכה. אפשר לומר: כמעט הטעייה.
        • כשדורשים מאתנו לחבוש מסיכות (רפואיות) תוך כדי אכילה – כנראה שנסיק שמי שקבע את הכלל לא ממש מבין. כאשר אנחנו נתקלים בהכוונה הפוכה – שמתנגשת עם המציאות – קורה אותו הדבר. עולים סימני שאלה לגבי איכות ההכוונה.
      • יש סתירה ברורה בין ההפשטה הגבוהה ("Step") לבין ההגבלה שכל Step כולל Elements. נראה שניסו לקרוא ל Step בשם טיפה יותר מצומצם "QuestionnaireStep", אבל מכיוון ש Step מוחזק ע"י Questionnaire – לא נראה שנוספה כאן משמעות (מקסימום השם עומד טוב יותר בפני עצמו). ככל שההפשטה גבוהה יותר, נצפה לפחות קביעות (הגבלות) על הפשטה. הגבלות / קביעות על ההפשטה הוא כלי שימושי להכוונה – אבל במקרה הזו זו פשוט נראית הכוונה לא טובה.
  • גמישויות עתידיות
    • EntityHub מכיל QuestionnaireStep – ולא Pages.
      • זו בעצם גמישות, שמאפשרת עץ מקונן של דפים ו EntityHubs.
      • הקשר בין EntityHub ל Page הוא פחות ברור אפילו מחלופה 1 (קשר עקיף).
      • אם יש צורך עסקי אמיתי באופק למבנה כזה – ייתכן וזה מודל טוב. על פניו מהתיאור בפוסט הראשון – זו נראית כמו גמישויות מיותרת המטשטשת את הכוונה.
  • עקרונות תוכנה – אני לא מזהה חריגה.

חלופה 3

החלופה הזו צורמת בעיני מהמבט הראשון, מכיוון שהיא מפירה את עקרון ה SLAP (Single level of abstration principle), מה שגורר הפרה של עקרון ה (POLA (principle of least astonishment. אני יודע בקרב המגיבים לפוסט הקודם – זו הייתה האופציה המועדפת, ואני מוכן להגן על עמדתי. טיעון שהועלה הוא "פשטות", ואכן פשטות הוא יתרון אמיתי – אבל אני אנסה להראות שהפשטות שהחלופה הזו מציגה היא בעיקר מראית-עין, ולאורך זמן אני מעריך שהיא לא תחזיק מעמד. מצד שני – בצד ההכוונה, דווקא יש סיכון ממשי להכוונה לכיוונים לא מועילים. אפרט.

  • פתרון הבעיה העסקית – פותרת.
  • הכוונה
    • כפי שציינתי כבר בחלופה 1, המונח "Element" מספק הפשטה מירבית[א], מה ש"מתיר" להכיל: כלב, עץ, עוני, ורקורסיה – כ Elements נוספים במערכת. המונח Element לא סותר / דוחה את האפשרויות הללו מעצם שמו.
      בקיצור: הפשטה מירבית היא הכוונה אפסית. אין פה הכוונה. הכל הולך.
      • מה היה אפשר לעשות אחרת? לספק הכוונה מסוימת. למשל, השם "QuestionnairePageElement" כבר מגביל / מכווין אותנו הרבה יותר טוב. גם כלב, וגם רקורסיה – כבר בבירור אינם מתאימים. EntityHub – פחות מתאים, אבל עדיין יכול "להשתחל" עם קצת דמיון (כ "iframe ויזואלי"). אם היינו קוראים ל EntityHub בשם EntityPage – זו הכוונה נוספת, כי זה לא נשמע טבעי להכיל page בתוך page. מונח כמו "QuestionnaireComponent" יכול להיות הכוונה, אם המונח Component מתקשר אצלנו חזק לרכיב UI עצמאי (כך ב UI frameworks מסוימים). בקיצור: הייתי מנסה להחליף את המונח Element במונח שמכווין יותר את הכוונה.
  • גמישות עתידית – יש אפשרות להוסיף כמעט כל דבר כאלמנט – מה שנוגע בנקודה הבאה.
  • עקרונות תוכנה
    • כותרת (Title), שאלה (Question), תמונה (Picture), ועמוד ניהול ישויות (Entity Hub) הם לא באותה רמת הפשטה. אני מניח שזה בולט ברמה של תרגילי "מצא את יוצאי הדופן" הפופולריים בחוברות עבודה של הילדים שלי כשהיו בגילאים מוקדמים. (לא פעם אגב, הרגשתי לא שלם עם התשובה שהחוברת מציעה ל"יוצא הדופן").
      • הם בסדרי גודל אחרים: חייל בודד מול פלוגה.
      • הם עצמאיים במידה שונה: אחד זקוק ל Container / מסגרת שתכיל אותו – והשני לא.
    • נטען שהכנסת כל הנ"ל לאותה הפשטה תאפשר קוד פשוט יותר (ריבוי-צורות / polymorphism) – אבל ריבוי-צורות לא עובד בפועל, כאשר הרכיבים השונים בו לא דומים מספיק זה לזה. התוצאה לרוב היא branching הולך וחוזר בקוד:
      • if type = EntityHub -> do x
      • else -> do y
    • כלומר: יצרנו הכללה ("Entity") לפריטים שזקוקים לטיפול שונה מהותית, ולכן למרות היכולת להכיל אותם באותו מבנה נתונים (<List<Entity, למשל) זה לא יעבוד ברגע שנטפל בקוד אחרת – ובעצם נטפל, ברוב המקרים, בשתי קבוצות שונות של פריטים. כלומר: כאילו הייתה לנו הכללה, אבל בפועל הקוד נאלץ לטפל בשני מקרים נפרדים.
    • הבעיה הכי גדולה, היא "ההזמנה" להוסיף כל פריט נוסף להכללה הגבוהה של "Entity". מכאן הקוד ילך ויסתבך. גם ב branching גדול יותר בקוד, אפילו יותר – באי-חלוקת הקוד לנושאים / אזורים מופרדים (אותו מחלקה תטפל בכל הסוגים השונים של הפריטים), והכי גרוע – פספוס ההזדמנות לחלוקה יותר הגיונית והכוונה יותר טובה של האזור הזה בקוד – לו היינו משתמשים בהפשטות טובות יותר.

חלופה 4

טוב, אני חייב להודות שזה המודל המאוזן והפשוט ביותר לטעמי, ע"פ הבנתי של ה narrative. עדיין יש לו חסרונות, בואו נראה:

  • פתרון הבעיה העסקית – לא טיפלנו בשאלה על EntityHub – וזה חסר.
  • הכוונה
    • כפי שציינתי, לפי דעתי הכי פשוט ומאוזן מכל החלופות האחרות:
      • Step הוא אחד משני מצבים – הנבדלים זה מזה.
      • EntityHub בעצם קשור לשאלון, ישות שמשמעותה ברורה.
        • כן הייתי מצפה שיכולות הנוספות לשאלון, ייתמכו גם ב"תת-השאלון". אני מניח שגם משתמשים לא היו מבינים למה שרמה 0 (שאלון-העל) יש התנהגות אחת, ובתת-שאלון (רמה 1) – יש התנהגות אחרת.
    • עדיין Entity היא הפשטה גבוהה מדי, וגם Step עדיין פתוח לפרשנות (לטוב ולרע – תלוי למה אנחנו מתכוונים)
  • גמישות עתידית
    • בחינתי הצד הטוב הוא שימוש חוזר ביכולת ה Questionnaire גם לתת-שאלון.
    • הקוראים ציינו שהגמישות להכיל היררכיה של EntityHubs אינה נדרשת – והיא נראית כגמישות מיותר. אני מסכים – ומעדיף לחסום אותה.
  • עקרונות תוכנה – אני לא מזהה חריגה.

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

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

  • ניסיתי להגביר את ההכוונה בעזרת מונחים המובילים להפשטות נמוכות יותר:
    • Questionnaire Page במקום Step. לא נראה שצריך משהו יותר מזה בשלב הזה. להגביה את ההפשטה בעתיד – לרוב קל יותר מאשר להנמיך הפשטה.
    • Component במקום Element – בהנחה שברור שזה רכיב ויזואלי בודד בדף. זה שינוי חשוב בעיני.
  • הוספתי ל EntityHub Page שאלה אחת אפשרית. כלומר: יש טיפול מיוחד (אי שימוש חוזר בקוד ה Component) בשאלה על EntityHub – אבל זה נראה לי האופציה הפשוטה יותר בסה"כ.
  • הגדרתי שני סוגים של Questionnaire כדי לחדד שלא כל תכונה / יכולת של ה Root Questionnaire תהיה בהכרח ב Sub-Questionnaire, למנוע שלא נסתבך.
  • הוספתי constraint על ההורשה ש Sub Questionnaire לא יכיל Entity Hub Pages. אין צורך כזה – וחבל לסבך את המערכת.
    • איך ממשים את זה? תלוי בשפת התכנות. ניתן לבודד את Sub-Questionnaire שיחזיק רק QuestionnirePages – אבל אני חושש שהתרשים קשה יותר לקריאה:
  • אני שומע כבר ביקורת עולה: אבל הפתרון שלך יותר מסובך מכל האחרים. זו פשטות???
    • אני טוען: התרשים מורכב יותר – לא הפתרון. בכל מקרה בקוד (שיהיה מסובך עוד יותר, אני מניח) – נתמודד עם השאלות הללו. אני מעדיף לפתור אותן בשלב התכנון, ואני מניח שהתרשים המפורט / מורכב מעט יותר – בסה"כ יתרום להבנה משותפת של מי שעובד על הפיצ'ר. השאלות הגדולות הן שם – ובאופן דיי פשוט, לדעתי. למנהלים בכירים אפשר להציג בתור התחלה תרשים מופשט יותר (כמו התרשים של חלופה 4, עם מונחים המובילים להפשטות פחות גבוהות)

סיכום

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

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

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

מטרת הפוסט לא הייתה לדון בפתרון כזה או אחר – אלא בדרך להגיע לפתרון.

שיהיה בהצלחה!


[א] – אני מודע לכך ש"מירבית" הוא כתיב לא תקני – אבל הוא נראה לי ברור יותר. כמו שפרי ברבים צריך להכתב פרות (Peyrot), אבל הגיוני יותר עדיין בעיני לכתוב פירות.

Design by Example II

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

אנו רוצים לתכנן מנגנון להגבלת בקשות / תעבורה. מנגנונים כאלו יכולים להופיע בחלקים שונים של המערכת, אבל אבחר בדוגמה שנראית לי הנפוצה ביותר: API. אנו רוצים להגביל את כמות הבקשות המגיעות מצד שלישי למערכת שלנו. יש כאן כמה שאלות לענות עליהן:

  • היכן יישב המנגנון של ה Rate Limiting? בתוך המערכת – או כרכיב נוסף?
  • איך המנגנון יעבוד בפועל? איך יוודא שה Rate נשמר?
  • האם אנחנו צריכים כלים נוספים (Queue, Database, וכו') – על מנת לספק את המנגנון?

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

מה שאנו נוטים לשכוח…

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

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


הספר ?Are your lights on מספר על מגדל "ברונטוזרוס", מגדל משרדים לתעשיית הפיננסים – שבו הלקוחות מתלוננים על תור ארוך למעליות. הוא מציע מספר פתרונות:

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

מה דעתכם? איזה פתרון אתם מעדיפים? מה נראה לכם הכי הגיוני?

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

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

  • קביעת השכירות כפרמטר של מספר העובדים של כל שוכר – וכך צמצום מספר העובדים בבניין. כלומר: יהיה משתלם יותר לחברות עם פחות עובדים / פחות צפיפות לשכור. זה עשוי להשפיע גם על תחזוקה / חניה / עלויות אחרות.
  • יציאה בקמפיין שמבליט את המגניבות בלעבוד ב"מגדל ברונטוזרוס" – כך שהתורים במעליות יתקבלו ביתר הבנה: "זו זכות לעבוד בכזה מגדל, תראה כמה אנשים רוצים את זה".
  • גיוון בתחומי העיסוק של השוכרים בבניין. אולי כל אנשי הפיננסים מתחילים לעבוד בין 7:00 ל 7:30, אבל ההגעה לחברות הייטק – עשויה להתפזר על טווח רחב יותר של שעות (8:00 עד 10:00) ולהוריד את העומס?
  • למכור את הבניין, ולהתמקד במומחיות של החברה – בנייה ושיווק נדל"ן (ולא ניהול נכסים).

למה לא חשבנו על הפתרונות האלו ברשימה הראשונה שהכנו? אולי כמה מהם טובים, לבעל העניין, (ואולי גם לאחרים) הרבה יותר מפתרונות "הנדסיים"?

נסו לחשוב, מה מוביל אותנו ל"ריצה" לפתרון ראשון? פתרון שהוא אולי לא הפתרון לבעיה הנכונה.

חזרה ל Rate Limiter

אוקי. אנחנו רוצים להבין טוב יותר את הבעיה (או הבעיות) שבגינן אנחנו רוצים Rate Limiter ל API שלנו.

השאלה החשובה היא השאלה העסקית: מי רוצה את ה Rate Limiter (או כל Design שאנחנו עובדים עליו),ולמה? איך אנחנו יכולים לבנות ביטחון שאנחנו פותרים את הבעיה הנכונה?

  • בווריאציה אחת נתכנן Rate Limiter שנועד להגן על המערכת שלנו בפני עומס. צד שלישי קורא למערכת שלנו בקצב גבוה (נאמר: אלפי פעמים בשעה), ו/או כל קריאה של הצד השלישי דורשת מהמערכת שלנו כמות נכבדת של עבודה – כך שמעבר לקצב מסוים, המערכת שלנו תגיב לאט מדי לכלל השימושים ואולי תקרוס.
    • להזכיר, גם כאשר יש auto-scaling – הוא לא מיידי. Peak גדול שמגיע ברגע אחד, יכול לגרום לאי יכולת לספק את הבקשות לזמן מה עד שהמערכת גדלה מספיק.
    • נניח שהצד השלישי הוא חלק משני בביזנס. כלומר: אנו מעדיפים לא לתת לו שירות על מנת להגן על המערכת / הביזנס העיקרי.
  • בווריאציה השנייה, אנו רוצים להגן על הלקוחות שלנו מפני עלויות-יתר. הם משלמים לנו על כל קריאת API אבל מצפים שנעזור להם לנהל את העלויות. אם לקוח לא רוצה להוציא יותר מ $5000 בשבוע – אנו נאפשר לו את זה ע"י דחיית בקשות שחורגות מהתקציב.

איטרציה ראשונה: Rate Limiter שמגן על המערכת

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


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

המהנדסים שנגשו למטלה (דווקא חבר'ה עם הרבה שנים בתעשייה), לא הטילו ספק בדרישות ומימשו מנגנון שחוסם לקוח (היה באותו שלב רק אחד) שעושה יותר מ 50,000 בקשות בשעה.

האם אתם מזהים כבר את הכשל הלוגי? הנה כמה:

  • נניח שהמערכת יכולה לעמוד בעומס של 60,000 בשעה. הוספה של לקוח נוסף תאפשר 100,000 בקשות בשעה.
  • כמה מהעומס מגיע מפנים המערכת? אולי בעצם השימוש העיקרי של המערכת כבר משתמש ב 20,000-30,000 בקשות בשעה? ואז – 50,000 בקשות נוספות כבר יביאו לקריסה.
  • כמה המספר הזה יציב לאורך זמן? מי יידע לעדכן אותו כאשר שינוי במערכת משנה את הקיבולת הזמינה (להעלות או להוריד)?
  • הכי גרוע אולי, אם מגיע לקוח שעושה מיליון בקשות בשעה – כמה זמן ייקח עד שייחסם?
    • 60,000 בקשות בשעה הן 1,000 בדקה, ו 16 בשנייה. מיליון בקשות בשעה, בממוצע, הן 270 בשנייה – הרבה יותר ממה שהמערכת יכולה לשאת.
    • מה אם מותר לעשות 50,000 בשעה – אבל לקוח בוחר לעשות את כל הבקשות שלו במשך שלוש דקות? התוצאה היא זהה.

זה אגב מה שקרה לנו אז: שעתיים אחרי ש API נפתח לצד השלישי – כל המערכת קרסה. ה Rate Limiter, מומש ונבדק – אבל לא עשה את העבודה. הצד השלישי ידע שלאחר 50,000 קריאות בשעה הוא ייחסם, אבל לא דאג להגבלות מצדו (הוא היה במוד ניסוי). מכיוון שהפנה בקשות בקצב גבוה מאוד, המערכת קרסה תוך דקות, "רק" אחרי כ 10,000 בקשות.

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


בואו נתחיל לחשוב על התכנון. הנה כמה שאלות שהעלתי בתחילת הפוסט:

  • היכן יישב המנגנון של ה Rate Limiting? בתוך המערכת – או כרכיב נוסף? – בהבנת הבעיה נראה לי שאני רוצה את ה Rate Limiting כרכיב נוסף. הוא אמור להגן על המערכת, ושייפול אם צריך – ויגן על המערכת.
    • יתרון נוסף – אוכל להשתמש ב Rate Limiter גם עבור שרתים (מיקרו-שירותים) אחרים. יש לי כלי לשימוש חוזר.
    • חסרון – עלויות. ישנם מקרים ספציפיים בהם זה שיקול מספיק לחבר את ה rate limiter לקוד השרת – אבל אנחנו לא שם.
  • איך המנגנון יעבוד בפועל? איך יוודא שה Rate נשמר?
    • דבר ראשון שברור שהרזולוציה צריכה להיות קטנה. תלוי מאוד אופי הבקשות, אורכן, תדירותן וכו' – אך כברירת מחדל אני אלך על היחידה הבטוחה והפשוטה: שנייה. הגבלת קריאות בשנייה.
    • מכיוון שמה שחשוב לי הוא להגן על המערכת בפני קריסה – חשוב לי שהיה מונה (counter) מרכזי שידחה בקשות בכלל. בנוסף נניח שאנחנו רוצים גם מונה לכל לקוח – לייצר שוויון מסוים. נניח: 1,000 קריאות בשנייה בכלל, ו 200 לכל לקוח. נניח שיש כ 20-30 לקוחות. המספרים המדויקים פחות חשובים לתכנון, אבל קל יותר לדבר ולהתייחס למספר נתון.
      • המקסימום למונה הכללי צריך לנבוע מתוך יכולות המערכת. מספר שנקבע יהיה כלל אצבע שלא יתחשב בשינויים במערכת. לכן, היה עדיף למשל למדוד את ה CPU של השרת הפנימי ולהחליט לפיו (או בעצם: ממוצע CPU כי כנראה יש כמה instances וגם המספר שלהם עשוי להשתנות דינאמית). בכל מקרה, אנחנו באיטרציה ראשונה – ולא נכון לצלול לזה כרגע. נרשום את המחשבה בצד.
    • "האלגוריתם" עצמו לספירה, נשמע לי דיי פשוט ואתאר אותו מיד בהמשך.
  • האם אנחנו צריכים כלים נוספים (Queue, Database, וכו') – על מנת לספק את המנגנון? האמת שתחושת הבטן שלי אומרת Redis (מנוע מבני-נתונים / אולי בסיס נתונים K/V – מבוסס זיכרון. כלי שכדאי להכיר). אני מניח על קצב גבוה כלשהו ובכל מקרה ברור לי שה Rate Limtier צריך כמה מופעים עבור High Availability (לא נרצה שנפילה שלו תפיל את השירות לצד-שלישי) – ורדיס הוא רכיב מרכזי.
    • חשוב בדזיין לפשט, ואולי אנחנו לא זקוקים לרדיס (בקצבים לא גבוהים, גם בסיס נתונים רגיל יכול לעשות את העבודה). תחושת הבטן שלי אומרת לי שכנראה שנרצה, וקל לי אישית לחשוב על הפתרון כך – ולכן אני מתחיל איתו. בסבבים מאוחרים יותר, אולי אמצא דרך לחתוך אותו החוצה, אבל אני הולך כרגע עם מה שהכי פשוט לי לעבוד איתו – ולהתקדם לנושאים נוספים.

הנה תרשים:

  • בקשה מתקבלת ע"י ה Rate Limiter ואני בודק את המונה המרכזי (global counter). אם חרגתי ממנו – אני יכול ישר לקפוץ ל 4b ולדחות את הבקשה.
  • את המונים אני יכול לתחזק ב Redis כ key/value, כאשר ה key הוא שנייה ב Epoch (עבור המונה הגלובאלי) או שילוב של לקוח (שאני מזהה ע"פ ה auth token) + שנייה ב Epoch.
    • ל Keys אקבע expiration של 10 שניות, למשל – כדי שהזיכרון של רדיס לא יתמלא.
    • הנחת יסוד שלי הוא שהשרתים מסונכרנים בשעונים. זו הנחה סבירה לחלוטין בתשתיות הענן הקיימות, ובאמזון, אם זכור לי נכון – אפשר להניח על סטייה מירבית של 1 ms לשרתים באותו Region – מה שלא בעיה עבורנו.
      • אפשר גם לקבוע cloudWatch alert על חריגה בשעונים של שרתים. לא יודע אם הייתי זוכר את זה בסשן Design ו/או ראיון – בטח לא היה לי זמן לחפש בגוגל ולאמת.
    • מי שמכיר היטב את נושא הזמן בטח חושב שיש כאן חור (קטן) בתכנון בגלל Leap Seconds. אני יכול להרגיע ש Epoch מתעלם מ leap seconds – ובכל מקרה זה גליץ' מספיק קטן ונדיר להתעלם ממנו.

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

  • ההחלטה השרירותית כמעט לחסום לקוח יחיד ב 200 קריאות לשנייה אולי בעייתית. תלוי בביזנס – אולי לקוחות פונים מעט וב bursts – ואז חשוב לתת להם את מלוא הקיבולת האפשרית (1000 קריאות בשנייה?). בכל מקרה, מקום לשיפור האלגוריתם ובכל מקרה לא נשמע לי showstopper.
  • עלויות של חומרה: עוד 2-3 שרתים + Redis זה עלות לא מבוטלת. האם היא נדרשת?
    • צעד מידי ופשוט לצמצום עלויות יהיה לממש את ה Rate Limiter על גבי AWS Lambda (או מקבילה בענן אחר). נשמע כמו צעד מתבקש.
    • הנה שיפרתי משהו משמעותי מתוך ביקורת עצמית מובנית 😀
  • ה Scale דיי טוב. ככלל אצבע Redis יכול לטפל ב 100,000 בקשות בשנייה. אפשר לנהל דיון על scales אדירים – אבל נשאיר את זה בצד, עד שיוכח אחרת. במקרה הכי גרוע ה Rate Limiter "קורס" – אך המערכת עדיין מוגנת.
  • עקרונות תוכנה: SOLID / other practices:
    • No single point of failure – לרדיס אין redundancy, אם הוא ייפול (ויעבור מיד restart) – יהיו 10-30 שניות של downtime (הנחה) ומידע שנעלם מהזיכרון בכל מקרה יהיה כבר לא רלוונטי (מונים של שניות קודמות).
  • ייתכן ובאמת החסימה של תעבורה לכל לקוח היא מעבר למינימום ההתחלתי ויכולנו להתחיל עם מונה מרכזי וזהו. תודה לטל רום על ההערה.

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

איטרציה ראשונה: Rate Limiter לניהול עלויות של לקוחות

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

נניח שיש לנו כמה אלפי לקוחות, וכל אחד קובע תקציב יומי להוצאות על קריאות API. בואו נענה על כמה שאלות:

  • היכן יישב המנגנון של ה Rate Limiting? בתוך המערכת – או כרכיב נוסף? – במקרה הזה נשמע שעדיף לשבת בתוך המערכת. מדוע?
    • אולי יש מספר קריאות API שמפעילים את אותה פונקציונליות שאנו רוצים לגבות עליה. מנגנון הגבייה/מעקב לא יצטרך לעקוב אחרי הדרכים השונות להגיע ללב הלוגיקה (כלומר: API1,2,3,4 דורשים חיוב)
    • אם יש תקלה ולא הצלחנו לסיים את הפעולה (Exception) – כנראה שלא נכון לחייב. כלומר – אם החיוב היה ב gateway/proxy כמו במקרה הקודם, היה עליו לפעול רק בעת מתן תשובה תקנית.
    • פחות רכיבים במערכת. ייתכן ויש לנו מערכת גבייה ("commission service" או איך שלא ייקרא) – ואז הגיוני לשים את ה Rate Limiter שם. זה עדיין בתוך המערכת – רק במקום הנכון יותר.
  • איך המנגנון יעבוד בפועל? איך יוודא שה Rate נשמר?
    • רדיס כבר לא טוב לנו. מדובר בגבייה של כסף שזה עניין מדויק שאסורים בו פספוסים, ורדיס ש"נפל" ואיבד את כל המונים שלנו – גם אינו מצב סביר.
      • סביר יותר להתחיל בסיס נתוני (רלציוני, או מה שמהערכת עובדת בה) ומשם להמשיך.
    • המנגנון עשוי להיות דיי דומה, נניח Key/Value כאשר המפתח הוא יום Epoch + זיהוי הלקוח. כל זאת כל עוד איפוס המונה ב UTC הוא הגיוני. ייתכן ולא – ואולי יש צורך לנהל את ה offset של אזור הזמן לכל לקוח / או מדיניות אחרת כלשהי.
    • מה עם לקוח שלא השתמש בחיוב שלו במשך כ 3 ימים – וביום הרביעי יש לו חיוב של 125%? האם אנחנו רוצים לאזן מקרים כאלו איכשהו – או להישאר במסגרת נוקשה של יום?
      • בגלל שאנחנו באיטרציה ראשונה – נתחיל ב"מסגרת" נוקשה של יום ונדון בהרחבות אפשריות רק בהמשך.
  • האם אנחנו צריכים כלים נוספים (Queue, Database, וכו') – על מנת לספק את המנגנון?
    • הזכרנו כבר בסיס נתונים, כי מידע צריך להשתמש persistent. אני לא רואה יותר מזה כרגע.

הנה תרשים שמתאר את המבנה:

  • אני מדמיין מבנה קיים כלשהו (בשחור), התוספות הן בכחול.
  • קודם כל, לפני הפעלת פעולה עסקית יש לבדוק האם ניתן לחייב (שלב 1). הוא יגיע ל Rate Limiter והוא מצדו יבדוק את המונה בבסיס הנתונים. הסכמה יכולה להיות key/value פשוט.
  • רק כאשר הפעולה הסתיימה בהצלחה (אני מניח? – תלוי איך המערכת עובדת), מבצעים פעולת charge שאותה נוסיף לחיוב ה counter.
    • אפשר לשאול: "מה יקרה אם יהיה exception ב increase counter? זו לא פעולה אטומית?" – התשובה היא שזה כנראה באג והתשובה כנראה מאוד תלויה במערכת הספציפית ואיך היא עובדת. נשמע לי לא רציני "לדמיין" כאלו פרטים בלי שניתן לבדוק. באופן כללי מכיוון שזה אותו בסיס נתונים – ניתן לצרף טרנזקציות (אם בסיס הנתונים תומך) ולהיות חלק מאותה פעולה אטומית בשלבים 2.1 ו 2.2.

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

  • יכולים להיות מגוון דרישות כיצד לחשב את ה Limit של כל לקוח. כל דרישה – עם פתרונות אפשריים משלה. יש מגוון אלגוריתמים ל Rate Limiting בניתן למצוא באינטרנט. העניין הוא לספק צרכים ספציפיים – ובאופן הפשוט ביותר שניתן. אין טעם להשתמש באלגוריתם מורכב ממה שנדרש – זו לא הנדסה טובה.
  • מה קורה במידה ויש לנו Scale אדיר, שבסיס נתונים יחיד לא יוכל לעמוד בו? אולי – ה latency של בדיקת המונה (קריאה לבסיס נתונים ע"פ מפתח היא לרוב פעולה של מילי-שניות בודדות) יקרה מדי?
    • בסיס נתונים רלציוני לרוב יכול לטפל בכמה אלפי בקשות פשוטות בשנייה. אם צריך יותר ניתן לנהל אולי 2 רמות של עדכונים: אחת ברדיס מהירה, והשנייה מתוזמנת ומסנכרנת, נניח כל דקה, את הנתונים מרדיס לבסיס הנתונים. כאן נוצר הסיכון שלקוח שחרג מחשבונו ייחסם רק דקה מאוחר יותר (במקרה הגרוע). האם זו פשרה סבירה שניתן לקחת? אולי החברה יכולה לספוג סטיות כאלו – בכדי להשאיר את המערכת יחסית פשוטה?
    • המקרה של latency הוא דיי דומה. אפשר לנהל שכבר מהירה ושכבה איטית. אפשר להפוך את פעולות העדכון לאסינכרוניות ואפשר להחזיק cache מקומי על המונה וכאשר הוא מתקרב לקצה (נניח: 95%) רק אז להחיל בדיקה בכל קריאה. עוד אופציה חלופית לזו היא לנהל "כרטיסיות" של גישות כאשר שרת מבקש מבסיס הנתונים בקשה ל 100 בקשות ואותן הוא מנהל בזיכרון ורק כל 100 קריאות פונה לבסיס הנתונים. יש כאן מספר מקרי קצה שדורשים טיפול – גישה אפשרית אך לא מאוד פשוטה.
      • בכל מקרה נראה שצמצום latency ו/או הרחבת scale יגיעו עם tradeoff לגבי הדיוק של האכיפה. חשוב לזכור שהרבה מורכבות טכנית יכולה להיות מומרת בגמישות עסקית, למשל הסכמה לחריגה של לקוחות בכמה אחוזים מההקצאה היומית שלהם – על חשבון החברה.
  • מכיוון שמדובר בכסף, חשוב לבדוק את מקרי-הקצה השונים ולראות שאין פספוסים משמעותיים. אני לא חושב כרגע על בעייה עקרונית, אך הייתי משאיר את העניין כנקודה לבחינה.

סיכום

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

  • תהליך בניית תוכנה (גם תכנון וגם קידוד) הוא תהליך של גילוי, חשיבה, ולמידה מתמשכים. זו טעות לקפוץ למסקנות מהירות, להחליט מוקדם ולהתקבע על כיוונים ופתרונות. לסגור אופציות. בטח שגם לממש דברים שלא ברור לנו שהם נחוצים.
    • כמעט כל "הפתרונות" שסקרתי בווב (בעיקר עבור כתיבת הפוסט הקודם: URL Shortener) היו כאלו: החלטיים, "יודעים", ומציגים תמונה של פתרון כאילו זה תרגיל בטריגונומטריה, עם התחלה וסוף חד-משמעיים. זה לא עובד כך באמת.
  • אם היה תכנון "מיטבי" (מלה שדיי צורמת לי, אגב, כשאני שומע אותה בהקשרים מקצועיים) לסגנון של בעיות: Cache, URL Shortner, או Rate Limiter – אז היה כבר Open Source אחד לכל בעיה שמשתמשים בו ודי.
    • אני מקווה שהצלחתי להדגים כיצד כל מצב עסקי מעט שונה – יהנה מתכנון שהוא קצת או הרבה שונה. ששתי הבעיות בפוסט – באמת דורשות פתרונות דיי שונים.
    • ברור שלפעמים נכון להתפשר, ולקחת פתרון קצת פחות מתאים – כי הוא זמין, אמין, או קל. אני עדיין בעד שימוש חוזר בשירותים וספריות (קוד פתוח, או בכלל).
  • טעות נפוצה שלישית היא צלילה לפרטים לפני בניית "Walking Skeleton" (קרי "שלד מהלך"). במקום לצלול לפרטים ובעיקר למימוש של סכמת בסיס-הנתונים (לרוב דומיין ידוע, שילמד אותנו מעט על התכנון והצרכים, אבל יקשה על שינויים מהותיים בתכנון) – חשוב יותר להרכיב "Flow" עובד מקצה לקצה (להלן: שלד) וגם לאמת אותו עם העולם – למשל להריץ עליו כמה בדיקות או אפילו תעבורה אמיתית של המערכת (להלן: מהלך).

אני מקווה שהצלחתי במשימה.

שיהיה בהצלחה!

אפשור מול ריסון: קרב האור באופל של ארכיטקטורת התוכנה?

פעמים רבות בחיי השתתפתי בשיחה שהחלה בערך כך:

"אז למה שלא נשתמש ב GraphQL / בסיס נתונים משותף / נעבור מ p2p ל broadcast / נסיר שכבת הפשטה מהתוכנה? – זה יעזור לנו לכתוב תוכנה מהר יותר!".

"אבל מה עם המחירים?"

"איזה מחירים? מה יותר טוב מלכתוב קוד מהר יותר? למה לא?"

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

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

הוויכוח הזה לא התחיל היום. הוא לא ויכוח בין אדם אחד לאחר, ולא ויכוח ייחודי למיקום יחיד.

זה ויכוח שמתרחש בעולם התוכנה יום וליל, מסביב לגלובס.

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

במבט-על הוא נראה כמו ה Game of Life בו "שטחים" נכבשים ומשתחררים:

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

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

לופ שלא נגמר.

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

הנה כמה התכתשויות כאלו, שהתרחשו בקנה-מידה עולמי:

— ביבשת "מבנה התוכנה" —

Design Patterns נגד … מה שהיה קודם

YAGNI מול Design Patterns

S.O.L.I.D מול YAGNI

— ביבשת ה"תקשורת" —

SOA מול RPC

REST מול SOA

newer RPC (Thrift/gRPC) מול REST

GraphQL מול newer RPC

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

אז מה קורה שם?

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

כשעלויות המחייה עולות וכואבות – דורשים הסרת חסמים / פיקוחי.

כשמתגלה ניצול / חוסר צדק של חזקים מול חלשים – דורשים בקרה ורגולציה.

הדיון הזה מתקיים בעולם כבר מאות שנים – ועדיין לא הגיע להכרעה.

האם זו בעיה כ"כ סבוכה? NP-Complete? אי אפשר כבר להציב מחשב שיפתור אותה?!

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

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

ה Tradeoff בעולם התוכנה, הוא דיי דומה:

  • בצד אחד, אפשור (Enablement) – החלטות שעוזרות לנו לכתוב קוד בצורה קלה/מהירה יותר. הסרת חסמים.
  • בצד שני, ריסון (Restraint) – בניית מנגנונים שיגנו עלינו בפני טעויות, ישמרו את הקוד קל לשינוי.
למשל: אם משתנה הוא גלובאלי (נגיש מכל מקום בתוכנה [א]) – קל לגשת אליו ולהשתמש בו. למה להתאמץ?
אפשור גבוה גורר שימוש גבוה. אנו מרבים להשתמש במה שקל להשתמש בו – וכך יש סבירות גבוהה ששימוש במשתנים גלובאליים, שמקצרים כתיבת קוד, יהפוך במהרה לפופולארי ובעל שימושים רבים. מפתחים מעדיפים לכתוב פחות קוד – וטוב שכך!
אפשור כמעט תמיד עוזר בטווח הקצר (אחרת: מה הטעם?), ומחיריו לרוב מתבררים רק בטווח הבינוני או הארוך. שימוש במשתנים גלובאליים יכול להוביל למחירים הבאים:
  • שינוי בהגדרת המשתנה, למשל: טיפוס או פירוק שלו לשני משתנים שונים – עשוי להיות קשה מאוד. עשרות או מאות מקומת בקוד צריכים להשתנות. כל המקומות הללו – צריכים להיבדק ויש סיכון לרגרסיה. מכאן: עבודה שחשבנו שתעשה בשעה – עכשיו אורכת ימים, באופן בלתי צפוי.
  • למשתנים הגלובליים אין "הקשר" ולפעמים קשה לזכור / להבין מה משמעותם המדויקת. כל פרשנות שגויה עשויה להיות באג בתוכנה.
  • "פיצוץ" המרחב הגלובאלי במשתנים מקשה עלינו לבחור בין משתנים בשמות דומים, ולזהות מי הוא מי.
  • קשה יותר לכתוב בדיקות יחידה – לקוד שיש לו קשר למשתנה הגלובאלי.

אז מצד אחד אפשרנו – זזנו מהר, מהרגע הראשון.

מצד שני – בטווח הבינוני או הארוך – אנחנו משלמים מחיר שמאט אותנו.

מה עדיף?

הפתרון

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

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

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

הפעולה ההפוכה הייתה ריסון. ריסון מושג ע"י משמעת ("אסור להשתמש במשתנים גלובלאליים") או ע"י מניעה (שפות חדשות הסירו את היכולת להגדיר משתנים גלובאליים).

שפת ג'אווה (1995), למשל, הלכה צעד הלאה וקבעה נורמה של שַׁלְפנים (Getter/Setters) על האובייקטים: הקצנה של הלקח של "אסור לאפשר משתנים גלובאליים" – על scope מצומצם בהרבה, הרי הוא האובייקט. אינספור מפתחים בזבזו במצטבר שנות חיים בכתיבה של getter/setter גם למשתנים שלעולם הגישה אליהם לא תשתנה, ולעולם לא יעשה בהם שימוש לרעה.

אחרי כמות אדירה של סבל (או לפחות: בזבוז) שהצטברו – המגמה התהפכה. שפות רבות מאפשרות ומעודדות גם חשיפה של משתנים שלא דרך שׁלְפנים, ודרכים אלנגנטיות להוסיף שלפנים רק בעת הצורך. Records שהוצגו בג'אווה 14 – באיחור רב, הם דרך אחת לחסוך כתיבה של שלפנים עבור מבני-נתונים (במובן ה OO שלהם).

הנה לנו עוד מחזור.

לכאורה נראה שחשוב ללמד אנשים לנתח את ה tradeoff בין אפשור וריסון – כדי שיחליטו טוב יותר.

אבל:

  • אנשים, בייחוד בעלי ניסיון מועט, אבל גם בכלל – נוטים לבצע הערכת-חסר של העלויות ארוכות הטווח שעלולות להגיע מהסרת הגנות (חסמים שיש להם חשיבות). קשה להעריך זמנים, וקשה יותר להעריך את התוצאות העתידיות של שינוי פשוט לכאורה בקוד.
  • לאנשים, במיוחד בעלי ניסיון מועט – יש נטייה חזקה לטובת האפשור, על פני הריסון: זה מבאס לרסן. זה מענג לאפשר. והאופטימיות תמיד תתעדף עונג על פני באסה.
  • "בוא ננסה ונראה" היא לא גישה מספיק טובה: האפשור כמעט תמיד נראה חיובי בטווח הקצר, והמחירים מתגלים לרוב אחרי שהם כבר מצטברים.
    • זה נשמע דמיוני שבעקבות אפשור פשוט, שחסך כמה דקות בכל פעם – יידרשו מאוחר יותר חודשי-עבודה של מפתחים מיומנים בכדי לחזור בחזרה למצב הקודם – אבל זה קורה.
  • אנשים שונים רואים את ה tradeoff בצורה שונה – מה שמקשה על הסכמה מהירה.
    • סגנונות עבודה שונים, ועבודה על פיצ'רים / חלקים שונים במערכת – משפיע על ההסתכלות שלנו על העניין.
    • מצב-מעורב, בו חלק מהמפתחים בוחרים באפשור וחלק בריסון לרוב לא מפחית משמעותית את מחיר אפשור-היתר, ויוצר מתחים בקבוצה.
מפה לשם, האיזון בין ריסון לאפשור מוסכם לרוב ברמה קבוצתית:
  • גם ברמה ארגונית: צוות / קבוצה / ארגון פיתוח.
  • גם ברמת קהילתית, למשל: מפתחי ה React בחברה / בישראל / בעולם.

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

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

בכל זאת, הסיכון הוא לא לגמרי סימטרי:

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

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

נדמה לי שבחברות תוכנה, ובתרבות הישראלית בפרט – המצב הזה הופך ליותר ויותר נדיר.

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

תסביר שוב: מה הנזק מאפשור-יתר / ריסון-יתר? אז מה עושים?

אפשור הוא הרצון להתקדם מהר ע"י הורדת חסמים. דוגמה קלאסית (ואמיתית): חשיפת נתונים מבסיס-הנתונים ישירות ב HTTP. למשל: אפליקציית הווב פונה ישירות לבסיס הנתונים ושולפת מידע (מסוים), וכך לא צריך לעבור דרך API GW ודרך ה Backend – חסכנו עבודת פיתוח ושיפרנו את הביצועים.

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

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

האם זה רעיון טוב או לא? זה תלוי בהקשר.

יהיו פעמים שכן – שזו תהיה הדרך הפשוטה והטובה לעשות את הדברים.

במערכת אפליקטיבית בה:

  • המודל, ומכאן סכמת בסיס הנתונים משתנה מדי-פעם.
  • שכבות אפליקציה מטפלות בנתונים (בכתיבה, אבל גם בקריאה), ומפעילות לוגיקה-עסקית עליהם – שגם היא משתנה.
  • דרישות צד-הלקוח משתנות לאורך זמן.
גישה ישירה מצד-הלקוח לבסיס-הנתונים עשויה להתגלות ככדור (תותח) ברגל. הפיתוח יתקדם מהר, אבל אז:
  • יתגלה באג שלא ברור מדוע הוא מתרחש: מישהו הוסיף קוד אפליקטיבי שאינו חל על הקריאה הישירה מבסיס הנתונים.
  • שינוי פשוט לכאורה, נניח: שינוי במודל שדורש שינוי בסכמה של בסיס הנתונים – הופך לשינוי קשה, ארוך, ובעל הזדמנויות רבות לתקלות.
    • יש כאן גם חוסר-הוגנות ארגוני פוטנציאלי: מפתח אחד אפשר וחסך זמן בפיתוח הפיצ'ר שהוא אחראי אליו, בעוד מפתח אחר נאלץ לשלם את המחיר היקר שנגרר מאותו אפשור.
    • נתקלתי במצבים כאלו פעמים רבות – והם לא מסייעים לתחושת השותפות והידידות בארגון, במיוחד אם צוות אחד מאפשר תדיר על חשבון אותו צוות אחר שמשלם את החובות-הטכניים של אותו האפשור.
ריסון הוא הרצון להגן על המערכת ע"י הצבת חסמים מלאכותיים. במילה "מלאכותיים" הכוונה היא שיש דרך לבצע את הפעולה באופן קל יותר – אך אנחנו יוצרים חוקים / מגבלות פיסיות שלא יאפשרו זאת.
דוגמאות:
  • השימוש ב private על members בפרדיגמת ה OO – הוא ריסון ברמת המיקרו. למעבד אין בעיה לגשת לכתובת הזו בזיכרון – אבל אנחנו מורים לו לא לעשות זאת (ומשלמים תקורה בביצועי התוכנה / זמן כתיבת הקוד).
  • כלים לניהול תלויות בין מודולים / מיקרו-שירותים או נהלים להגבלת ספריות ה open source שנכנסות למערכת: אין למתכנת בעיה להוריד כל ספריה ולהתשמש בה – אבל הארגון רוצה לבדוק את הספרייה מבחינת אמינות / תמיכה / כפילות / רשיונות / היבטי אבטחה – לפני שזה נעשה.
  • קונבנציות של קוד – הן ריסון. הקומפיילר יקבל סגנונות שונים ומשונים – אבל הארגון מחליט שבנקודות מסוימות הוא מקבל סגנון רק מסוים.
  • לפעמים גם בחירה של שפת-תכנות היא ריסון. שפת Go מחייבת מבנה אחיד ופשוט הרבה יותר משפה משופעת באפשרויות כמו רובי. מעבר מרובי ל Go – הוא ריסון ניכר.
דוגמה קלאסית לריסון-יתר הוא Closed Layered Architecture מרובת שכבות. בכדי להתגונן בפני בעיות שונות בכתיבת מערכת, הומצא מודל השכבות בו כל שכבה יכולה לקרוא רק לשכבות מתחתיה. בגרסה ה"סגורה" של המודל, כל שכבה יכולה לקרוא רק לקוד באותה השכבה או בקוד בשכבה אחת מתחתיה:
כלומר: אם קוד בשכבה 4 רוצה לקבל נתונים משכבה 2 עליו:
  • לקרוא לשכבה 3 ולבקש את המידע.
  • שכבה 3 תקרא לשכבה 2 ותבקש את המידע.
  • המידע חוזר במבנה הנתונים ששכבה 2 מכירה (אך שכבה 3 יכולה להשתמש בה).
  • שכבה 3 לא יכולה להעביר את מבנה הנתונים של שכבה 2 לשכבה 4 (אסור!) ולכן היא מגדירה מבנה נתונים משלה למידע שאותו היא חושפת בפני שכבה 4, לאחר המרה, כמובן.
ייעצתי פעם לארגון שעבד עם מודל של 6 שכבות סגורות. המערכת לא הייתה עשירה כ"כ ב business logic ורובה ביצעה אינטגרציה בין מערכות.
מידע רב עבר בין שכבה 2 לשכבה 6 – ורוב הקוד בשכבות 3, 4, ו 5 פשוט תרגום שוב ושוב קריאות, הלוך ושוב, למבנים שקולים – אך שונים. חשיפת נתונים בין שכבה 2 לשכבה 6 דרשה כמות נכבדת של קוד? על מה?!
אני בטוח שמישהו הגיע עם כוונה טובה. הוא קרא מאמר או שמע הרצאה על מערכת שעבדה ללא סדר / שכבות – והפכה לסיוט לתחזוקה. אני מדמיין שהוא החליט לא ליפול לפח ולעשות את "הטוב ביותר". לא רק 3 שכבות – אלא 6! לא רק שכבות – אלא שכבות סגורות. Crème de la Crème!
הנזק כאן כמובן היה אדיר,שעות מפתחים ושחיקה רבה ממשימות בסיסיות. אני מקווה שהחברה בסוף יישמה את הרעיון הפשוט של לעבור למודל פתוח או לפחות פתוח-למחצה.
נ.ב. האוונגליסטית לשינוי הייתה דווקא מישהי שרק התמנתה לתפקיד ארכיטקטית. לארכיטקטים הותיקים והמנוסים בחברה היה blind spot למצב, ולאבסורד שבו.

סיכום

אז מה אפשר לקחת מכל הסיפור הזה?
דבר ראשון – אני מקווה שחידוד הנושא יעזור בפעמים הבאות שתתקלו בדילמה שבין אפשור וריסון – ותצליחו להסתכל על הדילמה במבט מעט יותר מפוכח.
דבר שני – הזהרו מהטיעון (נא לקרוא במבטא צרפתי): "ואז: Walla!, נפתח קוד הרבה יותר מהר!" וגם מהטיעון ההופכי "ואז, !Walla, לא עוד בעיה מסוג X במערכת – וחדל לבזבוז הזמן".
כשמישהו מציע אפשור / ריסון משמעותי במערכת, אני אישית, הייתי רוצה לראות אותו\אותה בפנים מיוסרים (מלבטים). בדרך אני נתקל בהם כשפניהם זורחות והם מלאי אנרגיה (שלא לומר: זחיחות) – אני ארגיש הרבה יותר טוב כשהם יהיו מיוסרים, ויאמרו משהו כזה:
"אני חושב לאפשר/לרסן את הדברים כך וכך, הנה ההזדמנויות (מציאותיות), אבל הנה גם הסיכונים (שמטרידים גם אותי). מה אתם אומרים?"
זו הדרך המקצועית לגשת לדיונים כאלו. כשכולים מכירים בכך שמדובר ב tradeoffs לא פשוטים – הדיון הופך לקל ויעיל יותר.
אני משוכנע שאין פתרון אחד כולל / נכון-תמיד ל treadeoff שבין אפשור לבין ריסון.
אבל אני גם מאמין שבחשיבה נכונה, אפשר ברמת המערכת / הארגון הספציפי – למצוא tradeoffs הרבה יותר טובים מבחירה שרירותית. ואם טועים – אפשר גם לתקן.
הפסיקו להסתכל מתחת לפנס, ולהניח שהדברים עומדים להסתדר ע"פ התסריט האופטימי שבו הייתם רוצים!
לא עוד "הפיתוח יטוס מעכשיו בטיל".
או "מערכת שהיא בטון יצוק".
דיי. מאסתי בתיאורים כאלו.
בואו נהיה מקצועיים.
שיהיה בהצלחה!

[א] בשפות שלא תומכת משתנים גלובאליים ניתן לחשוב על משתנה שעל אובייקט שנגיש לכולם.

תכנון ופיתוח תוכנה: מידול קונספטואלי

כבר כמה זמן שאני רוצה לזקק את תחום תכנון (Design) יעיל של תוכנה. זה תחום שיש בו מקום למיומנות רבה, אבל מאתגר מאוד ללמד. בכדי להתמודד עם האתגר, אתמקד בפן אחד (להלן Divide & Conquer) של אומנות ה Design: מידול.

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

  • משתמשים במונח "מידול" כתהליך ההצגה של העיצוב (Design). כמטאפורה: אדריכל שבונה מודל מוקטן של הבית בכדי להציג אותו ללקוחות.
    • כאן נכנסות "שפות מידול" (UML, ERM, ADL), ומתודולוגיות מסוימות (C4, ATAM, 4+1 Views). הטכניקות הללו מעט ארכאיות לתקופתנו ואני לא מתכוון לעסוק בהן.
  • משתמשים במונח "מידול" כדי לתאר רעיון של יצירת מודל מפורט/מדויק שיחליף את הקוד / נחולל קוד ממנו. כאן המודל הוא פורמאלי, מדויק, ודורש עבודה ותחזוקה רבה. ניתן לאפיין כאן שתי גישות עיקריות:
    • מידול מבנה או נתונים – בגישות כמו Model Driver Architecture (קרי MDA), או מידול של בסיסי נתונים.
    • Semantic Modeling עבור מערכות לעיבוד שפה טבעית או Ontology modeling (אונטולוגיה – הגדרת קשרים בין מונחים) ליישומים יותר כללים של בינה מלאכותית.
    • אני לא מתכוון לעסוק בנושאים הללו בפוסט.
  • משתמשים במודל "מידול" כתהליך ביניים באיסוף דרישות, תיאור העולם / צרכים / דרישות בצורה מאורגנת ומדויקת יותר – לפני שמייצרים את העיצוב הטכני וכותבים קוד. הדרך המקובלת ביותר לתאר מודל מסוג זה היא מודל קונספטואלי (Conceptual Modeling) ועליו אני הולך לדבר בפוסט הזה.
    • על אף שראיון המודל הקונספטואלי נמצא בשימושים כבר עשורים, רבים מקשרים אותו למתודולוגית ה Domain-Driven-Design (בקיצור: DDD) – שהביאה אותו לחזית הבמה / הפכה אותו לקצת יותר מדובר ופופלארי בתחילת שנות ה 2000.

פאק! מעולם לא הגדרתי מודל קונספטואלי. האם זה אומר שאני עושה Design גרוע?!

תנו לי להרגיע: היה לכם מודל קונספטואלי בכל ה Designs שעשיתם. פשוט לא ידעתם את זה.
כמו כן: הגדרה של מודל קונספטואלי up front – הוא רעיון שנראה שלא הוכיח את עצמו לאורך השנים. אי הקדשת זמן להגדרת מודל קונספטואלי up front – הוא כנראה הדרך היעילה יותר לעשות דברים.
אי אפשר לחשוב וליצור תוכנה – בלי מודל קונספטואלי בראש. ברור שיש לכם איזו קונספציה על איך הדברים קורים / צריכים להיות. זה המודל הקונספטואלי שלכם. אולי הוא לא תתועד / מתוקשר / מזוקק – אך הוא בהחלט קיים.
הבעיה במודלים קונספטואליים היא שאנשים שונים בונים לעצמם בראש מודלים שונים, כל אחד "והאמת שלו". למה זו בעיה? האם לא טוב שיש מעט שונות (Diversity) / נקודות מבט מגוונות?
ראו גם: Mental modelRepresentation (psychology), and Cognitive model

הרבה פעמים זו לא בעיה, אולי זה מספיק טוב. לגיוון בהבנה / תמונת-עולם גם יכולה להיות תרומה.

הבעיות שצצות לרוב הן:
  • א: פערים משמעותיים בהבנה בקרב מפתחים שונים => קוד לא עקבי, או אפילו סותר.
  • ב: יש תמימות-דעים בקרב המפתחים – אבל כולם טועים / לא מבינים נכון את הביזנס.
  • ג: יש פערי-הבנה בין אנשי הביזנס, מה שמבלבל ומקשה על המפתחים להבין.
  • ד: כל התשובות נכונות.
 
כלומר, בגישת ה Lean אנחנו לא ניגשים להגדיר מודל קונספטואלי ב"תחילת הפרויקט", אנו מגדירים אותו כאשר אנחנו מזהים בעיית תקשורת משמעותית.
משמעות נוספת של האמירה הזו היא שלא ננסה אפילו "למדל" את כל הביזנס ומה שקורה בו – אלא רק איים מרכזים / חשובים בביזנס – שגורמים לנו לבעיה בכתיבת המערכת.
איך מגדירים מודל?
כל תרשים או טקסט הם טובים מספיק. המרכיבים שבעזרתם מגדירים מודלים מורכבים בעיקר מ:
  • ישויות (Entities)
  • קשרים (Relations)
  • תכונות (attributes) של הישויות. אולי גם מתודות.
  • הכללה / ריבוי-צורות.
  • הבחנה בין מחלקה/קבוצה למופע (instance).
  • כלי עזר: טקסט.
  • כלי עזר: קוד.

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

הדרכים הנפוצות להגדיר מודל, שאני נתקלתי בהן, הן pseudo-UML (לא צריך לדקדק), קוד, או פשוט מסמך וורד/מצגת.

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

דוגמה למודל קונספטואלי

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

הנה, למשל, כמה אפשרויות למודלים שונים לכסף (Money), איזה הוא המוצלח לדעתכם?

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

הערה: לא פעם אנשים יתקשו לתאר את המודלים ש"יש להם בראש", אל אף שהוא עקבי ולעתים אף מפורט. אם אלו אנשי-תוכנה, לפעמים עוזר לבקש פשוט מאוד לכתוב קוד / סכמה של בסיס נתונים כדי לנסות ולשחרר את "מחסום התקשורת".

ובכן, מתוך ארבעת המודלים של Money, איזה מודל הוא המתאים / המוצלח ביותר?

כמובן, כמובן – שכל מודל מתאים לכל סיטואציה. יש מערכות / מקרים בהם מודל #4 הוא מספיק טוב – ואז מודל מורכב יותר יסרבל את הפיתוח ללא סיבה. יש פעמים שמודל #3 הוא טבעי ויש מקרים בהם הוא לא-קשור-למציאות.

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

המודל גם מתאר tradeoffs טכנולוגיים. במקרה שלנו: מחשב ספרתי, בו כל מספר הוא כפולה של 2, אינו יכול לייצג בדיוק מספר כמו 1.1 – סכום לגיטימי לחלוטין לכסף. יש דרכים שונות להתמודד עם האתגר, ולא "לאבד" סנטים בעקבות פעולות חשבוניות / פעולות עיגול. למשל: שימוש ב Big Decimal או הייצוג הסנטים כמספר שלם (Long).

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

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

אז איך אפשר "לדפוק" מודל קונספטואלי?

עד כה, יכול להיות שאתם אומרים לעצמכם: "ברור!" " "זה פשוט" " "זה בדיוק מה שאני כבר עושה". כל זה – טוב ויפה.

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

"האחרון להבין ולזהות" 

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

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

"מודל טוב מדי"

זה אולי לא נשמע כ"כ רע – אבל זו טעות נפוצה וכואבת.

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

הכל נעשה מכוונה טובה, אבל חשוב לשים לב שתהליך מידול לא הופך בטעות ל Over-Engineering. הוא בקלות יכול להגיע לשם.

"מודל נאיבי"

לא פעם אפשר לסיים את עבודת המידול בשיחה קצרה בת 30 דקות: הצלחה גדולה (!), ויוצאים לדרך.

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

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

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

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

מודל אלגנטי יותר מהביזנס

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

  • לכל מכירה יש תעודת משלוח אחת – בעוד בביזנס, בשל מורכבות אופרטיבית, לעתים מנפיקים (בטעות) שתי תעודות משלוח שונות לאותה ההזמנה.
  • זיכוי יהיה כסכום החיוב – בעוד בפועל לעתים מזכים יותר או פחות בשל נסיבות ("פיצוי", "קיזוז") שונות שלא נכנסות למודל.
תת-וריאציה היא פשוט תקלות טכניות (הרבה פעמים: בצד התוכנה), שאנו נוטים לשכוח / לא מכירים בזמן המידול:
  • ללקוח יש Cookie שמזהה אותו בצורה מדויקת – בעוד חלק לא זניח מהמשתמשים, מתקינים "חוסם פרסומות" שמוחק Cookies, והמידע לא שלם.
  • ה GPS מדווח במדויק את נקודת ההתחלה והסיום של הנסיעה – בעוד בפועל בשם טעויות / רמאויות קטנות של נהגים, המידע לעתים שגוי או אפילו חסר.
תקשורת לקויה / חסרה
ישנו מודל, הוא טוב למדי – אבל נמצא בראשם של 2-3 אנשים. מכיוון שהוא לא מתואר בצורה מספיק ברורה / מדוייקת – אנשים אחרים מסביב מפתחים בראש "וריאציות" של המודל – ובעצם לא השגנו את מטרת המודל.
לא פעם מציינים continuous integration ככלי התומך במודלים הקונספטואליים. אם הקוד של מפתחים שונים צריך להתחבר ולעבוד מוקדם זה עם זה – הפערים יצוצו ויהיה קל / זול יותר לתקן אותם.
מודל חד-כיווני

"אלו הן הדרישות של הביזנס" – הוא משפט שגור, שמהווה smell לבעיה הזו.

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

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

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

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

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

כמובן ששני מודלים שונים עשויים לגרום לבלבול וטעויות. חשוב להגדיר bounded context – גבולות ברורים וחד משמעיים ואלו חלקים במערכת ובביזנס משתמשים במודל א" ואלו במודל ב". כמו כן חשוב תרגום טוב מספיק בין המודלים – בנקודות החיבור של המערכת ב contexts השונים. יש המציעים בהשנות מקרים כאלו ליצור context map – מיפוי של כל ה contexts, הגבולות, והתרגומים בין המודלים ה"חופפים". "Good fences make good neighbours" – הם אומרים.

מודל תוכנה השונה מדי מהמודל הקונספטואלי

מודל קונספטואלי הוא מחשבות / רעיונות / סדר – המוצגים בתרשימים, מסמכים ולעתים קצת קוד (יש כאלו שיאמרו – "כתבו interfaces").

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

אפשר ליצור אותם שונים זה מזה, אפילו במידה ניכרת.

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

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

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

סיכום

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

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

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

לא נכנסתי לטכניקות קונקרטיות / מפורטות יותר של מידול – כי אין הרבה כאלו. כלומר יש את Event Storming ויש כאלו שיחשיבו את CRC Cards כטכניקה של מידול (דיי דומה, למען האמת) – אבל סה"כ אין הרבה טכניקה מדוייקת שאני יודע לקשר לנושא.

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

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

שיהיה בהצלחה!