בנייה דיאלוגית של אפליקציה

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

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

סדר

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

בלאגן

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

סדר

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

יותר מדי סדר

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

קליף- האנגר

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

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

מקום טוב באמצע

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

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

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

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

דיאלוג

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

כללי אצבע

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

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

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

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

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

סיכום

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