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

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

האמת היא שהפריימוורק הוא לא העניין פה.

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

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

פריימוורק הוא לא הבעיה וגם לא הפיתרון.

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

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