עקרונות לפיתוח אפליקציות מודרניות מבית NGINX. חלק 1

שלום חברים. לקראת השקת הקורס "מפתח אחורי ב-PHP", באופן מסורתי אנו חולקים איתך את התרגום של חומר שימושי.

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

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

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

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

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

על ידי יישום העקרונות הללו, תמצא את עצמך מנצל את המגמות האחרונות בפיתוח תוכנה, כולל ה דופים לפיתוח ואספקת יישומים, השימוש בקונטיינרים (לדוגמה, סַוָר) ומסגרות תזמור מכולות (לדוגמה, קוברנט), שימוש במיקרו-שירותים (כולל Microservice Architecture nginx и ארכיטקטורת תקשורת רשת עבור יישומי microservice.

מהי אפליקציה מודרנית?

יישומים מודרניים? מחסנית מודרנית? מה זה בעצם אומר "מודרני"?

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

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

אפליקציה מודרנית מספקת API לגישה לנתונים ולשירותים המבוקשים. ה-API צריך להיות בלתי משתנה וקבוע, ולא נכתב במיוחד עבור בקשה ספציפית מלקוח ספציפי. ה-API זמין דרך HTTP(S) ומספק גישה לכל הפונקציונליות שנמצאת ב-GUI או ב-CLI.

הנתונים חייבים להיות זמינים בפורמט נפוץ וניתן לפעולה הדדית כגון JSON. ממשק API חושף אובייקטים ושירותים בצורה ברורה ומאורגנת; לדוגמה, RESTful API או GraphQL מספקים ממשק הגון.

יישומים מודרניים בנויים על מחסנית מודרנית, וערימה מודרנית היא המחסנית שתומכת ביישומים כאלה, בהתאמה. מחסנית זו מאפשרת למפתח ליצור בקלות אפליקציה עם ממשק HTTP ונקודות קצה ברורות של API. הגישה שתבחר תאפשר לאפליקציה שלך לקבל ולשלוח נתונים בקלות בפורמט JSON. במילים אחרות, המחסנית המודרנית תואמת את המרכיבים של יישום Twelve-Factor עבור שירותי מיקרו.

גרסאות פופולריות של סוג זה של מחסנית מבוססות על Java, פיתון, צומת, אוֹדֶם, PHP и Go. Microservice Architecture nginx מייצג דוגמה לערימה מודרנית המיושמת בכל אחת מהשפות שהוזכרו.

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

עקרונות

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

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

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

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

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

הבה נסתכל על שלושת העקרונות הללו ביתר פירוט.

עקרון הקטנות

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

יישומים מפורקים מהסיבות הבאות:

• הפחתת העומס הקוגניטיבי על מפתחים;
• האצה ופישוט הבדיקות;
• משלוח מהיר של שינויים באפליקציה.

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

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

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

טווחי זמן פיתוח מופחתים

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

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

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

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

בסיסי קוד קטנים

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

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

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

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

שינויים מצטברים קטנים

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

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

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

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

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

סוף החלק הראשון.

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

מקור: www.habr.com