רעיונות מסדרים, פתרונות נקודתיים
האם יש אמת אחת שמתאימה לכל מערכות התוכנה או שלכל מערכת יש את הכיוון והאופי שלה?
אם אתם מאלה שחושבים שיש אמת אחת, דרך אחת שמתאימה לכולם, המשיכו לקרוא. הפוסט הזה לא בשבילכם.
נשארתם? יופי. אז אם אנחנו מסכימים שלמערכות שונות יש אופי שונה למה כולנו משתמשים באותם מודלים ושואלים אותם את אותן שאלות? איך המודל אמור לדעת מה האופי של המערכת לפני שמייצר את התשובה?
סוכני קידוד מנסים לעזור. הם נותנים למודל דרך לקרוא חלק מהקוד. הם מריצים Linters שאולי שומרים על Code Style מסוים. הם מריצים את הבדיקות. אבל זה רק חלק מהתמונה.
החלק השני הוא הרעיונות המסדרים. רעיונות כמו:
מינימליזם - במערכת שלנו אנחנו בונים את הקוד הכי קטן שפותר את הבעיה. אנחנו לא רוצים לפתור בעיות נוספות ולא מוכנים לשלם אפילו מחיר קטן על התאמת הקוד לבעיות מהעתיד.
ביצועים - אצלנו בצוות יש תרבות של שמירה על ביצועים. אנחנו מתגאים שהמערכת שלנו נטענת מהר, תופסת מעט מקום ויעילה יותר מהמתחרים. כל שינוי קוד נמדד בהשפעה שלו על הביצועים ואנחנו שמחים לשלם בזמן פיתוח בשביל שיפור אפילו שולי בזמן הטעינה והריצה של התוכנית.
תכנות דפנסיבי - המשתמשים שלנו משוגעים והמערכת שלנו צריכה להתאים לכל מצב. אנחנו כותבים קוד גמיש שתמיד מוצא את הדרך לעבוד ולא להתרסק.
מהירות פיתוח - אנחנו סטארט-אפ שנאבק למצוא התאמת מוצר לשוק. זה ה Pivot השלישי שלנו. אנחנו בונים קוד שאפשר לשנות מהר, בלי סכימות, לא 100% עובד אבל בעיקר לא מסבך אותנו עם מיגרציות יקרות כשצריך לקחת צעד אחורה ולשנות מסלול.
המפתח הכי צעיר שלנו עובד פה 8 שנים. כולם מכירים את הקוד לעומק ומבינים כל שורה וכל פסיק. אנחנו כותבים קוד קצר ומדויק ולא מבזבזים תווים על הערות או הסברים ארוכים.
הרשימה היא רק דוגמה - אתם בוחרים את הפילוסופיה של המערכת שלכם. הדבר החשוב שתהיה לכם אחת.
ואחרי שבחרתם תוכלו לשמור אותה בקובץ AGENTS.md תחת סעיף Philosophy או Coding Approach כדי לקבל מהסוכן הערות שמתאימות לאותה פילוסופיה לדוגמה:
This commit mostly matches the Philosophy section in AGENTS.md. The coupon list is stored as a JSON column instead of a new table, which fits "Development speed": no migration to undo if we pivot again. One deviation: the new CouponValidator handles currency mismatches and expired-but-grace-period coupons, neither of which exists in the product today. Per "Minimalism," I'd remove both branches and keep only the expiry check.
כשהגישה שלכם כתובה בצורה ברורה הרבה יותר קל לקלוד לענות על שאלות כמו "מה עשיתי לא בסדר" או "באיזו מידה הקוד החדש תואם את הפילוסופיה של המערכת".