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

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

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

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

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

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

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

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