יש מיתוס קטן ומסוכן בפרויקטי Web: אם הפרויקט קטן, לא צריך לחשוב על ארכיטקטורה. פשוט בונים מהר, שמים כמה קומפוננטות, קצת data בקובץ אחד, כמה תנאים בתוך ה-UI, וזהו. הרי זה רק אתר תדמית, רק פורטפוליו, רק כלי קטן.
הבעיה היא ש"קטן" לא אומר "חד פעמי". הרבה פעמים דווקא פרויקטים קטנים הם אלה שחוזרים אליהם שוב ושוב: מוסיפים כתבה, מחליפים פרויקט, מתקנים קופי, משנים CTA, מחברים דומיין, מעדכנים SEO. אם לא שמים גבולות כבר בהתחלה, כל שינוי קטן נהיה חיפוש ארכיאולוגי.
הבעיה: קוד קטן יכול להפוך מהר לקוד שביר
בפרויקט קטן קל מאוד להצדיק קיצורי דרך. אין צוות גדול, אין מוצר ענק, אין תיעוד ארוך. אבל מהר מאוד מופיעים סימנים מוכרים:
- אותו טקסט מופיע בכמה מקומות.
- קומפוננטה אחת יודעת יותר מדי.
- תוכן, תצוגה ולוגיקה מתערבבים.
- שינוי בשפה אחת שובר שפה אחרת.
- קשה להבין איפה מוסיפים פריט חדש בלי לחשוש לשבור משהו.
זה לא תמיד נראה כמו "חוב טכני" דרמטי. לפעמים זה רק עשר דקות של בלבול בכל פעם שחוזרים לפרויקט. אבל עשר דקות כאלה מצטברות, ובעיקר יוצרות חוסר ביטחון.
הפתרון: גבולות פשוטים, לא מערכת כבדה
אני לא חושב שכל אתר קטן צריך שכבות ארכיטקטורה מפוארות. זה בדרך כלל רק מוסיף רעש. אבל הוא כן צריך כמה גבולות ברורים.
בפורטפוליו שלי, למשל, יש הפרדה בין דפי React, קומפוננטות, תרגומים, נתוני פרופיל ותוכן הבלוג. זה אומר שכתבה חדשה היא לא "לחפש איפה יש JSX מתאים", אלא להוסיף MDX ולעדכן אינדקס ברור. פרויקט חדש לא מחייב לפתוח חצי אתר, אלא להכניס אותו למבנה נתונים שמיועד לזה.
הגבולות האלה לא הופכים את הפרויקט למסובך. הם דווקא מורידים לחץ.
מה גבול טוב נותן?
גבול טוב עושה שלושה דברים:
- הוא אומר איפה שינוי אמור לקרות.
- הוא מקטין את הסיכוי ששינוי אחד ישבור אזור אחר.
- הוא נותן ביטחון לחזור לפרויקט גם אחרי חודש.
זה חשוב במיוחד בפרויקטים ציבוריים. פורטפוליו לא נמדד רק ביום ההשקה. הוא נמדד בכל פעם שמישהו לוחץ על לינק, קורא קייס סטאדי, עובר בין שפות, או בודק אם העבודה עדיין חיה.
אם המבנה מאפשר להמשיך לעדכן בלי לפחד, האתר נשאר חי. אם כל שינוי מרגיש כמו ניתוח פתוח, האתר מתחיל להישאר מאחור.
למה זה עניין מוצרי
ארכיטקטורה טובה בפרויקט קטן היא לא עניין של "יופי קוד" בלבד. היא משפיעה על המוצר.
אם קל להוסיף כתבה, הבלוג מתעדכן. אם קל לעדכן פרויקט, הפורטפוליו נשאר אמין. אם קל לתרגם תוכן, שתי השפות נשארות מסונכרנות. אם קל להריץ בדיקות, יותר סביר שבאמת יריצו אותן.
בסוף, מבנה קוד הוא לא רק דבר שמפתחים רואים. המשתמש מרגיש את התוצאה שלו דרך אתר מעודכן, יציב וברור.
מה למדתי
הגישה שעובדת לי היא לא לבנות מסגרת גדולה מדי, אלא לשאול שאלה פשוטה: אם אחזור לפה בעוד חודש, האם אבין איפה לשנות?
אם התשובה היא כן, כנראה שהארכיטקטורה מספיק טובה לגודל הפרויקט. אם התשובה היא לא, גם אתר קטן צריך עוד קצת סדר.
פרויקט קטן לא צריך להיראות כמו מערכת ענקית. הוא כן צריך להיות בנוי כך שאפשר להמשיך לעבוד עליו בלי לשבור אמון.