February 18, 2026

ביקורת קוד על קוד שנוצר בעזרת קלוד

עולם בעיה

עולם הבעיה שלנו הוא פשוט - במשחק Feahtersteel Saga רציתי להוסיף יכולת לשחקן לבצע סקילים.
סקיל היא יכולה המפעילה משהו בזמן המשחק.
למשל - היכולת לירות 2 חצים בבת אחת.
חץ שמתפוצץ ועושה נזק אגבי לייצורים אחרים.
סקיל שיוצר מגן על השחקן מפני נזק וכדו’…

הקוד הקיים

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

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

אז מבלי לחפור יותר מדי… הפתרון שלי:

הפתרון שאני הייתי מבצע

עקרונות הפתרון:

  • אבסטרקציה נמוכה, למשל ליצור ממשק לכל סוג של סקיל, אם יש לי סקיל שיורה או סקיל שמגן הם יהיו ממשקים שונים.
  • לא ליצור יותר מדי דברים חדשים - כאשר יוצרים מלא מחלקות בבת אחת אפשר להתבלבל וליצור קוד לא טוב.
  • עקרון האחריות היחידה - אני מנסה לשמר כמה שיותר שכל גורם ייתעסק במשהו אחד.
  • פיצול מימוש - כל מחלקה תממש את הצד שלה, לא נרצה למחלקה אחת תגדל למפלצת או מה שנקרא God class.

חייב לומר שעקרונות תוכנה מושתתים אצלי עמוק בפנים - כבר לפני 10 שנים ויותר למדתי את העקרונות האלו ומאז הם אצלי.

סך הכל יצרתי 3 ממשקים:

  • ISkills
  • IShootingSkill
  • ICharacterAlterSkill

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

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

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

או בקוד:

1
2
3
4
5
6
7
def Execute(self, skill: Skill):
cost = skill.ManaCost()
has_enough = self.ManaContainer.HasEnoughMana(cost)
if has_enough:
self.ManaContainer.ReduceMana(cost)
else:
except NoManaException()

הבנו את הדרך שלי - אבסטרקציה מינימלית, שימוש בממשקים.

הפתרון שקלוד ביצע

בדרך הזו אני רואה כמה בעיות של מתכנת חובבני:

  • הוא יצר SkillManager ביחד עם SkillRegistry.
    ההפרדה הזו לא מובנת ויוצרת הרבה בלבול בין מי מחזיק איזו לוגיקה.
  • מימוש יצירת החצים והמתמטיקה נמצאת בתוך מחלקת Character מה שיוצר לנו - God class.
  • הפרדת הממשקים לא באמת עוזרת כי אין לנו צורך בממשק ISkill מלבד להחזיק אותם ביחד.

מה כן טוב פה?

  • הוא יצר את הכל יחסית מהר, האם איכותי? לא כל כך, האם מהר? כן.
  • הוא יצר הפרדה בין מי שמנהל טיימרים לסקילים לבין הסקילים עצמם.
  • הוא מימש מעיין Visitor pattern לסקילים הפאסיביים ובעצם הוא מקבל את ה-Attributes שאליהם הוא עושה אלטרנציה מבחוץ.

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


מה לעשות הלאה?

  • הגדירו לו בClaude.md איך לעצב קוד, הגדירו קוד סולידי ואיזון בין ממשקים למחלקות.
  • הגדירו שלבים שהוא ייבצע דברים צעד-צעד ולא הכל בבת אחת, אולם חילקתי את זה ל-3 אבל כנראה הייתי צריך לחלק ליותר.
  • מדי פעם תעצרו אותו ותבדקו מה הוא עשה.
  • איטרציות זה שם המשחק - עשו איטרציות עוד ועוד עד שהתוצאה שלכם תהיה רצויה.
  • אל תתפשרו, ברגע שתפפשרו הוא יבין שזה ה”עיצוב” הנכון בפרוייקט שלכם.

תודה על הקריאה!

על הפוסט

הפוסט נכתב על ידי Ilya, רישיון על ידי CC BY-NC-ND 4.0.

שתפו את הפוסט

Email Facebook Linkedin Print

קנו לי קפה

#Software#AI#ClaudeCode#Claude