פרונטאנד React מקצה לקצה: ארכיטקטורה, אופטימיזציה, פריסה

מדוע פיתוח ממשק React נתקע בשלב האינטגרציה

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

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

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

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

מה משתנה אחרי עיבוד מחדש של הצד הקליינטי: אפקטים מדידים

מענה הממשק

קודם הדף החזיר את כל הקוד בבת אחת, והמשתמש חיכה 3-4 שניות במכשיר נייד ממוצע. אחרי עיבוד מחדש ב-React — פיצול קוד לפי מסלולים, מטמון לבקשות, ויתור על רינדורים מיותרים ברשימות כבדות. הזמן עד לאינטראקציה הראשונה מתקצר פי 2-4, הגלילה מפסיקה "לרעוד" במכשירים חלשים.

הוצאת עדכונים

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

פחות תיקונים ידניים

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

פחות כשלים, חזרה לאחור צפויה

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

עלות התמיכה

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

פורמטים של עבודה: צוות פנימי, הרכב ייעודי, השלמה ממוקדת

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

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

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

שלבי פיתוח אפליקציית React: מהאודיט ועד מסירת הקוד

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

1. אודיט של הקוד והתשתית. בוחנים את המאגר הקיים, תלויות, בנייה, כיסוי בבדיקות, צווארי בקבוק ברינדור. בפלט — דוח עם נקודות סיכון והערכה מה נשתמש מחדש ומה נכתוב מחדש.
2. סכמת ארכיטקטורה. מגדירים גבולות מודולים, ניתוב, עבודה עם מצב ונתונים, היכן הרינדור שרתי והיכן קליינטי. הסכמה מאושרת לפני שורת הקוד הראשונה — תיקונים בשלב הזה הם הזולים ביותר.
3. הרכבת השלד. מרימים טיפוסיות, לינטרים, פיצול לשכבות, סביבות פיתוח ובנייה. השלד מספק מיד מבנה צפוי, שאליו הצוות מוסיף מסכים בלי "גן חיות" של פתרונות.
4. אינטגרציה. מחברים את הממשק עם הצד השרתי ועם שירותים חיצוניים: חוזי בקשות, מטמון, טיפול בשגיאות ובמצבי טעינה, הרשאה. את החוזים מקבעים, כדי ששינויים בצד האחורי לא ישברו את הממשק בשקט.
5. בדיקת תרחישים. מריצים את מסלולי המשתמש במלואם, כולל נדירים ושגויים: תגובות ריקות, ניתוקי קשר, בקשות איטיות. בנפרד בוחנים מדדי טעינה ומענה במכשירים חלשים.
6. מסירת הפרויקט. מוסרים מאגר עם היסטוריה, תיעוד לפריסה ולארכיטקטורה, הוראות למפתחים. עורכים פירוק קוד עם צוות הלקוח ונשארים בליווי, אם צריך.

ערכת מסירה: קוד, סכמות, נהלי מהדורה והרשאות

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

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

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

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

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

מה שינו

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

תוצאת הפרויקט

הזמן עד למוכנות הממשק התקצר מ-5,4 ל-1,5 שניות, תזוזות הפריסה נעלמו. שיעור הסלים הננטשים ירד מ-41% ל-17%, ההמרה של הממשק להזמנה מבוצעת גדלה פי 1,8 בתעבורה ניידת. הכשלים בשלב התשלום ירדו פי שלושה — כניסה חוזרת כבר לא מאפסת שדות מלאים.

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

במה שונה כתיבה מאפס מהחלפה הדרגתית של מודולים

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

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

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

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

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

ספקות טכניים לפני ההתחלה: קצר ולעניין

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

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

כיצד בנויה בדיקת איכות הקוד?

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

מי אחראי על ההוצאה לפרודקשן?

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

מה יקרה אם פרויקט ייקח צוות אחר?

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

נדון במשימה: מה לשלוח בהודעה הראשונה

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

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

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