נא לחלק לשתיים לפחות (גם אם לא חייבים)

יש רגעים כאלה שנדלקת המנורה מעל הראש ואתה אומר לעצמך ״איך לא חשבתי על זה קודם?״ בשבוע שעבר היה לי אחד כזה…

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

  • הפיצ׳ר בלי התייחסות לדהל״פ : בתור לקוח אני רוצה לקבל חיווי על אירועים שקורים במערכת.
  • הפיצ’ר עם דהל״פ : בתור לקוח אני רוצה לקבל חיווי על X אירועים שקורים במערכת ב-T זמן (לדוגמא בשניה).

מדוע זה עובד?

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

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

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

* מקור התמונה: http://www.flickr.com/photos/carbonnyc/6415460111/

One Response to “נא לחלק לשתיים לפחות (גם אם לא חייבים)”

  1. Dalia Pongratz says:

    רעיון מעניין ומבטיח. מומלץ להוסיף לרעיון זה: להסתכל על ביצועים נדרשים ברמה הכי כללית (top level) ממש בהתחלת התכן (design). כי אם נדרשים ביצועים חזקים, חשוב לתת את הדעת על טכנולוגיה מתאימה ואולי design patterns , כדי למנוע מצב שבו כשהדרישות לביצועים סוף סוף מוגדרות, מתברר שכל מה שעשינו עד כה לא יכול לתמוך בהן.
    דוגמא מהחיים: אם עלינו לטפל בהרבה מאד הודעות או packets שמגיעות בקצב גבוה, אולי לא כדאי לבחור ב- design pattern שייצור thread עבור כל סוג הודעה – מה שעלול לגרום להתפוצצות של threads, מעבר ליכולת של מערכת ההפעלה.