בחלקים הקודמים (חלק א', חלק ב'), עמדנו על האתגרים מההיבטים הפיזיים והחומרתיים, והדרכים להתמודד עימם. בחלק זה נעמוד על האתגרים מההיבט התוכנתי ונסביר כיצד להתמודד עימם - נעבור על נקודות הכשל כגון: קוד המקור איננו גמיש לשינויים, חוסר יציבות ואיטיות של התוכנה, קוד המקור אשר לא נכתב בצורה מאובטחת, ריבוי רכיבים במערכת עם תלות הדדית בניהם, קושי באיתור ותיקון תקלות ועוד.
ברגע שהמערכת שלנו צריכה להתמודד עם גידול במספר משתמשים ויכולת לעמוד בגידול של כמות המידע שהיא צריכה לעבד ולספק - עומדים לפנינו מספר אתגרים כשמסתכלים על ההיבט התוכנתי.
האתגרים מההיבט התוכנתי:
התאמה של קוד המקור לעבוד במשאבי חומרה מוגבלים
במידה והמערכת נדרשת לעבוד על חומרה מוגבלת, אזי התוכנה שלנו צריכה להיות עם אופטימיזציה מאוד גבוהה, דבר הדורש שקוד המקור יהיה ברמה מקצועית גם הוא, תוך שימוש באלגוריתמים יעילים וחסכוניים, מה שדורש כמובן, עלות גבוהה לפיתוח של מערכת כזאת.
עדכון דרישות מערכת התוכנה
כאשר המערכת נדרשת לעבוד בצורה שונה ולתמוך ביכולות חדשות, יש צורך לעדכן את דרישות המערכת המקורית, ולבצע ניתוח חדש של המערכת וצרכי הלקוח ומשתמשי המערכת, תהליך זה יכול להימשך בין כמה ימים למספר שבועות.
עדכון תכנון מערכת התוכנה
לעיתים לאחר שינוי דרישות המערכת, יהיה צורך בתכנון מחדש של המערכת בכדי לתמוך בגדילת משתמשים ומידע, דבר הדורש אנשים מנוסים בתחום. לכן, תכנון נכון יכול להקטין בצורה משמעותית את זמני מימוש המערכת עד לבשלות לעלייה לאוויר. שלב זה יכול לקחת בין מספר שבועות (במידה ונדרש שינוי תכנון במספר קטן של מודלים), אך במידה וכל המערכת אינה מודולרית, תכנון כזה יכול להמשך חודשים.
מימוש המערכת
שלב זה יכול להיות בתהליך פיתוח במודול מפל המים שבו יש צורך לחכות לסיום תכנון מלא של המערכת, או בתהליך פיתוח זמיש (זריז וגמיש – AGILE) שבו אנו נתחיל את שלב המימוש באיטרציות קטנות ואינקרמנטלי. ברגע שיש לנו תכנון מערכת של תת מערכת, אנו יכולים להתחיל במימוש תת המערכת מבלי לחכות לסיום מלא של תכנון המערכת. לכן, שלב מימוש המערכת יהווה תקופה של מספר שבועות/חודשים, תלוי בתהליך הפיתוח.
עמידה בתקני אבטחת מערכת התוכנה
כאשר אנו משנים את תכנון המערכת ובייחוד את קוד המקור או עושים שימוש בספריות צד שלישי, אנו עלולים להגדיל את שטח ההתקפה של המערכת שלנו. תכנון לא מקצועי עלול לחשוף חולשות חדשות שלא היו קודם במערכת, ומכיוון שתחום אבטחת מערכות תוכנה הוא תחום מורכב מאוד הדורש מומחיות רבה, נושא זה יכול לדרוש משאבים יקרים לצרכי היוועצות באנשי מקצוע, תוכנות אבטחה, עדכון מבדקי חדירה ועוד, ודברים אלו עלולים להמשך מספר שבועות - חודשים.
הכנסה של טכנולוגיות חדשות למערכת התוכנה
במידה ועולה צורך שיש להכניס שימוש בטכנולוגיה חדשה שאנשי הפיתוח ומערכות המידע שלנו לא שולטים בה, אזי מדובר באתגר הדורש מוביל טכנולוגי מומחה שיוכל לחקור את הטכנולוגיה החדשה ולבדוק עד כמה היא בשלה ומאובטחת לשימוש במערכת החדשה.
מעבר לחומרה שונה
במידה ועולה צורך לשינוי החומרה, אזי אנו נצטרך לבדוק האם המערכת שלנו תוכל לרוץ בצורה תקינה על החומרה החדשה - האם היא יכולה לרוץ או צריכה לעבור שינוי קוד? תהליך בדיקת היתכנות כזה יכול להיות קל לביצוע במידה ויש לנו אוסף של בדיקות תוכנה המכסה את כל המודלים ואת רוב התרחישים. במידה ואין לנו מערכת בדיקות מקיפה, אנו עלולים לגלות בעיות רק בשלב העלייה לאוויר, ומדובר בדבר מסוכן מאוד.
נקודות כשל קריטיות
קוד המקור איננו גמיש לשינוים - הסיבות לכך מגוונות: עקב איכות תוכנה ירודה, תוכנה שאינה קריאה, ללא בדיקות אוטומטיות, אינה מעודכנת, קשה לתחזוקה ולשינויים, אין מסמכים מעודכנים (לא חייב מפורטים אבל חשוב שיהיו מעודכנים ותואמים לקוד) המתארים מהן דרישות המערכת.
חוסר יציבות ואיטיות של התוכנה
גידול של כמות המידע במסד הנתונים גורמת עלולה לגרום לאיטיות וחוסר יציבות במידה והמערכת שלנו לא תומכת בגידול אופקית.
קוד המקור לא נכתב בצורה מאובטחת
אנו עלולים להגדיל את שטח ההתקפה של המערכת שלנו - תכנון לא מקצועי עלול לחשוף חולשות חדשות שלא היו קודם במערכת.
ריבוי רכיבים במערכת עם תלות הדדית בניהם
במידה ובמערכת שלנו ישנה תלות הדדית גבוהה בין רכיבים במערכת, יהיה מאוד מאתגר לבצע שינוי ברכיב מסוים מבלי שרכיבים אחרים יפגעו.
קושי באיתור ותיקון תקלות
כתיבה לקויה של קוד המקור ושימוש מועט במערכות ניטור בזמן אמת של הרישום (LOGGING) של הפעולות של המערכת, יגרום לקושי באיתור תקלות ויקשה על תיקונן בצורה טובה.
בכדי להתמודד עם האתגרים שהמערכת שלנו תצטרך, ולעמוד בעומסים, יש מספר דרכים. חלק מהן קלות ומהירות, וחלקן יותר מורכבות ודורשות יותר משאבים לצורך התגברות על האתגרים.
דרכי ההתמודדות עם האתגרים — פחות מורכבות:
שיפור אלגוריתם בקוד
אנו יכולים להריץ כלי פרופיילר (profiler) שיבצעו ניתוח של ניצול משאבי המעבד והזיכרון ובעזרתם נוכל לאתר שורות או שיטות (methods) בקוד שאפשר לשפר שם את האלגוריתם כך שיהיה יותר יעיל. ניקח מקרה לדוגמא: נניח יש לנו שיטה שמבצעת חישוב ויש בה שני לולאות מקוננות, אזי הסיבוכיות תהיה O(n²). באמצעות כלי הפרופיילר, נוכל לזהות את השיטה הנ”ל ולנסות לשפר את האלגוריתם בכדי שיעבוד בסיבוכיות נמוכה יותר מאשר O(n^2).
הוספת עיבוד מקבלי
אנו יכולים להאיץ את החישוב ע”י ביצוע עיבוד בו-זמנית של חלקים בקוד שהם בלתי תלויים אחד בשני, ובכך להשתמש בריבוי המעבדים שיש לשרתים בצורה יעילה יותר. יחד עם היתרון הגדול של שיפור הביצועים, ישנם אתגרים בכתיבת קוד שתומך בצורה נכונה בריבוי תהליכונים בצורה מסונכרנת כגון הרעבה, קיפאון ותחרות בין שני תהליכונים על כתיבה למשאב משותף.
שיפור השאילתות במסד הנתונים
במידה ויש לנו שליפה של נתונים ממסד נתונים (DB), אנו יכולים להפעיל ניתוח (explain plan)של אותו מסד נתונים, ולבדוק כיצד מתבצעת השליפה והאיתור הפנימי באותו מסד נתונים, וע”י כך לזהות היכן ניתן להוסיף אינדקסים לטבלאות ובכך לשפר את זמני שליפת הנתונים.
מנגנון נוסף שיכול לעזור הוא שימוש במנגנון זיכרון מטמון (Cache)
מנגנון זה מאפשר לנו לבצע פחות פעולות קריאה/כתיבה ממשק חיצוני, ובכך לשפר בצורה דרסטית את ביצועי המערכת. יש לשים לב שהכנסת מנגנון מטמון צריך להתבצע בצורה נכונה, מכיוון שאם הערך שיש לנו במטמון השתנה בעולם החיצוני ואנו נשתמש בערך שיש לנו בזיכרון המטמון העיבוד יתבצע בצורה לא עדכנית, דבר שיכול לגרום לבעיות. לכן, יש צורך להוסיף למנגנון זיכרון המטמון גם מנגנון המגביל את זמן החיים של מידע (TTL) במערכת, למערכת קריטיות העובדות בזמן אמת נצטרך להגדיר TTL נמוך מאוד, ואילו במערכת של דוחות יומיים ניתן להגדיר TTL של כמה שעות.
שימוש במודול צד שלישי (3rd party module)
במידה ויש לנו אלגוריתם הדורש עיבוד מורכב, ניתן להשתמש במערכת צד שלישי שהמערכת שלנו תוכל להכיל, ובכך נחסוך משאבים של זמן וכסף שהיו נדרשים עבור אנשים מומחים שיכתבו את המודול.
שימוש בספריית קוד פתוח
ישנן הרבה ספריות קוד פתוח במגוון שפות תוכנה, ובמגוון תחומים, אנו יכולים להמיר חלק מהמערכת לשימוש בספריית קוד פתוח, ובכך גם לשפר את איכות הקוד, וגם לתרום לקהילת הקוד הפתוח.
שימוש ב – CI/CD
ברגע שיש לנו מנגנון אינטגרציה והתקנה אוטומטי, אנו נוכל לשמור על רמת קוד גבוהה ואיתור תקלות לפני שהן מגיעות לסביבת הלקוח.
שימוש בתוכנה כשירות (SaaS)
אנו יכולים להשתמש בשירותי ענן ולהשתמש בתוכנה כשירות בכדי לעשות האצלת שימוש של קטע קוד לענן. אם לדוגמא ישנו צורך להוסיף יכולת חדשה למערכת או לשפר יכולת קיימת, אם נשתמש בתוכנה כשירות, אנו נוכל בזמן יחסית מהיר להוסיף את היכולת הזאת למוצר מבלי לגייס מומחים או לפתח תשתיות עבור התחום החדש. לדוגמא, אם אנו צריכים מנוע שממיר דיבור לטקסט, אנו יכולים להשתמש במגוון מוצרי שירות כתוכנה שקיימים אצל ספקיות הענן הציבורי ועל ידי כך נוכל לחסוך זמן יקר - והכי חשוב, נוכל לקבל במהרה משוב מהמשתמש אם היכולת החדשה מעניינת אותו, וכל זה יחסית בהשקעה של נמוכה של משאבים. בנוסף, נקבל עדכונים אוטומטיים של כל סביבת השירות מרמת החומרה, מערכת ההפעלה וכלה בעדכוני אבטחה של הספריות במערכת (ארחיב על נושא זה במאמר הבא).
תכנון מוקדם
אם נשתמש בממשקי Interfaces בזמן שאנו מבצעים קריאות לפעולות במערכת, אז ברגע שנרצה להחליף מודל מסוים לא יהיה צורך לשנות את כל המודלים שמשתמשים במודול המוחלף מפני שהממשק לא משתנה, אלא רק המימוש שלו – ולמעשה, בכך אנו מאפשרים למערכת שלנו גמישות ויכולת גידול בעלות נמוכה.
דרכי ההתמודדות עם האתגרים — דרכים מורכבות יותר לביצוע:
שינוי ארכיטקטורה של המערכת
זהו תהליך שיכול להתבצע על מודול מסוים מהמכלול של המערכת ויכול להיות צורך בשינוי ארכיטקטורה של כל המודלים במערכת. זהו תהליך שדורש איש תוכנה בכיר עם ניסיון בתכנון מערכת תוכנה. במידה ויש לנו מערכת תוכנה עם ריבוי תלויות וקטעי קוד לא יעילים ולא קריאים, שינוי בארכיטקטורת התוכנה יהיה מאוד קשה לביצוע.
שימוש בתבניות עיצוב (Design patterns)
ע”י שימוש בתבניות עיצוב, אנו יכולים להתגבר על אתגרים שיעלו כתוצאה משינוי או תוספת של קוד חדש, אם נשתמש בפתרון מוכר וידוע כגון מתאם (Adapter), מפעל אבסטרקטי (Abstract Factory), סינגלטון וכו’ נוכל להתמודד עם האתגרים בצורה טובה, תוך שמירה על איכות הקוד ועל כך שהמערכת תהיה גמישה לשינויים.
שינוי של שפת פיתוח התוכנה
מעבר לפיתוח בשפת תוכנה שונה הוא אתגר לא פשוט, מכמה היבטים, לכל שפת תוכנה שאנו מטמיעים בארגון ובמערכת התוכנה שלנו, נלווים אליה הרבה הכשרות ותשתיות שנכתבו עבור אותה שפה. במידה והמערכת שלנו כתובה ב-JAVA ואחד מהמודולים החדשים שלנו נדרש לתמוך בעיבוד זמן אמת קריטי שבו יש צורך בזמן תגובה מהיר, יתכן שנצטרך לעבור לפיתוח בשפת C/C++שפה שיותר קרובה לשפת מכונה, דבר זה כולל גיוס והכשרה של עובדים עם ניסיון רלוונטי, פיתוח תשתיות וביצוע בדיקות לקוד החדש וכמובן שיש לתהליך זה מחיר גבוה בכדי להגיע לרמת קוד ייצור.
לסיכום
הנקודות שמניתי למעלה הן הנקודות העיקריות שנותנים מענה לאתגרים של ההיבט התוכנתי. כמובן שיש עוד לא מעט נקודות ופעולות שניתן לבצע בכדי לתת מענה לאתגרים התוכניתיים שנדרשים לצורך הגדלת הביצועים והקיבולת של המערכת, ולכן במאמרים הבאים נעבור על פתרונות ומעבר לטכנולוגיות מבוזרות מבוססות ענן הנותנות מענה להרבה אתגרים.
מאת: ניר מקמל, ארכיטקט תוכנה למערכות מבוזרות מתקדמות
רוצים להתעדכן בתכנים נוספים בנושאי ענן וטכנולוגיות מתקדמות? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
בחלקים הקודמים (חלק א', חלק ב'), עמדנו על האתגרים מההיבטים הפיזיים והחומרתיים, והדרכים להתמודד עימם. בחלק זה נעמוד על האתגרים מההיבט התוכנתי ונסביר כיצד להתמודד עימם - נעבור על נקודות הכשל כגון: קוד המקור איננו גמיש לשינויים, חוסר יציבות ואיטיות של התוכנה, קוד המקור אשר לא נכתב בצורה מאובטחת, ריבוי רכיבים במערכת עם תלות הדדית בניהם, קושי באיתור ותיקון תקלות ועוד.
ברגע שהמערכת שלנו צריכה להתמודד עם גידול במספר משתמשים ויכולת לעמוד בגידול של כמות המידע שהיא צריכה לעבד ולספק - עומדים לפנינו מספר אתגרים כשמסתכלים על ההיבט התוכנתי.
האתגרים מההיבט התוכנתי:
התאמה של קוד המקור לעבוד במשאבי חומרה מוגבלים
במידה והמערכת נדרשת לעבוד על חומרה מוגבלת, אזי התוכנה שלנו צריכה להיות עם אופטימיזציה מאוד גבוהה, דבר הדורש שקוד המקור יהיה ברמה מקצועית גם הוא, תוך שימוש באלגוריתמים יעילים וחסכוניים, מה שדורש כמובן, עלות גבוהה לפיתוח של מערכת כזאת.
עדכון דרישות מערכת התוכנה
כאשר המערכת נדרשת לעבוד בצורה שונה ולתמוך ביכולות חדשות, יש צורך לעדכן את דרישות המערכת המקורית, ולבצע ניתוח חדש של המערכת וצרכי הלקוח ומשתמשי המערכת, תהליך זה יכול להימשך בין כמה ימים למספר שבועות.
עדכון תכנון מערכת התוכנה
לעיתים לאחר שינוי דרישות המערכת, יהיה צורך בתכנון מחדש של המערכת בכדי לתמוך בגדילת משתמשים ומידע, דבר הדורש אנשים מנוסים בתחום. לכן, תכנון נכון יכול להקטין בצורה משמעותית את זמני מימוש המערכת עד לבשלות לעלייה לאוויר. שלב זה יכול לקחת בין מספר שבועות (במידה ונדרש שינוי תכנון במספר קטן של מודלים), אך במידה וכל המערכת אינה מודולרית, תכנון כזה יכול להמשך חודשים.
מימוש המערכת
שלב זה יכול להיות בתהליך פיתוח במודול מפל המים שבו יש צורך לחכות לסיום תכנון מלא של המערכת, או בתהליך פיתוח זמיש (זריז וגמיש – AGILE) שבו אנו נתחיל את שלב המימוש באיטרציות קטנות ואינקרמנטלי. ברגע שיש לנו תכנון מערכת של תת מערכת, אנו יכולים להתחיל במימוש תת המערכת מבלי לחכות לסיום מלא של תכנון המערכת. לכן, שלב מימוש המערכת יהווה תקופה של מספר שבועות/חודשים, תלוי בתהליך הפיתוח.
עמידה בתקני אבטחת מערכת התוכנה
כאשר אנו משנים את תכנון המערכת ובייחוד את קוד המקור או עושים שימוש בספריות צד שלישי, אנו עלולים להגדיל את שטח ההתקפה של המערכת שלנו. תכנון לא מקצועי עלול לחשוף חולשות חדשות שלא היו קודם במערכת, ומכיוון שתחום אבטחת מערכות תוכנה הוא תחום מורכב מאוד הדורש מומחיות רבה, נושא זה יכול לדרוש משאבים יקרים לצרכי היוועצות באנשי מקצוע, תוכנות אבטחה, עדכון מבדקי חדירה ועוד, ודברים אלו עלולים להמשך מספר שבועות - חודשים.
הכנסה של טכנולוגיות חדשות למערכת התוכנה
במידה ועולה צורך שיש להכניס שימוש בטכנולוגיה חדשה שאנשי הפיתוח ומערכות המידע שלנו לא שולטים בה, אזי מדובר באתגר הדורש מוביל טכנולוגי מומחה שיוכל לחקור את הטכנולוגיה החדשה ולבדוק עד כמה היא בשלה ומאובטחת לשימוש במערכת החדשה.
מעבר לחומרה שונה
במידה ועולה צורך לשינוי החומרה, אזי אנו נצטרך לבדוק האם המערכת שלנו תוכל לרוץ בצורה תקינה על החומרה החדשה - האם היא יכולה לרוץ או צריכה לעבור שינוי קוד? תהליך בדיקת היתכנות כזה יכול להיות קל לביצוע במידה ויש לנו אוסף של בדיקות תוכנה המכסה את כל המודלים ואת רוב התרחישים. במידה ואין לנו מערכת בדיקות מקיפה, אנו עלולים לגלות בעיות רק בשלב העלייה לאוויר, ומדובר בדבר מסוכן מאוד.
נקודות כשל קריטיות
קוד המקור איננו גמיש לשינוים - הסיבות לכך מגוונות: עקב איכות תוכנה ירודה, תוכנה שאינה קריאה, ללא בדיקות אוטומטיות, אינה מעודכנת, קשה לתחזוקה ולשינויים, אין מסמכים מעודכנים (לא חייב מפורטים אבל חשוב שיהיו מעודכנים ותואמים לקוד) המתארים מהן דרישות המערכת.
חוסר יציבות ואיטיות של התוכנה
גידול של כמות המידע במסד הנתונים גורמת עלולה לגרום לאיטיות וחוסר יציבות במידה והמערכת שלנו לא תומכת בגידול אופקית.
קוד המקור לא נכתב בצורה מאובטחת
אנו עלולים להגדיל את שטח ההתקפה של המערכת שלנו - תכנון לא מקצועי עלול לחשוף חולשות חדשות שלא היו קודם במערכת.
ריבוי רכיבים במערכת עם תלות הדדית בניהם
במידה ובמערכת שלנו ישנה תלות הדדית גבוהה בין רכיבים במערכת, יהיה מאוד מאתגר לבצע שינוי ברכיב מסוים מבלי שרכיבים אחרים יפגעו.
קושי באיתור ותיקון תקלות
כתיבה לקויה של קוד המקור ושימוש מועט במערכות ניטור בזמן אמת של הרישום (LOGGING) של הפעולות של המערכת, יגרום לקושי באיתור תקלות ויקשה על תיקונן בצורה טובה.
בכדי להתמודד עם האתגרים שהמערכת שלנו תצטרך, ולעמוד בעומסים, יש מספר דרכים. חלק מהן קלות ומהירות, וחלקן יותר מורכבות ודורשות יותר משאבים לצורך התגברות על האתגרים.
דרכי ההתמודדות עם האתגרים — פחות מורכבות:
שיפור אלגוריתם בקוד
אנו יכולים להריץ כלי פרופיילר (profiler) שיבצעו ניתוח של ניצול משאבי המעבד והזיכרון ובעזרתם נוכל לאתר שורות או שיטות (methods) בקוד שאפשר לשפר שם את האלגוריתם כך שיהיה יותר יעיל. ניקח מקרה לדוגמא: נניח יש לנו שיטה שמבצעת חישוב ויש בה שני לולאות מקוננות, אזי הסיבוכיות תהיה O(n²). באמצעות כלי הפרופיילר, נוכל לזהות את השיטה הנ”ל ולנסות לשפר את האלגוריתם בכדי שיעבוד בסיבוכיות נמוכה יותר מאשר O(n^2).
הוספת עיבוד מקבלי
אנו יכולים להאיץ את החישוב ע”י ביצוע עיבוד בו-זמנית של חלקים בקוד שהם בלתי תלויים אחד בשני, ובכך להשתמש בריבוי המעבדים שיש לשרתים בצורה יעילה יותר. יחד עם היתרון הגדול של שיפור הביצועים, ישנם אתגרים בכתיבת קוד שתומך בצורה נכונה בריבוי תהליכונים בצורה מסונכרנת כגון הרעבה, קיפאון ותחרות בין שני תהליכונים על כתיבה למשאב משותף.
שיפור השאילתות במסד הנתונים
במידה ויש לנו שליפה של נתונים ממסד נתונים (DB), אנו יכולים להפעיל ניתוח (explain plan)של אותו מסד נתונים, ולבדוק כיצד מתבצעת השליפה והאיתור הפנימי באותו מסד נתונים, וע”י כך לזהות היכן ניתן להוסיף אינדקסים לטבלאות ובכך לשפר את זמני שליפת הנתונים.
מנגנון נוסף שיכול לעזור הוא שימוש במנגנון זיכרון מטמון (Cache)
מנגנון זה מאפשר לנו לבצע פחות פעולות קריאה/כתיבה ממשק חיצוני, ובכך לשפר בצורה דרסטית את ביצועי המערכת. יש לשים לב שהכנסת מנגנון מטמון צריך להתבצע בצורה נכונה, מכיוון שאם הערך שיש לנו במטמון השתנה בעולם החיצוני ואנו נשתמש בערך שיש לנו בזיכרון המטמון העיבוד יתבצע בצורה לא עדכנית, דבר שיכול לגרום לבעיות. לכן, יש צורך להוסיף למנגנון זיכרון המטמון גם מנגנון המגביל את זמן החיים של מידע (TTL) במערכת, למערכת קריטיות העובדות בזמן אמת נצטרך להגדיר TTL נמוך מאוד, ואילו במערכת של דוחות יומיים ניתן להגדיר TTL של כמה שעות.
שימוש במודול צד שלישי (3rd party module)
במידה ויש לנו אלגוריתם הדורש עיבוד מורכב, ניתן להשתמש במערכת צד שלישי שהמערכת שלנו תוכל להכיל, ובכך נחסוך משאבים של זמן וכסף שהיו נדרשים עבור אנשים מומחים שיכתבו את המודול.
שימוש בספריית קוד פתוח
ישנן הרבה ספריות קוד פתוח במגוון שפות תוכנה, ובמגוון תחומים, אנו יכולים להמיר חלק מהמערכת לשימוש בספריית קוד פתוח, ובכך גם לשפר את איכות הקוד, וגם לתרום לקהילת הקוד הפתוח.
שימוש ב – CI/CD
ברגע שיש לנו מנגנון אינטגרציה והתקנה אוטומטי, אנו נוכל לשמור על רמת קוד גבוהה ואיתור תקלות לפני שהן מגיעות לסביבת הלקוח.
שימוש בתוכנה כשירות (SaaS)
אנו יכולים להשתמש בשירותי ענן ולהשתמש בתוכנה כשירות בכדי לעשות האצלת שימוש של קטע קוד לענן. אם לדוגמא ישנו צורך להוסיף יכולת חדשה למערכת או לשפר יכולת קיימת, אם נשתמש בתוכנה כשירות, אנו נוכל בזמן יחסית מהיר להוסיף את היכולת הזאת למוצר מבלי לגייס מומחים או לפתח תשתיות עבור התחום החדש. לדוגמא, אם אנו צריכים מנוע שממיר דיבור לטקסט, אנו יכולים להשתמש במגוון מוצרי שירות כתוכנה שקיימים אצל ספקיות הענן הציבורי ועל ידי כך נוכל לחסוך זמן יקר - והכי חשוב, נוכל לקבל במהרה משוב מהמשתמש אם היכולת החדשה מעניינת אותו, וכל זה יחסית בהשקעה של נמוכה של משאבים. בנוסף, נקבל עדכונים אוטומטיים של כל סביבת השירות מרמת החומרה, מערכת ההפעלה וכלה בעדכוני אבטחה של הספריות במערכת (ארחיב על נושא זה במאמר הבא).
תכנון מוקדם
אם נשתמש בממשקי Interfaces בזמן שאנו מבצעים קריאות לפעולות במערכת, אז ברגע שנרצה להחליף מודל מסוים לא יהיה צורך לשנות את כל המודלים שמשתמשים במודול המוחלף מפני שהממשק לא משתנה, אלא רק המימוש שלו – ולמעשה, בכך אנו מאפשרים למערכת שלנו גמישות ויכולת גידול בעלות נמוכה.
דרכי ההתמודדות עם האתגרים — דרכים מורכבות יותר לביצוע:
שינוי ארכיטקטורה של המערכת
זהו תהליך שיכול להתבצע על מודול מסוים מהמכלול של המערכת ויכול להיות צורך בשינוי ארכיטקטורה של כל המודלים במערכת. זהו תהליך שדורש איש תוכנה בכיר עם ניסיון בתכנון מערכת תוכנה. במידה ויש לנו מערכת תוכנה עם ריבוי תלויות וקטעי קוד לא יעילים ולא קריאים, שינוי בארכיטקטורת התוכנה יהיה מאוד קשה לביצוע.
שימוש בתבניות עיצוב (Design patterns)
ע”י שימוש בתבניות עיצוב, אנו יכולים להתגבר על אתגרים שיעלו כתוצאה משינוי או תוספת של קוד חדש, אם נשתמש בפתרון מוכר וידוע כגון מתאם (Adapter), מפעל אבסטרקטי (Abstract Factory), סינגלטון וכו’ נוכל להתמודד עם האתגרים בצורה טובה, תוך שמירה על איכות הקוד ועל כך שהמערכת תהיה גמישה לשינויים.
שינוי של שפת פיתוח התוכנה
מעבר לפיתוח בשפת תוכנה שונה הוא אתגר לא פשוט, מכמה היבטים, לכל שפת תוכנה שאנו מטמיעים בארגון ובמערכת התוכנה שלנו, נלווים אליה הרבה הכשרות ותשתיות שנכתבו עבור אותה שפה. במידה והמערכת שלנו כתובה ב-JAVA ואחד מהמודולים החדשים שלנו נדרש לתמוך בעיבוד זמן אמת קריטי שבו יש צורך בזמן תגובה מהיר, יתכן שנצטרך לעבור לפיתוח בשפת C/C++שפה שיותר קרובה לשפת מכונה, דבר זה כולל גיוס והכשרה של עובדים עם ניסיון רלוונטי, פיתוח תשתיות וביצוע בדיקות לקוד החדש וכמובן שיש לתהליך זה מחיר גבוה בכדי להגיע לרמת קוד ייצור.
לסיכום
הנקודות שמניתי למעלה הן הנקודות העיקריות שנותנים מענה לאתגרים של ההיבט התוכנתי. כמובן שיש עוד לא מעט נקודות ופעולות שניתן לבצע בכדי לתת מענה לאתגרים התוכניתיים שנדרשים לצורך הגדלת הביצועים והקיבולת של המערכת, ולכן במאמרים הבאים נעבור על פתרונות ומעבר לטכנולוגיות מבוזרות מבוססות ענן הנותנות מענה להרבה אתגרים.
מאת: ניר מקמל, ארכיטקט תוכנה למערכות מבוזרות מתקדמות
רוצים להתעדכן בתכנים נוספים בנושאי ענן וטכנולוגיות מתקדמות? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר