בחרו את הכלי הנכון לדיאגרמה שלכן

זמן קריאה: 9 דקות

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

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

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

עד לפני כמה חודשים הכלי היחיד שהייתי משתמשת בו כדי ליצור דיאגרמות לדיזיין היה Draw.io והשנה התחלתי להשתמש גם ב- Excalidraw. העבודה עם Excalidraw ענתה על מספר דרישות שהיו לי ש-draw.io מעולם לא ענתה עליהם, ולכן היא השתלבה באופן מושלם בתהליך העבודה שלי.

אתן מכירות את https://t.co/jlmpqL5THL?
זה אתר שנחשפתי אליו רק לפני שבוע, ומאז אני מרגישה שאני רואה אותו בכל מקום.
מדובר בתוכנת ציור דיאגרמות סופר פשוטה, כמעט בלי פיצ'רים, אבל היא קלה לשימוש ומדמה כתיבה על הלוח, אז היא מצוינת להרצאות וראיונות.
אני מפיצה את הבשורה! 🙂

— Maya Gershovitz Bar 👩🏻‍💻 (@mayaGBar) April 28, 2021

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

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

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

איך כל אחת מהדיאגרמות לפיצ’ר הזה תיראה?

Overview

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

1. הצגה למתכנתות אחרות תוך כדי תהליך עבודה על הפיצ’ר למטרות התייעצות. 
2. הצגה לכל ה”צרכנים” של הפיצ’ר בתוך החברה – ראשי צוותים, פרודקט, CS, צוותים אחרים, וכו’. כל מי שצריך להכיר את הפיצ’ר ולדעת איך הוא עובד בלי להיכנס לכל הפרטים הקטנים.
3. הצגה לעובדים חדשים בחברה שצריכים לקבל היכרות שטחית עם רכיבים רבים במוצר, אבל לאו דווקא צריכים להכיר את כולם לעומק.
4. בראיונות עבודה כשנתבקש להציג פיצ’ר שעבדנו עליו.

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

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

הקומפוננטות העיקריות שלי תהיינה –

1. הקליינט של היוזר 
2. שרת שיתקשר עם היוזר
3. דאטה בייס שבו המידע של היוזר יישמר 
4. סרוויס שיריץ ג’ובים של הזמנות לפי הלו”ז של היוזר
5. סרוויס שיבדוק האם מנה צריכה להישלח ליוזר, ויבחר מסעדה 
6. סרוויס שישלח את ההזמנה לתן ביס ויודיע ליוזר שההזמנה בדרך אליו.

המידע שלי יזרום בכמה כיוונים – 

1. המידע מהיוזר יזרום מהקליינט לשרת היוזרים ומשם לדאטה בייס
2. המידע מהסרוויס שמריץ ג’ובים יזרום לסרוויס שמחליט אם להוציא הזמנה ומשם לסרוויס שמוציא הזמנה ומשם לשרת היוזרים

רכיבים נוספים –

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

יאללה, בואו נצייר את הדיאגרמה –

יו, איזה כיפי ומהיר זה היה!

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

---

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

Deepdive

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

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

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

1. במהלך Design review
2. כשהכנסתי מתכנתות נוספות לפרויקט
3. כשהכנתי מסמכי תיעוד לפיצ’ר 

כשאנחנו עושות דיאגרמת Deepdive לפיצ’ר אנחנו רוצות לצלול כמה שיותר לפרטים הקטנים.

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

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

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

מה ייכלל ב-deepdive? כמה שיותר –

1. שמות ספציפיים – טבלאות, תורים, פקודות api…
   אנחנו רוצות שהדיאגרמה שלנו תספק הרבה מידע ספציפי מבלי שהקהל יאלץ לצלול לקוד.
2. פרטים על הקומפוננטות – באיזה סוגי רכיבים אנחנו משתמשות, באיזה סרוויסים חיצוניים אנחנו משתמשות…
   גם בסעיף הזה, אנחנו רוצות לספק כמה שיותר מידע טכני ספציפי.
3. מבנה מידע – שאילתות והודעות לדוגמא, שדות ב-db, טיפוסים…
   כל הפרטים האלה חשובים מאוד כשאנחנו רוצות לדעת במה הפיצ’ר מטפל ולא מטפל, והם מציפים בעיות על פני השטח במהירות.
4. רכיבים קטנים ותתי רכיבים שלא הופיעו בשרטוט המקורי – שאילתות העשרה, פניות ל-DB, טבלאות נוספות…
   הרבה פעמים אנחנו מסתמכות על פעולות קטנות שאנחנו לא טורחות לציין ב-Overview, אבל חשוב לציין אותן ב-Deepdive כדי לעלות על בעיות פוטנציאליות, ולהימנע מתחושת “וודו”.
5. טיפול בשגיאות – הודעות ללקוח, תורים של deadletters, ניסיונות חוזרים…
   חשוב לדעת איך נטפל בשגיאות גם כדי לדעת שחשבנו על כל המקרים האפשריים, וגם כדי לבחון אם ישנם פתרונות טובים יותר.

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

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

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

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

---

למה אני משתמשת ב-Draw.io כדי לצייר דיאגרמות מהסוג הזה?
בעיקר בשביל הדיוק. Draw.io מאפשר לך ליצור דיאגרמות ענקיות, ואחרי זה לטייל בהן (כמו בלינק שהוספתי למעלה). ה-grid שלה מאפשר ליצור שרטוט מאוד מדויק שהוא שימושי לשמירה על הסדר כשמנסות לדחוס כל כך הרבה פרטים לתמונה אחת. יש לה הרבה יותר מגוון של צורות, ציורים וסמלים, כך שאתן יכולות לייצג את הרכיבים השונים באופן מדויק לגמרי.
סה”כ, Draw.io היא מצוינת. יש סיבה שהשתמשתי בה במשך הרבה שנים, ושאני מתכננת להמשיך להשתמש בה. אבל מעתה והלאה, כשאני רק רוצה לשרטט למישהו ציור מהיר של מערכת, אני אשלוף את ה-Excalidraw.

---

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