הגדרת ארכיטקטורת BLoC לאפליקציית Flutter

מדוע BLoC Flutter נשבר בעת הרחבת מסכים

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

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

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

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

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

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

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

מה נותנת ארכיטקטורת אפליקציה בנויה היטב

מחזור בנייה ושחרור צפוי

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

התאוששות מתקלה ומחלקת כשלים

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

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

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

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

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

שכבות, מצבים ואירועים: איך בנוי BLoC Flutter

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

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

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

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

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

שלבי בניית הארכיטקטורה עבור המוצר שלכם

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

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

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

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

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

חפצי עבודה שנשארים אצל הצוות שלכם

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

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

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

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

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

מה שינו

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

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

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

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

מה זה נתן לצוות

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

במה שונה BLoC מגישות אחרות לניהול מצב

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

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

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

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

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

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

ספקות טכניים נפוצים לפני התחלה

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

עד כמה זה תואם לספריות ולניווט הנוכחיים?

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

מה עם התמיכה לאחר מסירת הפרויקט?

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

אילו סיכוני הטמעה כדאי לצפות מראש?

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

האם אפשר לחזור אחורה אם הגישה לא תתאים?

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

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

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

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

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

מה אנחנו מבררים בשיחה:

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

מה תקבלו בתום השיחה:

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

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