לכתוב מסקראץ'

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

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

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

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

 

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

מבחינה טכנולוגית

• מעל השלד של הארכיטקטורה הישנה רצים פיצ'רים רבים, מורכבים יותר ומורכבים פחות. יחלוף זמן רב עד שכל הפיצ'רים ישוכתבו למערכת החדשה.
• המערכת הישנה עברה כבר סבבים רבים של ייצוב בסביבת לקוח. למערכת חדשה תהיה תקופת הסתגלות לא קצרה.
• במרבית המערכות, יש צורך להעביר את כל המידע מהמערכת הישנה לחדשה, וכאשר הארכיטקטורה שונה מאוד, זה לגמרי לא טריוויאלי (נסו לחשוב, למשל, על מעבר ממערכת מבוססת טבלאות ו-joins למערכת מבוססת documents).
• יש צורך לשמר את הקונפיגורציה של כל מערכת באתר לקוח ולדאוג שהיא תשמור על תאימות לאחור של ההתנהגות המקומית (מה יקרה, למשל, אם נעבור מגישה של push לגישה של polling?)

מבחינה ארגונית

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

מבחינה עסקית

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

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

 

 

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