נתבקשתי ע״י אפרת וולפנר-תורג’מן (ידידה ותיקה) ודור מצפי, שמקימים בימים אלה את גילדת התוכנה בחברת סמסונג – לבוא ולדבר קצת על תכנון תוכנה (Software Design).
האתגר שלהם: מגוון רחב מאוד של אנשי תוכנה: FE, BE – קל להבין, אבל בגילדה שלהם יש גם אנשי Data Science / ML, Data Engineers, Embedded, ו Firmware. כולם כותבים קוד, אבל באמת צורות העבודה של המקצועות הללו היא שונה דייה, כך שלא קל למצוא ברמת הקוד דוגמאות הרלוונטיות לכולם.
האם דזיין הוא שונה? האם אפשר באמת להגדיר כללים זהים שיתאימו גם למפתחי FrontEnd, גם לאנשי Machine Learning, וגם לאנשי Firmware.
לקחתי על עצמי את האתגר – והאמת שהוא לא היה קשה.
תהליך דזיין הוא מיומנות. השוואתי אותו לטניס שולחן – אותו כולם משחקים (או יכולים לשחק בלי למידה משמעותית), אבל יש אנשים בעלי מיומנות נמוכה ובעלי מיומנות גבוהה – וההבדל בתוצאה הוא אדיר. שחקן טירון יכול להפתיע במכה משמעותית – אבל שחקן מיומן יגיע למכות טובות בתדירות גבוהה הרבה יותר, ובצורה הרבה יותר עקבית.
כמה כללים פשוטים (איך לאחוז במחבט, באיזו זווית לתת את המכה ״כוון כאילו אתה נותן מכה לפנים של היריב״) – יכולים להקפיץ משמעותית את הביצועים של שחקן לא מיומן.
כך גם בדזיין , ניסיתי לספק במצגת כמה טיפים בסיסיים שיכולים ״להקפיץ״ את הביצועים דיי מהר. מכאן והלאה – כמובן שיש הרבה עניין של מיונות, שתמיד אפשר לשכלל ולשפר.
כמה נקודות במצגת ששוות להתייחסות נוספת
למה אפשר לצפות מדזיין טוב?
שחקן טניס-שולחן טוב ישלוט בכדור וכמעט לא ״יאבד״ כדורים נוחים. הוא יעבור למתקפה כאשר הוא בעמדה נוחה, ויגיש ליריב כדורים שקשה להתמודד איתם (״הנחתות״).
איך נראה דזיין טוב?
הנה שלושת הכללים. מי שמיומן בתהליך הדזיין צפוי לספק דזיין שיעמוד ב 3 התכונות הנ״ל. כמובן שסעיף 1 ״פריצות דרך״ לא תמיד מתקיים, אך ככל שהמיומנות גבוהה יותר – כך מצליחים לספק פריצות דרך בצורה יותר תדירה ויותר עקבית.
יש תהליכי דזיין שלא יספקו אף אחת מהתמורות הנ״ל – וזה אומר שהם נעשו במיומנות נמוכה, ויש הרבה מה לשפר.
יש תהליכי דזיין שיספקו תמורה אחת מהנ״ל – הם באמת תורמים משהו, ואולי חשוב – אך גם אותם כדאי לשפר ולשאוף ליותר.
דזיין הוא תהליך – ולא מסמך
קל לפעמים לטעות ולעשות הקשר קשיח ״דזיין === מסמך״. זו כמובן שגיאה.
כפי שאייזנהאואר נהג להסביר שתכנון תוכנית הקרב חשוב הרבה יותר מתוכנית הקרב עצמה – כך תהליך הדזיין הוא החשוב יותר מהמסמך.
כל איש צבא יודע, שמהלך הקרב מתחיל לסטות מתוכנית הקרב – ברגע שנורה הקליע הראשון (ולפעמים גם מוקדם יותר). הערך הגדול בתוכנית הוא הבנייה של עקרונות, יעדים, ניתוח סיכונים-ותגובות, וחלוקת אחריות בין הכוחות – שרובם ימשיכו להיות רלוונטיים גם לאחר ששדה הקרב התפתח ונראה שונה מכל תסריט שהוצג בתוכנית.
באופן דומה, חשוב תהליך הדזיין – לערב אנשים רלוונטיים: גם לקבל מהם פידבק אבל גם בכדי לשתף אותם. לסנכרן את הצוות שיעבוד על הדזיין בכוונות – כך שיהיה קל ופשוט יותר לתקשר שינויים ולהבין את ההשלכות שלהם. להיות מודעים להחלטות המפתח שנותחו, כך שגם אם נכנס משתנה חדש ומשמעותי למשוואה – נוכל לעדכן את התוכניות מתוך הכרה עמוקה על מה זה עשוי להשפיע.
יש כאלו שמעודדים עדכון של מסמך הדזיין (״תוכנית הקרב״) תוך כדי המימוש – ככל שהוא סוטה מהתוכנית המקורית. אני לא חסיד של הפרקטיקה הזו – אולי רק את נקודות המפתח, ובפרויקטים בהם מעורבים הרבה אנשים.
מקווה שתמצאו פוסט זה שימוש!
אהבתי את השקף האחרון 🙂
😀
תודה.
אבל מרגיש קצת באוויר.. לא מתחבר לי לתכלס.. אולי דוגמאות יעזרו?
בעיקר שקף 10 שנראה חשוב אבל לא ברור: מה הכוונה לפריצת דרך בסעיף 1?
בסעיף 2 הכוונה לגמישות?
בנוסף היה אולי עוזר אם גם היו תשובות לשאלות בשקפים 13 – 16 …
היי יאיר,
אנסה להסביר…
״פריצת דרך״ היא תובנה עמוקה איך לעשות דברים טוב יותר. למשל: דרך פשוטה יותר או הרמונית יותר לממש פיצ׳ר. אולי דרך שלא תגרום לבעיה כלשהי שלא שמנו לב אליה.
אני קורא לזה ״פריצות דרך״ כי אלו דברים משמעותיים, ולרוב לא עולים בנקל. לרוב דרוש *תהליך* של דיון / ״חפירה״ – עד שאותם רעיונות טובים יותר צצים.
אם השקענו כמה שעות למצוא כזה רעיון – והוא חוסך סיבוכיות משמעותית במערכת שתעלה לנו בשבועות של תחזוקה עתידית (לא מקרה נדיר) – זו הצלחה גדולה.
כל דוגמה כזו תהיה יחסית למערכת ספציפית – ולכן אין לי דוגמה ״קלאסית״. אנסה משהו: בשפת javaScript הגדירו את המשתנים כ var ב scope דיי מבלבל (פונקציה) + מנגנון hoisting כפיצוי (שגם הוא דיי מבלבל). לו היו חושבים על ההגדרות של let מראש (כנראה לא התנהגות מסובכת יותר – רק נכונה יותר) – זו הייתה פריצת דרך משמעותית שהייתה מאוד משתלמת. תובנות כאלו מגיעים מתוך אתגור ודיון, וקל לפספס אותם ולהמשיך עם משהו שנראה על פניו טוב מספיק.
סעיף 2 אינו גמישות – אלא היכולת באמת ליצור תוכנית עבודה מה בערך הולכים לעשות. משהו שקבוצה של אנשים יכולה לתקשר מסביבו ולפעול מסביבו ביחד בצורה יעילה. לא פעם מתחילים לממש בעוד הדרך לא באמת ברורה. אולי ברורה לאדם אחד, אולי גם לו – לא.
התהליך המחשבתי של סידור הצעדים / אתגרים / שינויים שאיתם נתמודד, הכרה שלהם – וסיכום שלהם בצורה שניתן לשתף בין קבוצה של אנשים, היא משמעותית לאיכות וקלות הביצוע של המשימה. זה נשמע אולי טריוואילי, אבל יותר מדי פעמים צוותים יוצאים לדרך בלי תוכנית טובה מספיק. בלי הבנה ברורה מספיק מה יש לעשות, וממה יש להיזהר.
גמישות היא נושא חמקמק…. קל לפתח גמישות שלא משתלמת. המון waste הולך לתכנונים שמוסיפים גמישויות שלא יעשה בהן שימוש – אבל מוסיפים בהחלט מורכבות למערכת. עצה טובה בעיני היא לצמצם גמישויות עתידיות מלבד המקרים בהם: א. אנחנו משוכנעים ב 90% שיהיה בהן שימוש (ואנחנו בונים track record של הנחות שמוכיחות את עצמן) ב. המחיר לבצע את השינוי בעתיד יהיה דרמטית יותר גבוה מעלות השינוי כיום. בקיצור: הרבה אנשים ניגשים לדזיין בניסיון לחזות את העתיד ולבנות מערכת ש״תתאים בול״ לעתיד – וזה אחד המקומות שנופלים בהם הכי הרבה.
לגבי שקפים 13-16 חשבתי שהעניין דיי ברור. אולי הוא לא.
כל אחד התיאורי הדזיין עונים על צורך משמעותי אחד משקף 10 – אז יש בהם ערך. הם לא מיותרים או רעים – אבל בהחלט אפשר לחתור ליותר. אני מצפה מדזיין לספק בד״כ את שלושת הערכים (בד״כ – כי ״פריצות דרך״ לא ניתן להבטיח).
דזיין הוא מיומנות שלוקח זמן לפתח. אפשר לעשות דזיינים ״שתורמים משהו, אבל לא ממש טובים״ כמו התיאורים הנ״ל, ואפשר בזמן לא ארוך – אבל עם מיקוד נכון, לעשות שיפור משמעותי בדזיינים ולהפיק מהם יותר. אני מאמין שתחת הכוונה, אנשים יכולים תוך כ 5 תהליכי תכנון (שהם מקבלים עליהם פידבק) לשפר את הרמה בצורה משמעותית.
יוצא דופן יחסית ברשימה הוא התיאור בשקף 15 – שהוא מצייג את הערך החשוב ביותר: פריצת דרך. לפעמים זו נראית כמו אכזבה (״מתחילים לתכנן מחדש״) למרות שזה הישג. הרבה יותר מוצלח לתכנן מחדש, מאשר לממש מחדש או לחיות עם מימוש לקוי ולגרור אותו.
ספיציפית ניתן לטעון שכדאי לשאוף להגיע לתובנה שצריכים כיוון חדש – מוקדם ככל האפשר. את זה משיגים בעקבות גישת “Share Early״ שציינתי בשקף 18.
אני מקווה שהצלחתי לענות לעיקרי הדברים.
תודה על השאלות / הערות!
אהבתי. אני רק רוצה לנסות לחבר שתי נקודות אצלך, אולי לאחת. הטרמינולוגיה של “טוב” היא בעייתית כי אפשר להתווכח שעות מה זה טוב ורע. באחד השקפים אתה מדבר על התרומה, הקו הזה של הdesign payoff. מציע לחבר את שניהם למונח Eventually Beneficial, משהו שאולי קל יותר להסכים עליו (בהנחה שמבינים אותו) והוא לוקח בחשבון גם את מימד הזמן.
https://monksoldserver.com/2022/02/02/giving-in-eventually-beneficially/
תודה על ההערה!
מ-ע-ו-ל-ה!