למה כל ספרייה זקוקה לפרויקט אמיתי
מחברי ספריות רבים טועים. הם חושבים שדוגמאות מספיקות.
דוגמאות אינן מספיקות.
דוגמאות מוכיחות שפיצ'ר עובד. פרויקטים אמיתיים מוכיחים שספרייה עובדת. אלו שני דברים שונים.
אני בונה הרבה אפליקציות דמו. אני בונה אתרי דוגמה, APIs ורכיבים. הכל נראה מושלם בדמו. דמו מציגים את ה-"happy path". הם מציגים את זרימת העבודה האידיאלית.
דמו הם סביבות מבוקרות. הארכיטקטורה פשוטה. הדרישות נשארות צפויות.
פרויקטים אמיתיים הם שונים.
כשמשתמשים בספרייה עבור פרויקט אמיתי, הכללים משתנים. אתם כבר לא עושים הדגמה. אתם פותרים בעיה.
פרויקטים אמיתיים מביאים:
- לוחות זמנים צפופים
- דרישות משתנות
- פריסות (layouts) מורכבות
- מקרי קצה (edge cases)
- טעויות אנוש
כאן הספרייה מראה את כוחה האמיתי. היא מראה את חולשתה האמיתית. ספרייה חושפת את עצמה תחת לחץ, לא בדמו.
פרויקטים אמיתיים חושפים את ההנחות שלכם. רעיון עשוי להיראות אלגנטי על הנייר. הוא עשוי להיות הגיוני במהלך הפיתוח. ואז המציאות מכה.
זרימת עבודה מרגישה מגושמת. קונפיגורציה מרגישה חזרתית. API מרגיש לא טבעי. העיצוב שלכם לא שגוי, אבל הוא עדיין לא פגש את המציאות.
הדבר הטוב ביותר שמחבר יכול לעשות הוא להפוך למשתמש של התוכנה שלו. אל תבנו רק דמו. בנו אתרים, אפליקציות ועסקים באמצעות הכלים שלכם. תסתמכו עליהם.
כשאתם מסתמכים על התוכנה שלכם, נקודת המבט שלכם משתנה. אתם מפסיקים לחשוב כמו מחברים. אתם מתחילים לחשוב כמו משתמשים.
למשתמשים אכפת מ:
- חיכוך (friction)
- בהירות
- ביצוע העבודה
בניית דברים אמיתיים משנה את השאלות שלכם. אתם מפסיקים לשאול "אילו פיצ'רים כדאי לנו להוסיף?". במקום זאת, אתם שואלים:
- למה זרימת העבודה הזו מרגישה מגושמת?
- למה אני חוזר על עצמי?
- למה זה לקח יותר מדי זמן?
פתרון הבעיות הללו יוצר תוכנה טובה יותר מכל סשן סיעור מוחות.
כל ספרייה זקוקה לפרויקט אמיתי. הפרויקט הזה אינו לצורך שיווק. הוא שדה ניסוי. הוא מאלץ את הספרייה לפתור בעיות אמיתיות. הוא מוצא חולשות לפני שהמשתמשים שלכם ימצאו אותן.
המטרה היא לא להוכיח שהספרייה שלכם מושלמת. המטרה היא ליצור דרך עבור הספרייה שלכם להשתפר.
מקור: https://dev.to/stinklewinks/why-every-library-needs-a-real-project-1ae7