לתקן, או אולי להחליף?

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

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

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

 

 

לסיכום ההרצאה, אלו חמשת המבחנים שכדאי להעביר את המערכת:

הבאגים הנעלמים

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

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

מעורבות

האם כמעט כל באג או פיצ'ר חדש דורשים מעורבות של יותר ממפתח/צוות אחד?

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

אפקט הפרפר

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

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

Root Cause

האם באגים רבים, מסוגים שונים וממודולים שונים, נובעים מאותה סיבה ראשונית (טכנולוגית או אנושית)?

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

"תפירה"

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

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

 

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

להתראות!