הערה: אני שמח לארח את שחר בר (ברזניצקי), ארכיטקט מנוסה בתחום High Scalable Applications. שחר משתף את הנסיון שלו עם מימוש לא נכון של תבניות עיצוב. שווה קריאה!

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

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

Pattern mismatch

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

Pattern mania

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

Pattern mis-implementation

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

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

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

לסיכום

לפני שמלמדים patterns כדי לשנן את עקרונות KISS ו-YAGNI

שירותי MCS רלוונטיים

חומר רלוונטי