על Effective Software Design (או ESD)

תקשיבו: הנה נושא חשוב שמעולם לא כיסיתי בבלוג.

לא התעלמתי לגמרי. כתבתי מסביבו:

• האם אנו זקוקים ל Software Design? (+ כמה תגובות)
• מדוע אנו זקוקים ל Software Design?

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


מהו תהליך ה"דזיין" (כלומר: Software Design) הזה? תהליך שכל מפתח משתתף בו מספר פעמים בשנה?


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

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

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

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

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

זה ממש מוזר - כי זה תהליך כ"כ נפוץ וכ"כ מקובל. על איזה בסיס אתם עשיתם דזיין? כיצד לימדו אתכם?

ומכיוון שקיים צורך, היכן היועצים? הקורסים? הספרים? האם אני פשוט מפספס את כולם?

אז איך עושים דזיין - בצורה לא יעילה?

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

דזיין = הצגת הפתרון

ישיבות דזיין רבות סובבות סביב התיאור של מה שהולכים לעשות: בעיה --> פתרון.
הקהל מודרך בתוך סיפור שאין לו רקע משמעותי לגביו. כמובן גם שאין לו מושג על ההתלבטויות שהיו - אך לא הגיעו לידי מימוש.

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

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

אם מטרת הדיזיין היא לשמוע "הממ... כן.. זה נשמע הגיוני.." - אז זה הפורמט הנכון עבורכם!

דזיין = "חפירה" בסכמת בסיס הנתונים

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

המודל הקונספטואלי מרכיב בתוכו הנחות משמעותיות על דומיין הבעיה והפתרון שלה --> שזה מצוין!

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

שתי הבעיות הן:

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

תוכנות wireframe, כמו axure, מכילות סט כלים על מנת לייצר low-fidelity wireframes בהם יש פרטים חסרים / לא שלמים / קווים לא ישרים המחצינים את חוסר הבשלות / שלמות של ה wireframe.
כאשר מציגים למשתמשים wireframe מלוטש ומהוקצע - הפידבקים נוטים להיות על הליטוש: צבעים, מיקום של כפתורים, וטקסטים.
כאשר מציגים למשתמשים low-fidelity wireframe - הפידבקים על המהות, ה flow, והתוכן המוצג - תופסים חלק משמעותי יותר.

דזיין = 90 דקות של מסירות - ואז שריקת סיום

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

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

סיכום ביניים

לא משנה אם עשינו את אחת הטעויות לעיל, או טעות אחרת. התוצאה היא לרוב זהה:

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

כל שעת ישיבה של 8 אנשים - היא יום עבודה.

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

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

אז איך עושים דזיין - בצורה יעילה?

להלן עיקרי הדברים. אציג אותם בתור סוג של "template" למסמך דזיין יעיל.

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

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

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

הזדמנות נוספת: קיצוץ אפשרי בפעולות מיותרות. "למה לכתוב קוד multi-threaded? בביזנס אין יותר מ 10-20 בקשות כאלו בדקה!" 

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

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

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

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

הקשר (context)

חשוב מאוד להבין היכן הקוד / מודול / שירות המדובר נמצא ברחבי המערכת הקיימת:

• מי פונה אליו?
• למי הוא פונה?
• באיזה flows גדולים של המערכת הוא מעורב.

זה נשמע טריוויאלי - אבל זה הרבה פעמים זה מידע שחסר, ואף אחד לא מעז לשאול.

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

הוא כמעט תמיד שווה את ההשקעה.

על התרשים שווה להסביר את ה flows החשובים. אחד או כמה. זה יכול להיות בטקסט או בדיאגרמה.

אני אישית מאוד אוהב UML 1.x Collaboration Diagrams.
בגלל שאני רגיל לשרטט אותם - אני גם עושה זאת במהירות.

לפעמים ה flow החשוב - הוא בתוך המודול (או שירות) שלנו.

לפעמים ה flow החשוב - הוא בין המודול שלנו לאחרים.

מה שחשוב הוא לא להציג תרשים בפורמט כזה או אחר.

מה שחשוב הוא "לשים על השולחן" את ה 1 עד 3 flows החשובים ביותר ולראות שהם:

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

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

זה השלב לעצור.

Stop!

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

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

הנטייה האנושית היא לקבע, להתרגל, ולהסתגל לאותה דרך א' - כי "היא פותרת דברים" או "זה עובד!".

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

החלטה גדולה מספר 1: מה הייתה הבעיה / דילמה? 

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

הנה דוגמה לאופן לתאר החלטה גדולה של דזיין:

------

החלטה גדולה מספר 1: איך השירות שלי מקבל נתונים שלהם הוא זקוק?

אופציה א': שירות אחר יעדכן אותנו בכל שינוי דרך RabbitMQ

• יתרונות: פשוט... יעיל ....
• חסרונות: הרבה הודעות ....

אופציה ב': השירות שלנו יקרא לשירות השני בכל פעם וישלוף את הנתונים.

• יתרונות: פחות הודעות ברשת. הנתונים יותר up-to-date
• חסרונות: התלות "מרגישה" לא נכונה.

בגלל xyz בחרנו באופציה א'.

------- 

תיאור שכזה הוא בסיס לסיעור מוחות איכותי.

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

חלק גדול מפריצות הדרך בסיעורי מוחות שכאלו קורים כאשר המשתתפים מסכימים עם ההחלטה - אבל לא עם ההנחות!

מישהו אומר: אבל לא לקחתם בחשבון את חסרון x באופציה א'. זו בעיה ממשית כי....

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

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

אני ממליץ להתעקש על דיון ב 2-3 "החלטות גדולות" עבור בדזיינים משמעותיים.

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

המודל

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

הדיון במודל יהיה יעיל יותר כאשר:

• נשמיט שדות לא חשובים. created_at ו updated_at אולי הם שדות רצויים - אבל יש סיכוי טוב שהם לא באמת חשובים לדיון. כלל זה גם טוב אם המודל מאוחסן ברדיס, או MongoDB - למשל.
• נשמיט טיפוסים של בסיס הנתונים, כדי להימנע מדיונים משניים. 
• הדיון על varchar vs. char vs. text ב postgreSQL הוא מעניין - אבל לא מצדיק את ההשקעה ברוב המוחלט של הפיצ'רים.גם אם מדובר בדיון 1 על 1 - הרשו לעצמכם לדלג על הדיון הזה.
• נתאר את השימושים העיקריים של ה data, אם מדובר בכמויות / קצבים משמעותיים. 
• דיון קצר על אינדקסים ומבנה הסכמה, לאור השימוש המצופה - כן יכול להיות דיון משמעותי ששווה את הזמן.
• כמו כן: העובדה שיש לנו מיליון אובייקטים / רשומות שנוספים כל יום - הוא מידע שעלול לערער הנחה ו/או חלק אחר בדזיין של המערכת. דיון על כמויות שימוש במודל עשויות להעלות נקודות שלא היינו חושבים עליהן אחרת.

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

צ'ק ליסט

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

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

-----------

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

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

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

כמה עצות כלליות:

זדיין הוא לא נוסחה מתמטית

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

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

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

הלו? - שנות התשעים עברו

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

רדו מזה! חשבו על פשטות, על תחזוקה, על הרמוניה עם המערכת הקיימת, על עקרונות SOLID או GRASP.

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

דזיין הוא תהליך של קונצנזוס

שזה אומר כן... תהליך חברתי. לא הדבר שהכי טבעי לכל אנשי התוכנה על כדור הארץ.

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

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

אם אתם משקיעים שעות בדיון האם להעביר את שדה ה data ב json ברמה העליונה או רמה משנית - אז .... באמת חבל.

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

הדזיין לעולם לא נגמר

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

יש נוסחה שאומרת שההתיישנות של מסמך הדזיין = המרחק הפיסי שלו מהקוד x אורך המסמך.

ולכן, מסמך דזיין שמופיע כשני עמודים של readme.md בתוך ה git repository - הוא זה שהסיכוי שלו להישאר רלוונטי הוא הכי גדול.

הרבה יותר חשוב מהדזיין, או מישיבת ה Review (אם יש כזו) - הוא הידע, ההבנות, והחשיבה שנעשו. התהליך שעברנו בזמן העבודה על הדזיין.

"חשיבת דזיין" תמשיך להיות בשימוש תוך כדי כתיבת הקוד, תוך כדי Refactoring בקוד, או תוך כדי דזיין / עבודה על הפיצ'ר הבא באותו האזור של המערכת.

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

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