שלום לכולם.

[gilad_no]

הערה קטנה לגבי Location:

אין צורך לממש אופרטור השמה. אם ישנה מחלקה\מבנה שלכל הטיפוסים שלו ממומשים אופרטורי השמה (במקרה הנ"ל - X,Y שהם משתנים רגילים), ניתן לבצע השמה בין אובייקט אחד למשנהו בצורה אוטומטית גם בלי לממש זאת ידנית.

 

[אלדד28]

אני אשמח מאוד לראות.

 

[Scipio]

ראה קוד בשירשור

 

[Zack DA]

העלה את הקוד, אנו סקרנים ../images/Emo13.gif

 

[גיל14]

לא יותר מדי זמן...

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

 

[אלדד28]

היו הרבה אנשים שנשמעו ככה.

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

 

[Scipio]

צעצוע של מודל

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

 

[אלדד28]

אתה צודק,

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

 

[Scipio]

צריך לקבוע את שיטת העבודה לפי היעד

אני מסכים שתכנון + בדיקות אוטומטיות זוהי צורת עבודה טובה ובטווח הבינוני והארוך משתלמת יותר (לרוב) - אבל צריך להגדיר היטב את היעד. במקרה דנן - תכנון ארוך מדיי + התעקשות על איכות תוכנה גרר ל"ביטול" הפרוייקט ולכן פיספס את היעד. זה גם די צפוי בגלל המחויבות הנמוכה והערכת החסר עד לקבלת תוצאות ממשיות. גם לשנות - בטח בתוכנה בהיקף כזה זה לא כל כך נורא. לכתוב תוכנה כזו עם ממשק + תמיכה ברשת זה נראה לי כמו סדר גודל של פרוייקט לא גדול במיוחד של אוניברסיטה - אבל ברמת נסיון לא מקצועית של סטודנטים בשנים ראשונות (ושנה אחת של נסיון מעשי מקטינה בהרבה את "היקף" הפרוייקט. אז גם אם התכנון גרוע אפשר לשכתב מה שנדרש אחרי שרואים כבר את המשחק. אני חושב שצריך גמישות ולדעת מתי גם לחתוך פינות כאשר עושים זאת בצורה מודעת. מה שקרה פה זה Analysis Paralysis .. במקום לקבל משהו שעובד - היה דיון (שגם אני השתתפתי בו

עם צריך הירכיה שלמה של חיילים או מספיק רק כמה מחלקות .... נו טוף...

 

[אלדד28]

אתה מתכוון,

היה דיון "האם צריך מחלקות של חיילים או שנעשה 'כאילו' ++C עם מחלקה אחת ודי"

 

[Scipio]

משהו כזה - אבל לא בדיוק

היה כזה דיון. רמת ה OO לא מתבטא במספר המחלקות אלא במה שהם מייצגות (שכמובן יש דרכים רבות). במקרה הספציפי של טקטיקו לעשות 10 מחלקות עבור כל סוג של חייל נראה לי OVERKILL . שכן ההבדל בין 2 3 4 5 6 7 (גנרל עד מה שלא יהיה 7 המסכן) הוא רק הדירוג בינהם (ואולי נניח איזה ICON מייצג אותם) ואפשר להכניס את זה כ ATTRIBUTES במחלקה. למשל במודל המשחק שכתבתי יש מחלקה אחת שמטפלת בכל סוגי החיילים. נכון יש כמה IF שמתייחסים לסוג ואפשר היה להחליף או להרחיב בהורשה ויכול להיות שאם היה סט חוקים אחר - או לחלופין - המטרה היתה ליצור מספר משחקי טקטיקו (בעלי חוקים שונים) אז הורשה הייתה כדאית (למשל כמו שעשיתי ב PLAYER וTAKTIKOPLAYER אשר מגדיר עבור סט החוקים של טקטיקו את מספר החיילים (למרות שאני לא חושב שלרוב כדאי לבנות הירכיות מנוונת (שרשרות) כי הם גורמות לסיבוך ה DESIGN בלי לתת תמורה. תופעות של OVER DESIGNING הם די נפוצות ולפעמים אתה מקבל ערמות של קוד אשר יכול להיות תשתית של משהו כמו OFFICE אבל נועד בעצם בשביל לשחק איקס עיגול

. שיטות Refactoring הם בעייתיות כיום בגלל חוסר תמיכה של ה IDE אבל יכולות להיות מאד יעילות.

 

[אלדד28]

במשחק המקורי היו התנהגויות שונות

לחלק בלתי מבוטל מהחיילים - ולא סתם הבדל דירוג. היה בהחלט מקום לירושה. בכל מקרה, ברור שרמת ה-OO אינה נקבעת על פי כמות המחלקות, אבל לעשות מחלקה עם ENUM בתוכה ו-50 פונקציות עם SWITCH-CASE-ים זה, איך לומר, לשחק ב-C בתוך ++C. זה בדיוק עניין ה-Refactoring. אגב, לא כל REFACTORING אפשרי לביצוע על ידי כלים אוטומטיים.

 

[Scipio]

OO זה לא רק שפה

אני מסכים לעשות מחלקה והרבה SWITCH CASE בתוכה זה לא OO. אבל לא צריך להגזים. כך למשל בקוד שיישמתי - אני לא חושב שצריך ליצור מספר הירכיות (כאשר מה שיש זה כל ההיקף). אם ההיקף היה מתרחב והיה שוני רב יותר - אני מוצא הצדקה לפיצול. בכל מקרה ראיתי קוד של C שהוא OO - הרבה יותר מסורבל אבל אפשר לישם קוד פרוצדרולי אפילו בשפה JAVA וקוד OO בתוך ASSEMBLY

הרבה מהREFACTORING יכול היה להעשות על ידי כלים אוטומטיים - הבעיה היא 1. טכנית (אין כל כך הרבה כלים כאלה) 2. לפעמים הקידוד הוא מונע רעיון אבל אחרי שיש רק קוד הרעיון "נעלם" - אם הרעיון היה נשאר איכשהו אפשר היה לעשות REFACTORING יעיל יותר. זה כמו שמישהו אומר - שמע אפשר לחבר המחלקות האילו יחד - או לפצל משהו. זה דבר טכני לחלוטין וברור מה צריך לעשות אבל בכל זאת כלי טריוייאלי לא יכול להיות קיים. - בצורה כללית - Refactoring שאפשר להגדיר אותו במדויק במילים ואחר כך לוקח הרבה זמן (טכנית) זה Refactoring שאפשר לעשות אותו (תיאורטית כרגע) אוטומטי.

 

[אלדד28]

נכון, לא צריך להגזים לשני הכיוונים.

אין בינינו מחלוקת. לגבי REFACTORING, יש סיבה טובה לזה שאין כלים כאלו - אנשים פשוט לא סומכים עליהם. אם היה לך פרויקט של חצי מיליון שורות קוד, היית מריץ עליו תוכנה כזו? אתה צריך אח"כ לשבת לבדוק שינוי שינוי, ולבדוק מחדש את כל המערכת. מה שכן, כלים שמציעים לך לשנות ומסבירים לך גם למה, זה כבר סיפור אחר לגמרי. אגב, גם אני הייתי בגישה של "זה טכני לחלוטין", אבל זה נכון רק לחלק מה-REFACTORING-ים. לא לכולם, וחלק בלתי מבוטל הוא מאוד, מאוד מסובך (אם כי אולי אפשרי טכנית).

 

[Scipio]

תוכנה כזו צריכה להיות אמינה

יש לי פרוייקט עם יותר מחצי מיליון שורות קוד ואם התוכנה הייתה מאד מאד אמינה - אני מניח שהייתי משתמש בה. זה כמו שאני סומך על קומפילר. למשל על תוכנה כמו INDENT היית סומך? (למרות שמה שהוא מתיימר לעשות זה רק סינטקטי והרבה יותר קל "להוכיח " את השקילות. גם כלי REFACTORING - צריך בעצם לשנות משהו שהוא אולי גם סמנטי אבל בעיקרון הוא דבר טכני - אז אם הכלי הוא אמין הייתי עובד איתו על הפרוייקט. כמובן שהייתי בודק קודם טוב טוב (גם מגוון שלם של מודולים ) את התוכנה אבל לבסוף הייתי משתכנע. חלק גדול הוא טכני לחלוטין - דווקא היום יצא לי להעיף מבט על Dr Dobbs ראה לינק על Radical Refactoring. לחלק גדול זה שבלוני לחלוטין באמצעות ה"ידע" שיש לקומפיילר / לינקר אפשר לעשות את זה די בקלות (כאשר ידע כזה הוא כמובן שלא טריוויאלי בכלל)..