מאחורי הקלעים נעשית עבודה רבה כדי שה-LMS שלנו יהיה זמין עבורכם באופן מקוון. איחוד כל המרכיבים דורש עבודת פיתוח רבה.
הרבה דברים השתנו מאז שהחברה החלה לבנות את Easy LMS. האם תרצו לדעת יותר? פריסילה, היועצת השיווקית שלנו, ראיינה את אחד המפתחים שלנו כדי ללמוד כיצד אנו בונים את Easy LMS באמצעות ארכיטקטורת מיקרו-שירותים, מה המשמעות של זה, וכיצד זה משפיע על העבודה שלנו כצוות ועל המשתמשים הסופיים.
פריסילה: תודה שהצטרפת אליי לראיון, תומאס! הדבר הראשון שאני רוצה לדעת (ואני מאמינה שגם רוב הקוראים) הוא מהי ארכיטקטורת מיקרו-שירותים. תוכל להסביר?
תומאס: אין בעיה. ארכיטקטורת מיקרו-שירותים היא דרך לבנות קוד למספר חלקים או מאגרים. אפשר לומר שאנחנו מחלקים את הדרך שבה אנחנו בונים קוד למספר מופעים במקום לבנות בלוק קוד אחד גדול.
פריסילה: מעניין. אז זה אומר שצוות הפיתוח בונה קטעי קוד עצמאיים שמתאימים לשאר התוכנה, נכון? אבל זה לא תמיד היה כך ב-Easy LMS. מדוע צוות הפיתוח ראה צורך לשנות את אופן בניית הקוד? מה הוביל לכך? האם זו הייתה מגמה חדשה או משהו כזה?
תומאס: כן, זו מגמה, אבל זו לא הייתה הסיבה העיקרית. תמיד ידענו על ארכיטקטורת מיקרו-שירותים. אבל בהתחלה, בנינו את Easy LMS כקובצי קוד גדולים, או מה שמכונה "מונוליט". כשהחברה התחילה לצמוח, היה לנו הרבה יותר תנועה באתר, מה שיצר הרבה בעיות, כמו דפים שלא הגיבו ובאגים. הבנו שאנחנו צריכים לשנות את הדרך שבה אנחנו בונים את הקוד, כדי שהאתר יוכל להתאים את עצמו ולהתרחב באופן אוטומטי.
זה כמו שיש "מפעל גדול" שמתקשה להתמודד עם עומס עבודה רב. הבנו שצריך לבנות "מפעלים קטנים" שיטפלו בחלקים אחרים של העבודה
גילינו שחלקים מסוימים בקוד לא היו מעשיים, ושהיה אפשר לשפר אותם. אז חשבנו שיהיה קל יותר לבצע את השיפורים בחלקים קטנים יותר, במקום לקחת על עצמנו פרויקט ענק. זה כמו "מפעל גדול" שמתקשה להתמודד עם כמות גדולה של עבודה. הבנו שצריך לבנות "מפעלים קטנים" שיטפלו בחלקים אחרים של העבודה.
פריסילה: תוכל לתת דוגמה למשהו שבנינו בארכיטקטורת מיקרו-שירותים?
תומאס: דוגמה עדכנית לשירות מיקרו שיישמנו היא הפונקציה החדשה לייצוא נתוני הבחינות ונתוני המשתתפים. פיתחנו אותה בשני המחזורים האחרונים. הייצוא הישן פעל ב"מפעל הגדול" הישן שלנו יחד עם דברים רבים אחרים ולא היה מותאם.
יכולנו ליצור "מפעל זעיר" שהתמחה בייצור מוצרים חדשים לייצוא. עם הייצוא נתקלנו בהרבה בעיות. לדוגמה, כאשר ללקוחות היה יותר מדי נתונים לייצוא, הבקשות שלהם העמיסו על המערכת הראשית. כעת, כשיש לנו שירות נפרד לייצוא, הכל פועל בצורה חלקה. למעשה, בנינו קוד לייצוא וקוד נוסף כדי להודיע למנהלים שהייצוא שלהם מוכן. אלה יחידות עצמאיות, לא חלקים גדולים.
פריסילה: מגניב! האם יש חלקים נוספים ב-Easy LMS שבנינו עם ארכיטקטורת מיקרו-שירותים?
תומאס: כן, יש. אחד המעניינים ביותר הוא העיצוב החדש של האקדמיה. בנינו את האקדמיה החדשה באמצעות React, שהיא מסגרת לבניית ממשקים. בנינו אותה מהארכיטקטורה הישנה (המונוליטית), לקחנו חלקים ממנה ויצרנו חלק עצמאי. בנוסף, בנינו ממשק תכנות יישומים (API) לאחזור נתונים להצגה בממשק. כעת יש לנו שני חלקים עצמאיים: אחזור נתונים והצגת הנתונים. הם קטנים יותר וקלים יותר לתחזוקה.
פריסילה: אוקיי, לפי מה שאמרת לי, עדיין יש לנו קוד ישן. האם זה בעיה שיש לנו עכשיו שני סוגי קוד במערכת ?? האם יש תוכניות לעדכן אותו?
תומאס: לא, זה לא בעיה. זה תהליך. בנינו את החלקים הראשונים של המערכת בשיטת "גושים גדולים של קוד". יש תוכניות להחליף אותם. אבל הלקוחות לא יכולים להבחין בהבדל. אנחנו בונים את הקוד החדש כך שיעבוד בצורה חלקה עם הקוד הישן.
פריסילה: הבנתי. אז בתור מפתחת, מה את מעדיפה? האם קל יותר או מסובך יותר לבנות קוד עם ארכיטקטורת מיקרו-שירותים בהשוואה לתהליך הקודם?
תומאס: כן, הרבה יותר קל לחשוב בקטעים קטנים ולתחזק את הקוד החדש. אנחנו שוקלים לעדכן את ממשק המשתתפים בעתיד, כדי שיעבוד טוב יותר בשילוב עם האקדמיה ועם עצמו. אם נבנה אותו עם ארכיטקטורת מיקרו-שירותים, יהיה הרבה יותר קל להוסיף תכונות כי נוכל לעבוד על כל חלק בנפרד.
פריסילה: אז, איך העבודה עם מיקרו-שירותים שינתה את אופן העבודה שלך?
תומאס: אנחנו יכולים לפתח מהר יותר וטוב יותר. מיקרו-שירותים עוזרים לנו לתחזק את האתר ומאפשרים לנו להשיק דברים מהר יותר.
אנו יכולים גם להחליט על הדרך הטובה ביותר לבצע משימה, מכיוון שכל קטע קוד הוא יחידה עצמאית. משמעות הדבר היא שאנו יכולים לקבוע איזו שפת תכנות נרצה להשתמש ובאיזה סוג שירות נרצה להשתמש.
כאשר השתמשנו במערכת הישנה, אם רצינו לעדכן גרסה בשפה מסוימת, היינו צריכים להמשיך לבנות את הקוד באותה שפה. כעת אנו יכולים לבחור בין שפות שונות בהתאם למה שנראה לנו המתאים ביותר לתכונה הספציפית. אנו עובדים בצוותים. כאשר אנו מתחילים מיקרו-שירות חדש, אנו בוחנים את האפשרויות העומדות בפנינו, ואז מחליטים מה מתאים לנו ביותר. זה מעניק לנו יותר אפשרויות.
פריסילה: האם זה משפיע על נגיעה בחלקים לא רצויים של המערכת, כמו למשל כשמנסים לפתור בעיה ובסופו של דבר יוצרים בעיה אחרת (כגון באג)?
תומאס: כן, אפילו לפני שנה, כשניסינו לפתור בעיות שדרשו הרבה קוד, בסופו של דבר עבדנו על יותר מדי דברים מיותרים. לדוגמה, אם רצינו לפתור את X, פתרנו את Y ואז יצרנו את הבאג Z. העבודה עם מיקרו-שירותים צמצמה את הבעיה הזו.
פריסילה: בסדר. אני מבינה שארכיטקטורת מיקרו-שירותים מקלה על צוות הפיתוח את העבודה. אבל איך זה משפיע על הלקוחות שלנו ועל המשתתפים שלהם?
תומאס: ובכן, כפי שאמרתי, הלקוחות לא מבחינים (ולא צריכים להבחין) בחלקים שונים של הקוד. הכל צריך לעבוד יחד כדי ליצור חוויה חלקה. הלקוחות יכולים להרוויח מכך, כי עכשיו אנחנו יכולים לשחרר תכונות חדשות מהר יותר ולשפר אותן על סמך המשוב שלהם.
זהו שינוי דרסטי מהדרך שבה עשינו דברים בעבר. לדוגמה, כאשר שחררנו את לוח המחוונים החדש למנהלי בחינות, נדרשו לנו כשישה חודשי פיתוח עד ששחררנו את הכל בבת אחת. אם הלקוחות אהבו את זה או שנאו את זה, לא הייתה דרך חזרה (למזלנו, הם אהבו את זה ?). כעת, שינינו את הדרך שבה אנו יוצרים ומשחררים תכונות חדשות.
לדוגמה, בונה הקורסים החדש שוחרר לראשונה כגרסת בטא. בנינו אותו באמצעות React ושחררנו אותו בהדרגה, הוספנו תכונות חדשות קטנות עד שהוא הכיל את כל הפונקציונליות הדרושה כדי להחליף את בונה הקורסים הישן במלואו. בינתיים, יכולנו לראות מה עובד, איך הלקוחות משתמשים בו, לשפר אותו, לחזור עליו ולבצע שינויים. זה לא היה אפשרי עם שחרור של כמויות גדולות של קוד בבת אחת.
פריסילה: זה מאוד הגיוני. ממה שאני זוכרת, זה תואם את עקרונות שיטת השיפור של טויוטה שאנו מיישמים בחברה. עדיף ליצור אב טיפוס, לקבל משוב ולשפר את התכונה במקום להשקיע זמן רב מבלי לדעת איך הלקוחות יקבלו אותה. תודה שהצטרפת אליי לראיון!
תומאס: כן, אני חושב שזה עובד טוב יותר. אני מקווה שהצלחתי לשפוך קצת אור על אופן העבודה של צוות הפיתוח שלנו ב-Easy LMS! בשמחה.
