כל פריימוורק הופך לשפה
מפתחים מתמקדים לעיתים קרובות בתכונות של פריימוורק.
הם מסתכלים על ניתוב (routing), ניהול מצב (state management) וכלי בנייה (build tools). החלקים האלו חשובים. אבל תכונות הן לא החלק החשוב ביותר של פריימוורק ארוך-טווח.
פריימוורק הופך בסופו של דבר לשפה.
זו לא שפת תכנות. זו שפה של רעיונות, תבניות (patterns) וכוונות. השפה הזו הופכת ליקרה יותר מהקוד עצמו.
רוב הפריימוורקים מתחילים כפתרונות לבעיות טכניות. הם פותרים איך לנתב בקשות או לארגן קוד. בשלב הזה, הפריימוורק הוא רק רשימה של תכונות.
ואז, משהו משתנה.
ככל שיותר אנשים משתמשים בכלי, תבניות מתחילות לצוף. אנשים מתחילים להשתמש באותם פתרונות ומוסכמות (conventions). הפריימוורק מתחיל ללמד אותך איך לחשוב.
אתה לא רק לומד את ה-APIs. אתה לומד את הפילוסופיה. אתה לומד את ההנחות.
אפשר לראות זאת אצל מפתחים מנוסים. אתה מזהה אותם לא לפי התחביר (syntax) שלהם, אלא לפי המודלים המנטליים שלהם. הם מדברים בשפה של האקוסיסטם שלהם.
תחביר משתנה. גרסאות משתנות. תכונות משתנות. אבל השפה שבבסיס נשארת.
אוצר מילים משותף מפחית מורכבות. מונח אחד יכול להסביר מושג שלם. מוסכמה אחת יכולה להסביר תהליך עבודה (workflow) שלם. כך מפתחים מעבירים רעיונות במהירות.
זה משנה את הדרך שבה אתה כותב תיעוד (documentation).
תיעוד טוב מלמד אוצר מילים ומושגים. הוא עוזר למשתמשים להבין איך המערכת חושבת. תיעוד גרוע רק מפרט תכונות. אחד מוביל להבנה. השני מוביל לשינון.
פרויקטים אמיתיים מעצבים את השפה הזו. אי אפשר לעצב שפה בבידוד. היא צומחת משימוש אמיתי ומחיכוך אמיתי. הרעיונות המועילים נשארים. הרעיונות הגרועים נעלמים.
זה קורה בכל תחום. עסקים, מוזיקה ואדריכלות – כולם מפתחים שפות. אוצר מילים משותף הופך שיתוף פעולה לקל.
כשבונים תוכנה, הפסק לשאול איזו תכונה להוסיף בהמשך. שאל את השאלות הבאות במקום:
- האם זה מתאים לשפה?
- האם זה מחזק את הפילוסופיה?
- האם זה הופך את המערכת לקלה יותר להבנה?
תכונות יוצרות כלים. שפות יוצרות אקוסיסטמים. הפריימוורקים המצליחים ביותר לא רק מספקים תוכנה. הם מספקים דרך לבטא רעיונות.
מקור: https://dev.to/stinklewinks/every-framework-eventually-becomes-a-language-1b4h