בשני הפוסטים הקודמים של "תכנון מתוך דוגמה" (א.ק.א Design By Example), התמקדנו במציאת פתרון לבעיה קונקרטית. זו חלק קריטי בכל תכנון שהוא – אבל יש בתהליך התכנון גם מעבר לזה. בפוסט הזה נרצה להתקדם מעט יותר ב Liorson Software Design Maturity Model ולגעת ברמות השנייה (החצנת כוונות) והשלישית (התאמות לעתיד) של תכנון מערכת. הפשטות (Abstractions), הן כלי מרכזי בשתי הרמות הללו.
ברמה 1, אנו יכולים ליצור תכנון פשוט ויציב – אך חסר המשכיות: בסיבוב הראשון התכנון יעבוד טוב, אך ככל שיבואו עוד מפתחים ולא יבינו אותו ולא יצליחו להשתלב בו – התכנון ילך ויעלם. מי שיראה את הקוד כעבור שנתיים עשוי להסיק שמעולם לא נעשה תכנון לאזור הזה, ורק נכתב קוד בכדי לספק מטרות קצרות-טווח. האזור עשוי להיות בבלאגן.
תכנון טוב יותר (השאיפה של רמה 2) יחצין את מהות התכנון והכוונה למפתחים שעובדים עם הקוד, כך שבמקום לא-להבין את התכנון או להתעלם ממנו – הם ימשיכו ובשאיפה ישפרו אותו. זה ההבדל בין תכנון קצר-חיים, שיאבד משמעות לאחר מספר שינויים באזור, ותכנון שישרוד מידה של שינויים, ואף יתפתח בעקבותיהם.
ברמה השלישית, אנחנו מנסים לחזות את העתיד, ולהתכונן אליו. אם הכנה של שבוע עכשיו, תחסוך חודשיים של עבודה בהמשך הדרך, האם לא שווה להשקיע את השבוע עכשיו?
אזהרה: יש פה עניין של ניהול סיכונים. אם אחוזי הקליעה שלנו טובים – זה משתלם. אם הם קלושים – אז כנראה שאנחנו מבזבזים זמן לשווא וגם מסבכים את המערכת. בהקבלה: כולנו היינו רוצים להשקיע במניה של אמזון לפני עשור (בדיעבד), אבל האם אנחנו יודעים היום לומר מי תהיה אמזון הבאה? ואם נדמה לנו שכן – מה הסיכוי שבאמת נקלע?
עבור שלב 2 של המודל (החצנת כוונות) עומדים לפנינו כמה כלים:
- שיקוף – שמות נכונים ובעלי משמעות בקוד (כפי שהרחבתי בפוסט על קוד ספרותי). מבנה שמתאר משהו שקשה להתעלם ממנו.
- כדברי הדוד בוב: "אם אתם מסיירים במבנה שהוא כנסייה, ברור לכם שזו כנסייה. אם אתם מסיירים במבנה שהוא בית חולים – ברור לכם שזה בית חולים. הארכיטקטורה שלהם 'צועקת' את הכוונה, ולא ניתן להתבלבל".
- הפשטה – בניית מודל קונספטואלי / מטאפורות שיבטאו כוונה, ויספרו את "הסיפור של התכנון" כך שאחרים יוכלו להבין אותו, להמשיך אותו, ולהרחיב אותו.
- התווית דרך – כתיבת הקוד כך שסטייה מהתכנון היא קשה ("מענישה") והצמדות לתכנון (או הרחבת התכנון ע"פ העקרונות) – היא קלה ("מתגמלת").
"החצנת משמעות" היא לא שלב נפרד בתהליך התכנון – ההכוונה היא כבר חלק מפתרון הבעיה, וכמובן חלק חשוב מהמימוש. כאשר אנחנו בוחנים חלופות לתכנון – היבט חשוב לשקול הוא כמה הכוונה תסביר את עצמה. כמה סביר שהבאים לעבוד באזור יאמצו וימשיכו את התכנון, ולא יתעלמו/לא-יבינו ובמגע ראשון יסטו לכיוון אחר.
בואו נתחיל בתיאור של בעיה.
הבעיה שברצוננו לפתור
אנו רוצים לתכנן מערכת שאלונים. אנו רוצים שבעלי מסעדות / רשתות מזון יספקו לנו מידע חשוב על העסק שלהם. אלו יכולים להיות עסקים שונים בתחום המזון.
- "שאלון" הוא רמת העל, מקצה לקצה – של כל מה שאנחנו שואלים את בעל העסק.
- השאלון מורכב מדפים, שבכל דף כמה אלמנטים: כותרות, שאלות, ולעתים תמונות / דיאגרמות (התומכות בשאלות).
- בשאלון אנו אוספים מידע על "ישויות" השייכות לעסק. למשל, ברשת מסעדות – אנו רוצים אוספים פרטים על הרכבים של העסק, ועל המבנים (Facilities, יכולים להיות גם מבנים ארעיים).
- עמוד מיוחד, Facilities למשל, מציג את רשמית המבנים ומאפשר להוסיף / להוריד מבנים מהרשימה.
- כל הוספת מבנה תציג סט של שאלות שיש לענות לכל מבנה. למשל: 10 שאלות לכל מבנה, המתפרסים על פני שני עמודים.
- לאחר שמסיימים את איסוף הפרטים על המבנים, לוחצים בדף ה Facilities על הכפתור "Continue" וממשיכים ברצף השאלון.
- עמוד מיוחד, Facilities למשל, מציג את רשמית המבנים ומאפשר להוסיף / להוריד מבנים מהרשימה.
- אהה… ורק בדף של ה Facilities צריך גם להציג שאלה אחת "Include warehouses?" שמשפיעה על השאלות שישאלו לכל מבנה. זה אמור להיות דיי יוצא דופן, ולא להופיע כמעט אף פעם באובייקטים אחרים (רכבים, שותפויות/מועדוני לקוחות (לרשתות מזון), וכאלו…).
הדרישות דיי ברורות לדעתי. שימו לב שבמקרה הזה, בניגוד לבעיות הקודמות שעסקנו בהן – ה flow או המבנה של המערכת הוא לא המקום שנרצה לפתוח בו. הוא נשמע יחסית מובן מאליו. הסיכון הגדול "לשינוי התכנון מהיסוד" הוא מודל הנתונים, ולכן נפתח בו. תמיד נרצה לפתוח בנושא שיכול לשבש לנו את התכנון במידה הגבוהה ביותר.
החלופות
מרחב האפשרויות למודל נתונים הוא גדול מאוד, עם מספיק זמן פנוי אני כנראה אוכל לתאר 10-20 חלופות (במשפחות שונות) – אבל זו לא תהיה השקעה יעילה של זמן. הרבה יותר הגיוני לבחון 3-4 חלופות, שונות מספיק, שנראות סבירות ברמת תחושת הבטן – ולבחור מהן. כמובן שיש מקום לשיפור ושילוב בין החלופות, תוך כדי שאנחנו מבינים אותן.
אני ממליץ לכם לקחת קצת זמן ולבחון את החלופות ולראות שאתם מבינים אותן. לכל חלופה הוספתי תיאור קצר כדי לוודא שהכוונה מובנת כהלכה. אנחנו עדיין לא מנתחים אותן.
חלופה 1:
- Step הוא צעד בשאלון, שיכול להיות דף (Page) או צומת לניהול ישויות (Entity Hub). זה השלב שבו אנו יכולים להוסיף ולהסיר רכבים, מבנים וכו'. אשתמש בכל החלופות במונח Entity Hub בכדי לא לבלבל.
- כל דף מכיל סדרה של אלמנטים. ב UML (שפת התרשימים לתיאור מבנה של תוכנה) סימן ה
*מתאר יחס של רבים. כלומר: לדף יחיד – יש אלמנטים רבים (1 או יותר), ואולי מסוגים שונים – כפי שתיארנו למעלה.- על מנת לוודא שברור: גם דף יש יותר מאחד. השאלון (Questionnaire) מכיל צעדים רבים, ודף הוא Generalization (ראש חץ לבן חלול ב UML) של Step.
- Entity Hub מחזיק קשר למספר דפים, אלו הדפים שצריכים להישאל לכל ישות שמטפלים בה: נניח 2 דפים של שאלות לכל Facility, כמו שראינו בתרשים למעלה.
חלופה 2:
- הפעם אלמנט הוא תכונה של QuestionniareStep (האם זה שם עדיף? מה המשמעות של בחירה בשם זה או הקודם?) כך שבעצם יש לנו אלמנטים (שאלות, למשל) גם ב EntityHub. זה עוזר לכסות את מקרה הקצה ב Facility Hub, בו עלינו לשאול שאלה. מי יודע, אולי אם הזמן נגלה שאנו צריכים להציג עוד אלמנטים בתוך ה Entity Hubs?
- ה Entity Hub לא מחזיק דפים, אלא Questionnaire Steps – מה שמאפשר לו להחזיר שורה של דפים (המקרה הידוע) אבל גם Entity Hubs בנים – מה שיכול לאפשר היררכיה. למשל, איסוף מידע על מחסנים (Warehourses) בכל מבנה (Facility). לא נדרש היום, אבל האם זה לא יהיה חכם לאפשר את זה במודל כבר מעכשיו?
חלופה 3:
- במקרה הזה, אנחנו מגדירים EntityHub כסוג של אלמנט. כלומר: ייתכן שה Entity Hub הוא דף עם אלמנט יחיד: ה EntityHub.
- הדבר מאפשר להוסיף את השאלה שאנו נדרשים ב FacilityHub, וגם מאפשר בצורה טבעית לשלב בין Hub לאלמנטים נוספים באותו הדף: כמה שאלות, כותרות, או תמונות. הדבר גם מאפשר לצרף 2 EntityHubs באותו דף. למשל: לאסוף רכבים ומבנים – באותו דף של שאלות (כמובן שכל ישות: רכב או מבנה תפנה לשאלות משלה).
- ע"י כך שהפכנו את ה EntityHub לסוג של Element – ייתרנו את ההפשטה של Step/QuestionnaireStep – וכך בעצם פישטנו את התכנון!
חלופה 4:
- המבנה הזה, האמת, דומה מאוד לחלופה הראשונה – אבל מתאר הבדל אחד גדול ומשמעותי: ה EntityHub לא מחזיק דפים, הוא מחזיק Questionnaire.
- הדבר מאפשר לנו ליצור היררכיה של EntityHubs, דומה למה שתואר בחלופה 2 – אבל בדרך אחרת. (איזו דרך עדיפה? מה היתרונות / חסרונות של כל גישה?)
- יש כאן משמעות עתידית דיי גדולה, בכך ש EntityHub מצביע לשאלון: במקום להחזיק "רשימה של דפים" עם ולהיות מוגבל ליכולות שלהן, כל Entity (רכב, מבנה, וכל אלו שעוד יגיעו) – יזכה לשאלון עם כל היכולות שיהיו קיימות. אלו עשויות להיות יכולות ברמת מבנה הנתונים (למשל: מוסיפים ל Questionnaire שם או צלמית ייחודית שמופיעה ב UI) או ברמת ההתנהגות (יכולת "לאפס" שאלון, יכולת לשנות באופן אקראי את סדר הדפים בשאלון) – שעכשיו יהיו תקפים לשאלון של רכבים / מבנים מעצם היותו של סט השאלות "שאלון" ולא "רשימה של דפים".
- (יש איזו מידה של עצמאות/כוח שאנחנו נותנים לשאלות של Entities. האם זה דבר טוב או מזיק? מה המשמעות של זה?)
השתתפות הקהל
ארצה לעצור כאן, ולהמתין מעט עם הניתוח של האופציות ומשמעותן.
הייתי רוצה מאוד לתת לכם זמן לנתח את המצב בעצמכם (בכל זאת, אלו פוסטים לימודיים, לא?), ויותר מזה – אשמח מאוד לשמוע את דעתכם. הכל מתוך תרגיל לימודי, גם אם הניתוחים שלי אח"כ יהיו שונים משלכם – זו הזדמנות גם עבורכם וגם עבורי ללמוד משהו.
Google Analyhtics טוען שכל פוסט בבלוג נקרא ע"י בין 500 ל 2,000 קוראים (בד"כ). הייתי שמח לבדוק אם אלו בוטים או אנשים אמיתיים 😉.
עוד כשבועיים (סוף נובמבר) – אפרסם את הניתוח שלי על הדברים. אתם תראו שהוא מאוד תלוי סיטואציה, אין פה באמת "נכון" או "לא נכון" – אלא בעיקר "מתאים לסיטואציה X" ו"מתאים לסיטואציה Y".