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

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

יש שתי גישות להתמודד עם התהליך הבלתי נמנע הזה-

1. אפשר להילחם ב Complexity - לשמור על מודולים קטנים, לשכתב בקיצוניות קוד ברגע שמתחיל להיות מסורבל, הביטוי Move fast and break things מתאר סוג כזה של פיתוח.

2. אפשר להכיל את ה Complexity - לבנות ארכיטקטורות Object Oriented מורכבות, להשתמש ב Type System, לכתוב בדיקות, ללמוד לחיות עם זה שלעולם לא תצליח להבין כל פרט בקוד, ללמוד להשתמש ב Debugger, לכתוב המון תיעוד ו wikis ואפילו להיעזר ב AI כדי לקבל תשובות על הקוד.

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