ארכיטקטורת VIPER מודולרית וגמישה ל-iOS עם מחוללי קוד

מה נותן השלד המודולרי: מהירות בנייה וצפיות

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

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

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

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

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

דרכי ארגון שכבות VIPER: השוואת גישות

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

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

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

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

שלבי המעבר של האפליקציה לסכמה מודולרית

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

סדר העבודות הוא כך.

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

מה נשאר לצוות לאחר מסירת הפרויקט

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

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

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

מקרה בוחן: קיצרנו את זמן הבנייה והסרנו מחלקה של כשלים

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

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

מעבר למודולים

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

מספרים לפני ואחרי

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

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

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

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

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

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

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

ספקות טכניים: בדיקות, תלויות, גיוס לסכמה

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

מה עושים עם התלויות בין המודולים?

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

האם נדרש מהנדס נפרד לתמיכה?

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

כמה מהר מפתח חדש נכנס לפרויקט?

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

נדון במשימה ונחזור עם תוכנית עבודה

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

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

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

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