תוֹכֶן
זהו השני של שלושה חלקים ראיון. אתה יכול קרא את החלק הראשון כאן.
***
ההבנה שלי של פיתוח זריז היא בסיסית למדי. מעולם לא עבדתי תחת המתודולוגיה, אבל קראתי קצת על זה פה ושם. מהו בדיוק צבר חוב טכני?
צבר הוא רשימת משימות; אבל זה רשימת משימות עדיפות כי ניתן לקבל מחדש עדיפות כל שבועיים (על גבולות ספרינט) ואת הקבוצות רק להתחייב על חלון של שבועיים (ספרינט אחד). צבר של חוב טכני הוא חלק קטן מהצבר הכולל וסיפורים (משימות) אשר משולבים בצבר הכללי.
ובכן, זה לא אומר לי טון, אבל עשיתי גוגל מהירה, קצת יותר לקרוא, וקבעו כי "החוב הטכני הוא מה שעושה קוד קשה לעבוד עם.זה רוצח בלתי נראה של התוכנה, והוא חייב להיות מנוהל באגרסיביות ". בהתבסס על זה, אני מאמין שאני מבין היבט אחד של העבודה שלך הרבה יותר טוב. מודרניזציה, מעלה עד סטנדרטים, כמה קוד מבוגר של קוד פתוח באינטרנט, כמו מה שקרה Crimewatch בשנה שעברה.
אני יודע כל revamp של החברה הישנה ואת קוד קופה הוא לא על לוח הפיתוח בכל עת בקרוב, אבל כמה מתרגש אתה תהיה אם מישהו אמר "בואו לשכתב את זה ולעשות את זה נכון!"
אתה יכול לזכור את הדיונים שקרו סביב קופה לאחרונה; CCP השחף מטפל בתקשורת בנושא זה. אני יכול לדון בנושא החוב הטכני אבל לא בהקשר של POSES.
מספיק הוגן. בואו נתמודד עם זה מכיוון אחר. Crimewatch. לפי כל החשבונות קוד ישן, שביר מאוד. זה היה מאוד קשה לעבוד עם, ורוב הפרויקטים נמנע אינטראקציה עם זה, כי זה יכול לגרום לבעיות בלתי צפויות. כאשר המק"ס קיבלה את ההחלטה לשכתב קוד זה, עד כמה היית מעורב בתהליך שהתמקד בעיצוב החדש? כמה פיקוח אתה נותן לפרויקטים כגון Crimewatch כדי לוודא שהם לסטנדרטים שלך וכי הם לא להוסיף חוב טכני בהמשך הדרך? כמה היית מאושר כשהאור הירוק ניתן לשכתב את קרימיואט?
במונחים של עיצוב טכני בפועל, לא הרבה, ולא מעורב בעיצוב המשחק. להוביל טכני עבור צוותי משחק (CCP אטלס) ובעיקר מתכנת השרת הבכיר (CCP Masterplan) בקבוצה מיישמת את המערכת החדשה היו האנשים בחפירות עבור העיצוב בפועל. התפקיד שלי היה להדגיש את העובדה כי קוד Crimewatch הישן היה מתוחכם, מתכנתים זהירות וצוותים אשר ventured לתוך קוד זה ישירות לפקח על עבודתם, לקדם את הרעיון כי זה צריך להיות refactored על ידי הוכחת העלות של המערכת הנוכחית / קוד גורם לנו , ולהגדיר את הסטנדרטים לביצוע בדיקות ביצועים וביצועים (מנהל האיכות אחראי על בדיקת תכונות ותהליכי בדיקה כללית).
הייתי מאושרת מאוד כאשר הפרויקט הזה היה סוף סוף greenlighted; זה תמיד טוב להיות מסוגל לעבור את הדברים האלה מהרשימה, ולאחר מכן לעבור אל המערכת הבאה.
אני מוצא את כל צבר החוב הטכני חלק של העבודה שלך מרתק, במיוחד שכן הוא סובב סביב הרבה מערכות הליבה הישנות, EVE כי השחקנים קשה לעבוד עם ו / או רוצה לראות refactored עם תכונות טובות יותר, מודרני יותר . המק"ס הקפידה על התמודדות עם אזורים אלה של קוד ישן, פריך.
האם מערכת התפקיד של החברה ליפול לתוך צבר חובות טכניים?
במידה מסוימת, אבל בעיקר כי המערכת היא שאלה של מה זה אמור להשיג ומכאן אולי לגזור עיצוב המשחק שיפוץ. הקוד עבור מערכת זו אינו במצב רע במיוחד.
"לא במצב רע, "באיזה כבוד? מנקודת מבט של שחקן, מערכת תפקידים קשה לעבוד עם, ודברים שאנשים היו מצפים לעשות את זה, לעתים קרובות צריך להתבצע עם דרכים שונות לעקיפת הבעיה. (קלדום תיעד כמה מן הדרכים לעקיפת הבעיה במאבקיו כדי לקבל את התפקידים הארגוניים להתנהג בכמה דרכים בסיסיות). אני מניחה שהקוד יכול להיות במצב "טוב" בהתחשב במה שהוא באמת ולא נועד לעשות. רוב השחקנים יסכימו כי הוא זקוק שיפוץ. האם זה במצב טוב מספיק עבור שיפוץ כזה, האם זה נתון עדיפות הפיתוח?
אני משתמש "לא במצב רע" בהקשר של צבר חובות טכניים מן היבט טכני בלבד. מה שאתה מתאר הן בעיות שימושיות במערכת, מה שאני מכנה "שאלה של מה זה אמור להשיג ומכאן נגזר עיצוב שיפוץ המשחק". מנקודת מבט טכנית אז הקוד עצמו לא כל כך רע, קריא יחסית בתוכנית הגדולה של הדברים ולא מובנים בצורה גרועה.
מהן חלק מהמערכות אשר נופלים לתוך צבר חובות טכניים?
מערכת קופה, הדפדפן בתוך המשחק, שיפורים בביצועי ההפעלה של הלקוח, שיפורים בביצועים לשליחת אירועים סימולציה הפיזיקה ללקוחות, שיפורים בביצועים refactoring של מערכת התכונה; עד כמה שם. ישנן מערכות אחרות אבל הם ברמה נמוכה או כלים פנימיים או צינור. חלק ממערכות אלה לעיל נופל לתוך קטגוריות רבות אחרות; כגון מערכת קופה יש שימושיות היבטים עיצוב, שחלקם אנו פונים באודיסיאה עם איכות החיים שיפורים.
מי עושה את ההחלטה הסופית על מה החוב טכנית פריטים צבר יהיה לטפל?
בסופו של דבר זה מפיק בכיר שעושה שיחה על מה צבר עבור כל שחרור מכיל. היא מבקשת קלט ממפלגות שונות על סדר העדיפויות ומנסה לאזן את הצרכים הטכניים והעסקיים השונים. פריטים על צבר חובות טכניים הם בגדלים שונים ולכן משימה קטנה יותר עשוי להיעשות מוקדם יותר (כי זה נכנס לתוך לוח הזמנים), גם אם יש עדיפות טכנית פחות מאשר משימה גדולה יותר. איפה יהיו שינויים משמעותיים במכניקה המשחק, כמו עם Crimewatch, זה נופל תחת התחום של מעצב המשחק המוביל.
עם זאת, עדיין יש לך קצת הוגן קלט על סדרי עדיפויות אלה. אני מתאר לעצמי את המפיק הבכיר צריך להסתמך על המומחיות שלך ואת הניסיון עם צבר חובות טכניים?
לדעת איך המפיק הבכיר צריך לאזן את הצרכים השונים אז אני לא שולח לה רשימה עדיפות אחת; אני לדון צבר עם אותה ואת החשיבות היחסית ואת הגודל האפשרי של כל פרויקט יחד עם איך לעשות מסוימים חובות טכניות צבר חובות עשוי לאפשר דברים אחרים עבור אותה ואיך לא עושה אחרים מסוימים חובות טכניות צבר חובות עשוי "לצייר אותנו לפינה ".
האם פריטים טכניים של צבר חובות מטופלים על ידי צוות מסוים? או שהם מועברים לצוותים שעליהם ניתן להתמודד איתם בצורה הטובה ביותר (כלומר, מומחיות הצוות)
הם מטופלים על ידי כל הקבוצות, למרות צוות Gridlock היה מעורב רק משימות טכניות צבר חובות, כמו מתאים את שאר הצבר שלהם ומומחיות.
האם פריטים טכניים של צבר חובות מטופלים על בסיס הרחבת-הרחבה, או שהם פשוט מתמשכים, ולא קשורים בדרך כלל למחזור התרחבות ספציפי?
שניהם.
מה החוב פריטים טכניים צבר היו התמודד עבור הרחבת אודיסיאה?
כדי לתת שם כמה: אנחנו משפרים תיקון (יש מספר נמוך של כשלים בעת שימוש ב- HTTP / 1.0 proxies), לשכתב את התמונה תהליך ייצוא אוסף הדור, וכן שיפוץ טיפול השגיאה בכניסה ב- EVE API, כמו גם את שיטת הפריסה של ממשק ה- API ועדכון מנגנון המטמון הפנימי שלו (מקומי ומופץ).