תובנות מיום העיון Zen of Architecture עם Juval Lowy

8 באפריל 2013

אין תגובות

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

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

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

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

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

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

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

Methode

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

מי שמעוניין ללמוד יותר על תכנון ארכיטקטוני בטכניקה הזו, מוזמן לגשת לעמוד הבית של Idesign .NET ולהוריד משם את החומר על ה IDesign Method (נמצא בצד ימין, הראשון באגף ה Resources).

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *